Inheritance and child creation

  • Thread starter Thread starter John
  • Start date Start date
J

John

Hi,

How can I achieve that a childs constructor is only callable from it's parent?
Must I declare the class Private within A?

Thanks in Advance

Public MustInherit Class A

Protected Sub New()
End Sub

Public Shared Function CreateInstance() As A
Return New B
End Function

End Class

Public Class B : Inherits A

'Should only be callable from the CreateInstance method in A
Public Sub New()
Mybase.New()
End Sub
End Class
 
John,
How can I achieve that a childs constructor is only callable from it's
Click to expand...
parent?
I normally put A & B into a Class Library (DLL), then make B.New Friend, as
I normally have a "family" of derived classes. In that C, D, E, F, and G
also inherit from A, and A.CreateInstance is able to create any one of them,
based on a parameter. The class library represents this family.

Of course other classes within the class library will be able to create B
objects.
Public Class B : Inherits A

'Should only be callable from the CreateInstance method in A
Friend Sub New()
Mybase.New()
End Sub
End Class
Click to expand...
Must I declare the class Private within A?
Click to expand...
Would be the other option, which would ensure that no one could create B
objects! I just noticed that the System.IO.Stream.Null property is
implemented in terms of a nested class.

Hope this helps
Jay
 
Jay B. Harlow said:
John,
parent?
I normally put A & B into a Class Library (DLL), then make B.New Friend, as
I normally have a "family" of derived classes. In that C, D, E, F, and G
also inherit from A, and A.CreateInstance is able to create any one of them,
based on a parameter. The class library represents this family.

Of course other classes within the class library will be able to create B
objects.


Would be the other option, which would ensure that no one could create B
objects! I just noticed that the System.IO.Stream.Null property is
implemented in terms of a nested class.

Hope this helps
Jay
Click to expand...

Thanks for the reply Jay. Making b.New friend works but in my case, in
order to avoid misunderstandings, it would be better if no other class
in the class library, besides the parent A, could call b.new, c.new
etc. If I declare all children of A within A I would achieve this but
the problem then is the size of the class. Is there any way to declare
B as private within A but supply the implementation in another file?

Best Regards
John
 
John said:
Thanks for the reply Jay. Making b.New friend works but in my case,
in order to avoid misunderstandings, it would be better if no other
class in the class library, besides the parent A, could call b.new,
c.new etc. If I declare all children of A within A I would achieve
this
Click to expand...

How? Neither making the constructor in the derived class private, nor
friend, protected, or public would achieve this.
but the problem then is the size of the class. Is there any way
to declare B as private within A but supply the implementation in
another file?
Click to expand...

The only way (IMO) is
- declare a public Interface within A
- declare the derived classes private within A ("Private Class..."). The
constructor is declared public.
- implement the public Interface in the derived classes
- Have the public function within A return objects implementing the public
Interface ("..As IMyInterface......Return New B").

Only a comment to Jay's suggestion: It might not be appliable in all
situations which means it is not a general solution for this design pattern.
Let's have classes A, B and C. Requirements:
- Only A can create B objects
- Only B can create C objects
On one side A and B must be in the same assembly, on the other side B and C
must be in the same assembly. IMO there are other criteria defining which
classes to place in the same library.
 
John,
the problem then is the size of the class. Is there any way to declare
B as private within A but supply the implementation in another file?
Click to expand...
Not in the current version of VB.NET, Within Whidbey (VS.NET 2004, available
late this year) we gain "partial types" that allow you to split a class
between files.

However I think having nested classes spread across multiple files may lead
to more confusion then understanding.

Thanks for the reply Jay. Making b.New friend works but in my case, in
order to avoid misunderstandings, it would be better if no other class
Click to expand...

IMHO this is one of those items that the pain of getting it to do
specifically what you want probably is not worth the gain, hence I simply
put the "family" in a class library, and document the library that A has the
Factory method. The "pain" being either a really large A class due to all
the nesting, or Friend Sub New in derived classes, IMHO Friend Sub New is
the less painful...

Hope this helps
Jay


John said:
parent?
I normally put A & B into a Class Library (DLL), then make B.New Friend, as
I normally have a "family" of derived classes. In that C, D, E, F, and G
also inherit from A, and A.CreateInstance is able to create any one of them,
based on a parameter. The class library represents this family.

Of course other classes within the class library will be able to create B
objects.


Would be the other option, which would ensure that no one could create B
objects! I just noticed that the System.IO.Stream.Null property is
implemented in terms of a nested class.

Hope this helps
Jay
Click to expand...

Thanks for the reply Jay. Making b.New friend works but in my case, in
order to avoid misunderstandings, it would be better if no other class
in the class library, besides the parent A, could call b.new, c.new
etc. If I declare all children of A within A I would achieve this but
the problem then is the size of the class. Is there any way to declare
B as private within A but supply the implementation in another file?

Best Regards
John[/QUOTE]
 
Armin Zingler said:
Only a comment to Jay's suggestion: It might not be appliable in
all situations which means it is not a general solution for this
design pattern. Let's have classes A, B and C. Requirements:
- Only A can create B objects
- Only B can create C objects
On one side A and B must be in the same assembly, on the other side B
and C must be in the same assembly.
Click to expand...

I should clarify: Due to both requirements it is not possible.
 
Armin,
How? Neither making the constructor in the derived class private, nor
friend, protected, or public would achieve this.
Click to expand...

Public Class A
Private Class B : Inherits A

Public Sub New()
End Sub

End Class

Public Shared Function CreateInstance() As A
Return New B
End Function

End Class
The only way (IMO) is
- declare a public Interface within A
- declare the derived classes private within A ("Private Class..."). The
constructor is declared public.
- implement the public Interface in the derived classes
- Have the public function within A return objects implementing the public
Interface ("..As IMyInterface......Return New B").
Click to expand...
Are you sure?

On the last item you need a public shared function, because A is an
Interface you cannot have shared functions. John's use of an abstract base
class (MustInherit Class) allows the Shared Function.

You are correct having the nested classes ensure that only A will be able to
create them, however you then run into a "source management issue"

Only a comment to Jay's suggestion: It might not be appliable in all
situations which means it is not a general solution for this design pattern.
Let's have classes A, B and C. Requirements:
- Only A can create B objects
- Only B can create C objects
Click to expand...
You're changing the pattern! ;-) The pattern I was describing is 2 levels
(base & derived from base). You are describing N levels (base, derived from
base, derived from derived from base).

I was suggesting that:
- Only A can create B objects
- Only A can create C objects
- Only A can create D objects
- Only A can create E objects
Click to expand...

Does fit nicely in a single assembly, especially when only that assembly can
create A objects! And referenced assemblies do not care about B, C, D, and
E. In other words A's sub new is only Friend not Protected.

Think of the case where you have an field in a database, and that field has
"behavior" in your code. A is the polymorphic class that represents the
field in the database, B, C, D, & E are the specific "values" that field can
have, each with their own specific behaviors. A.CreateInstance accepts the
database field and returns an instance of B, C, D or E. The assembly itself
represents the field as a whole.

Of course I agree, one size does not fit all.

IMHO what John "needs" is the C++ version of the Friend keyword, however
VB.NET does not support it. I don't believe the CLR supports it. Basically
in C++ Class B can state explicitly who is its Friends, then only those
specifically listed classes can use the method in B.


Hope this helps
Jay
 
Jay B. Harlow said:
Armin,


Public Class A
Private Class B : Inherits A

Public Sub New()
End Sub

End Class

Public Shared Function CreateInstance() As A
Return New B
End Function

End Class
Click to expand...

Nowhere you can access the additional members of B so I don't see when it
makes sense.... Ah, ok, if B does not have additional members. *g* AFAIR I
haven't written a derived class without additional (public) members til now.
Ok, in rare cases this might be required. ;-)
Are you sure?

On the last item you need a public shared function, because A is
an Interface you cannot have shared functions. John's use of an
abstract base class (MustInherit Class) allows the Shared
Function.
Click to expand...

No, A is not an interface. A is the class containing the interface
declaration:

class A
public interface IMyInterface
end interface

public shared function func as imyinterface
return new B
end function

private class B
inherits A
implements imyinterface
end class
end class

(interface members left out)
You are correct having the nested classes ensure that only A will be
able to create them, however you then run into a "source management
issue"
Why?

You're changing the pattern! ;-) The pattern I was describing is 2
levels (base & derived from base). You are describing N levels (base,
derived from base, derived from derived from base).
Click to expand...

Right. I only wanted to show the limits of your suggestion ("..not appliable
in *all* situations"). Usually it soon comes to the situation I described,
so your model is not only limited to the "2 levels", it also requires
rearrangement and a different approach if only 1 level will be added.

[...]

Of course I agree, one size does not fit all.
Click to expand...

I should have read _everything_ first, so I think we agree. :-)
 
Armin,
Nowhere you can access the additional members of B so I don't see when it
makes sense.... Ah, ok, if B does not have additional members. *g* AFAIR I
haven't written a derived class without additional (public) members til now.
Ok, in rare cases this might be required. ;-)
Click to expand...
What we didn't show you is that A has overridable methods, and B is (only)
overriding those methods.
Why?
Click to expand...
I don't like a single source file from getting TOO large, I realize I can
use regions & outlining... I would prefer multiple source files. Also I'm
not so sure "partial classes" is a good idea (outside of designers) however
I have not played with "partial classes" in Whidbey yet. The way I see it is
if a class is getting so big that it needs multiple source files, your class
is probably too big & should be refactored (http://www.refactoring.com). As
I'm sure you have noticed I am a big proponent of OO along with small "light
weight" objects with small "light weight" methods... Basically I try to
"right size" everything ;-)

Hope this helps
Jay

Armin Zingler said:
Jay B. Harlow said:
Armin,


Public Class A
Private Class B : Inherits A

Public Sub New()
End Sub

End Class

Public Shared Function CreateInstance() As A
Return New B
End Function

End Class
Click to expand...

Nowhere you can access the additional members of B so I don't see when it
makes sense.... Ah, ok, if B does not have additional members. *g* AFAIR I
haven't written a derived class without additional (public) members til now.
Ok, in rare cases this might be required. ;-)
Are you sure?

On the last item you need a public shared function, because A is
an Interface you cannot have shared functions. John's use of an
abstract base class (MustInherit Class) allows the Shared
Function.
Click to expand...

No, A is not an interface. A is the class containing the interface
declaration:

class A
public interface IMyInterface
end interface

public shared function func as imyinterface
return new B
end function

private class B
inherits A
implements imyinterface
end class
end class

(interface members left out)
You are correct having the nested classes ensure that only A will be
able to create them, however you then run into a "source management
issue"
Why?

You're changing the pattern! ;-) The pattern I was describing is 2
levels (base & derived from base). You are describing N levels (base,
derived from base, derived from derived from base).
Click to expand...

Right. I only wanted to show the limits of your suggestion ("..not appliable
in *all* situations"). Usually it soon comes to the situation I described,
so your model is not only limited to the "2 levels", it also requires
rearrangement and a different approach if only 1 level will be added.

[...]

Of course I agree, one size does not fit all.
Click to expand...

I should have read _everything_ first, so I think we agree. :-)
Click to expand...
 
Jay B. Harlow said:
I don't like a single source file from getting TOO large, I realize I
can use regions & outlining... I would prefer multiple source files.
Also I'm not so sure "partial classes" is a good idea (outside of
designers) however I have not played with "partial classes" in
Whidbey yet. The way I see it is if a class is getting so big that it
needs multiple source files, your class is probably too big & should
be refactored (http://www.refactoring.com). As I'm sure you have
noticed I am a big proponent of OO along with small "light weight"
objects with small "light weight" methods... Basically I try to
"right size" everything ;-)
Click to expand...

Ok, I see the point now. Probably my lack of experience because I have never
had to write so many larger nested classes til now. Though, I would prefer a
large class over your modifier approach due to the reasons I have already
given - but I think we both know that often the right decision will turn
out in future. ;-)
 
Armin,
Though, I would prefer a
large class over your modifier approach due to the reasons I have already
given - but I think we both know that often the right decision will turn
out in future. ;-)
Click to expand...
Actually that is one of the cool things about Refactoring!

You can start out with one design, then change to the another design later,
in a controlled and "safe" manner.

I just wish there were more automated tools for Refactoring in VB.NET! Or
possible even a Refactoring book geared toward VB.NET similar to James
Cooper's VB6 & VB.NET book on Design Patterns.

Hope this helps
Jay
 
Back
Top