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
10  1223 
John, How can I achieve that a childs constructor is only callable from it's
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
Must I declare the class Private within A?
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
"John" <ju***********@yahoo.se> wrote in message
news:5f**************************@posting.google.c om... 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
"Jay B. Harlow [MVP - Outlook]" <Ja************@msn.com> wrote in message news:<Oz**************@TK2MSFTNGP10.phx.gbl>... John, How can I achieve that a childs constructor is only callable from it's
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
Must I declare the class Private within A?
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
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" <ju***********@yahoo.se> schrieb
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
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?
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.
--
Armin http://www.plig.net/nnq/nquote.html http://www.netmeister.org/news/learn2quote.html
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?
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
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" <ju***********@yahoo.se> wrote in message
news:5f**************************@posting.google.c om... "Jay B. Harlow [MVP - Outlook]" <Ja************@msn.com> wrote in message
news:<Oz**************@TK2MSFTNGP10.phx.gbl>... John, How can I achieve that a childs constructor is only callable from it's
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
Must I declare the class Private within A?
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
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
"Armin Zingler" <az*******@freenet.de> schrieb 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.
I should clarify: Due to both requirements it is not possible.
--
Armin
Armin, How? Neither making the constructor in the derived class private, nor
friend, protected, or public would achieve this.
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").
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
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
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
"Armin Zingler" <az*******@freenet.de> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl... "John" <ju***********@yahoo.se> schrieb
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
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?
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.
--
Armin
http://www.plig.net/nnq/nquote.html
http://www.netmeister.org/news/learn2quote.html
"Jay B. Harlow [MVP - Outlook]" <Ja************@msn.com> schrieb Armin,
How? Neither making the constructor in the derived class private,
nor friend, protected, or public would achieve this.
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
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. ;-)
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").
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.
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?
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
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).
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.
I should have read _everything_ first, so I think we agree. :-)
--
Armin
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. ;-)
What we didn't show you is that A has overridable methods, and B is (only)
overriding those methods.
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?
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" <az*******@freenet.de> wrote in message
news:Ok**************@TK2MSFTNGP10.phx.gbl... "Jay B. Harlow [MVP - Outlook]" <Ja************@msn.com> schrieb Armin,
How? Neither making the constructor in the derived class private,
nor friend, protected, or public would achieve this.
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
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. ;-)
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"). 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.
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?
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
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).
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.
I should have read _everything_ first, so I think we agree. :-)
--
Armin
"Jay B. Harlow [MVP - Outlook]" <Ja************@msn.com> schrieb 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?
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 ;-)
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
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. ;-)
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
"Armin Zingler" <az*******@freenet.de> wrote in message
news:Og**************@TK2MSFTNGP10.phx.gbl... "Jay B. Harlow [MVP - Outlook]" <Ja************@msn.com> schrieb > 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? 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 ;-)
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 This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Axel Straschil |
last post by:
Hello!
Im working with new (object) classes and normaly call init of ther
motherclass with callin super(...), workes fine.
No, I've got a case with multiple inherance and want to ask if this...
|
by: Peter Hamilton |
last post by:
I am trying to implement inheritance but I am having a difficult time with some concepts.
What I am trying to do is have a Child object inherit from the Parent, and when you set a property value...
|
by: Ben Blank |
last post by:
I'm writing a family of classes which all inherit most of their methods and
code (including constructors) from a single base class. When attempting to
instance one of the derived classes using...
|
by: Andrew Ducker |
last post by:
Let's say I have a root class called RootBusinessService
and I then want to have 25 business service classes based off of it.
And each class has a property that's shared between all instances of...
|
by: VR |
last post by:
Hi, I read about Master Pages in ASP.Net 2.0 and after implementing some
WinForms Visual Inheritance I tryed it with WebForms (let's say .aspx pages,
my MasterPage does not have a form tag itself...
|
by: Mark |
last post by:
why doesn't .NET support multiple inheritance?
I think it's so silly!
Cheers,
Mark
|
by: Julius Fuchs |
last post by:
Hi,
if I create a Person, a Vehicle is created; that's fine.
The problem is that if I create a Child the constuctor of Person is called
before and a Vehicle is created then a Bike is created and...
|
by: mmcloughlin |
last post by:
I'm learning about objects and am trying to figure out how basic
inheritance works. I've got into the habit of explicitly setting the
prototype object with an object literal as it seems to make the...
|
by: Ook |
last post by:
The following code compiles and runs. In my overloaded operator<<, I
call Parent.stuff. I would expect it to call Child.stuff, since Child
is the child class, but it does not. What am I missing,...
|
by: johnsonlau |
last post by:
When a class derives from a class,
You can use a pointer to the parent class to delete the instance of
child
only when a virtual destructor declared in the parent.
class Parent
{
virtual...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
|
by: conductexam |
last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and...
| |
