Architecting Dilemma

[John Wright]

Here is the situation. We are rearchitecting an application from VB 6.0 to
VB.NET 2005. Of course in VB6 there was no OOP so there are lots of CLS
files that do the work for each object type. I am proposing creating a base
class object that contains all the common properties and methods for an
object, then using inheritance, creating specific types of objects from the
base class. This is not a problem. This is a manufacturing application and
the manufacturing process is FOO ---Widget --->Piece. All Widgets are
created from FOO's and all Pieces are created from Widgets. I have proposed
creating a Widget base class and inheriting the Piece classes from Widget.
Widget will contain the FOO ID and FOO Part Number as read only properties
since they are really the only thing needed for the Piece class. Not a
problem. So to create a FOO I do the following (pseudocode)

Dim x as new FOO
x.ID = 5
x.PartNumber = "12345B"
x.Weight = 2500
x.Traveler = "FOO 124(4)"
x.Standard = "FOO 344-(J)"
x.ChemistryID = 44
x.update.

This creates a new FOO item. Next I need to create a Piece from Widget so
pseudocoding again, I create a Piece Class (inheriting from Widget):

Dim Y as new Piece(54)
y.traveler = "Piece12345A" 'Set in Widget since all pieces have a traveler
y.Standard = "Standard1234" 'Set in Widget since all pieces have a standard
y.weight = 32 'Set in the Piece class since not all pieces have a weight
y.Step = 44 'Set in Widget since all pieces have a traveler step
y.PartNumber = "PieceX" 'Set in Widget since all pieces have a PartNumber
y.Batch = "44x" 'Set in Piece since not all pieces have a batch
y.FOOID = FOOID 'Readonly from the Widget Class
y.FOONumber = FOONumber 'Readonly from the Widget class
y.update

Now for the big question. While MOST of the time we only need the FOOID and
FOONumber as readonly data, there are occasions where someone would need
more information such as the chemistry and the weight (there will be some
cases where weight would be very necessary), should we create two classes
for FOO? One class would be created when we are creating a FOO for the
first time and entered into the system, the other would be readonly data
that a function in Widget would create. Example:

Public Class FOO
_Weight as Long
_ID as integer
_PartID as string

Properties here

Methods here

Public Class FOO2
_Weight as Long
_ID as integer
_PartID as string
Readonly Properties here
No methods.

Then call the class properties as follows:

Public Class Widget
'Widget Properties
Dim _X as new FOO2 ([ID])
Public Readonly Property FOOWeight as long
Return _x.Weight
Or should I create one FOO class and set readonly properties for FOO in my
Widget Class and set them as appropriate.
Public Class Widget
Dim _FOOID as Integer
Dim _FOONumber as String
Dim _FOOWeight as long
Public Readonly Property _FOOWeight as Long
return _FOOID
...More FOO Read only properties
...Widget Properties
...Widget Events
...Widget Methods
I know this is a lot but I would like some direction.

Thanks.

John Wright

[Larry Linson]

screw classes

keep your DATA in a DATABASE and question M$

On Apr 10, 2:36 pm, "John Wright" <[e-mail]:

Here is the situation. We are rearchitecting an application from VB 6.0 to
VB.NET 2005. Of course in VB6 there was no OOP so there are lots of CLS
files that do the work for each object type. I am proposing creating a base
class object that contains all the common properties and methods for an
object, then using inheritance, creating specific types of objects from the
base class. This is not a problem. This is a manufacturing application and
the manufacturing process is FOO ---Widget --->Piece. All Widgets are
created from FOO's and all Pieces are created from Widgets. I have proposed
creating a Widget base class and inheriting the Piece classes from Widget.
Widget will contain the FOO ID and FOO Part Number as read only properties
since they are really the only thing needed for the Piece class. Not a
problem. So to create a FOO I do the following (pseudocode)

Dim x as new FOO
x.ID = 5
x.PartNumber = "12345B"
x.Weight = 2500
x.Traveler = "FOO 124(4)"
x.Standard = "FOO 344-(J)"
x.ChemistryID = 44
x.update.

This creates a new FOO item. Next I need to create a Piece from Widget so
pseudocoding again, I create a Piece Class (inheriting from Widget):

Dim Y as new Piece(54)
y.traveler = "Piece12345A" 'Set in Widget since all pieces have a traveler
y.Standard = "Standard1234" 'Set in Widget since all pieces have a standard
y.weight = 32 'Set in the Piece class since not all pieces have a weight
y.Step = 44 'Set in Widget since all pieces have a traveler step
y.PartNumber = "PieceX" 'Set in Widget since all pieces have a PartNumber
y.Batch = "44x" 'Set in Piece since not all pieces have a batch
y.FOOID = FOOID 'Readonly from the Widget Class
y.FOONumber = FOONumber 'Readonly from the Widget class
y.update

Now for the big question. While MOST of the time we only need the FOOID and
FOONumber as readonly data, there are occasions where someone would need
more information such as the chemistry and the weight (there will be some
cases where weight would be very necessary), should we create two classes
for FOO? One class would be created when we are creating a FOO for the
first time and entered into the system, the other would be readonly data
that a function in Widget would create. Example:

Public Class FOO
_Weight as Long
_ID as integer
_PartID as string

Properties here

Methods here

Public Class FOO2
_Weight as Long
_ID as integer
_PartID as string
Readonly Properties here
No methods.

Then call the class properties as follows:

Public Class Widget
'Widget Properties
Dim _X as new FOO2 ([ID])
Public Readonly Property FOOWeight as long
Return _x.Weight

Or should I create one FOO class and set readonly properties for FOO in my
Widget Class and set them as appropriate.
Public Class Widget
Dim _FOOID as Integer
Dim _FOONumber as String
Dim _FOOWeight as long
Public Readonly Property _FOOWeight as Long
return _FOOID
...More FOO Read only properties
...Widget Properties
...Widget Events
...Widget Methods

I know this is a lot but I would like some direction.

Thanks.

John Wright

[Branco Medeiros]

John Wright wrote:
<backposted />

I couldn't tell, by your description, if a Piece *is* a Widget (and a
Widget *is* a Foo -- which would make Piece also a Foo), or a Foo
*creates* widgets, which by their turn *create* pieces...

Then you show some pseudocode where a piece is assigned some values,
but the comments are confusing me either; you say, for instance about
"y", a piece:

y.traveler = "Piece12345A" 'Set in Widget since all pieces have a traveler

What does "Set in Widget" means? That "traveler" is an inherited
property? If so, then I'd say that all *widgets* -- instead of pieces
-- have a traveler (whatever that means)...

It's quite useless to propose any approach with so many er, pieces,
missing so I suggest you clarify the above doubts first (unless
someone shows up with a more clear understanding and suggests
something usefull).

Anyway, you ask about what to do with having a foo completely exposed
to the general universe of pieces and widgets, and how to protect it.

One possible approach would be a FooAdapter, which would only expose
readonly data about the foo:

Class FooAdapter
private mFoo As Foo
Public Sub New(Foo As Foo)
mFoo = Foo
End Sub

Public ReadOnly Property Chemistry As WhimsicalItem
Return mFoo.Chemistry
End Property

...and so on...

End Class

HTH.

Regards,

Branco.

Here is the situation. We are rearchitecting an application from VB 6.0 to
VB.NET 2005. Of course in VB6 there was no OOP so there are lots of CLS
files that do the work for each object type. I am proposing creating a base
class object that contains all the common properties and methods for an
object, then using inheritance, creating specific types of objects from the
base class. This is not a problem. This is a manufacturing application and
the manufacturing process is FOO ---Widget --->Piece. All Widgets are
created from FOO's and all Pieces are created from Widgets. I have proposed
creating a Widget base class and inheriting the Piece classes from Widget.
Widget will contain the FOO ID and FOO Part Number as read only properties
since they are really the only thing needed for the Piece class. Not a
problem. So to create a FOO I do the following (pseudocode)

Dim x as new FOO
x.ID = 5
x.PartNumber = "12345B"
x.Weight = 2500
x.Traveler = "FOO 124(4)"
x.Standard = "FOO 344-(J)"
x.ChemistryID = 44
x.update.

This creates a new FOO item. Next I need to create a Piece from Widget so
pseudocoding again, I create a Piece Class (inheriting from Widget):

Dim Y as new Piece(54)
y.traveler = "Piece12345A" 'Set in Widget since all pieces have a traveler
y.Standard = "Standard1234" 'Set in Widget since all pieces have a standard
y.weight = 32 'Set in the Piece class since not all pieces have a weight
y.Step = 44 'Set in Widget since all pieces have a traveler step
y.PartNumber = "PieceX" 'Set in Widget since all pieces have a PartNumber
y.Batch = "44x" 'Set in Piece since not all pieces have a batch
y.FOOID = FOOID 'Readonly from the Widget Class
y.FOONumber = FOONumber 'Readonly from the Widget class
y.update

Now for the big question. While MOST of the time we only need the FOOID and
FOONumber as readonly data, there are occasions where someone would need
more information such as the chemistry and the weight (there will be some
cases where weight would be very necessary), should we create two classes
for FOO? One class would be created when we are creating a FOO for the
first time and entered into the system, the other would be readonly data
that a function in Widget would create. Example:

Public Class FOO
_Weight as Long
_ID as integer
_PartID as string

Properties here

Methods here

Public Class FOO2
_Weight as Long
_ID as integer
_PartID as string
Readonly Properties here
No methods.

Then call the class properties as follows:

Public Class Widget
'Widget Properties
Dim _X as new FOO2 ([ID])
Public Readonly Property FOOWeight as long
Return _x.Weight

Or should I create one FOO class and set readonly properties for FOO in my
Widget Class and set them as appropriate.
Public Class Widget
Dim _FOOID as Integer
Dim _FOONumber as String
Dim _FOOWeight as long
Public Readonly Property _FOOWeight as Long
return _FOOID
...More FOO Read only properties
...Widget Properties
...Widget Events
...Widget Methods

I know this is a lot but I would like some direction.

Thanks.

John Wright

[jeff]

i think you are using inheritance wrong ... inheritance is for things
like...

BaseClass ... Person ... properties ... name, age, sex, DoB

PatientClass inherits from PersonClass and includes these additional
properties ... ChartNumber

PhysicianClass inherits from PersonClass and includes these additional
properties ... CollegeOfPhysicianID ...

SpecialistClass inherits from PhysicianClass and includes these additional
properties ... SpecialtyCode

So a patient has a name, age, sex, DoB and ChartNumber property
Physician has a name, aga, sex, DoB and CollegeOfPhysicianID
Specialist has a name, age, sex, DoB, CollegeOfPhysicianID and SpecialtyCode

If you want to record Eye Color for all Persons, you simple add the Property
to the Base PersonClass and ALL people now have EyeColor.
If you want to record CountryOfOrigin for each physician, you simply add
this property to the PhysicianClass and now you have it for All physicians,
including Specialist.

Inheritance allows you to 'extend' a base class to better reflect your
business object. It is not intended to model relationships.

What you describe here, if I am reading correctly is a relationship.

There are many FOO's in a Widget
There are many Widgets in a Piece ...

Is this the relationship ...
Foo is many to 1 Widget
Widget is many to 1 piece

If this is the case, than you are dealing with three seperate classes ...
that ARE related, not INHERITENT. You do not use INHERITENCE to should
RELATIONSHIP, you use inheritence to extend a class to better suit your
object.

What I would do is ...

Create Foo Class...
- make the properties specific to the FOO object.

Create a Widget Class...
- make the properties specific to the Widget object
- one property will be a Collection of FOO's ...

Create a Piece Class
- make the properties specific to a piece
- one property will be a collection of widgets.

This is assuming I am reading your request correctly...If I am not correct,
the please ignore.

Thanks
Jeff

"John Wright" <ri***********@hotmail.comwrote in message
news:e4**************@TK2MSFTNGP04.phx.gbl...

Here is the situation. We are rearchitecting an application from VB 6.0
to VB.NET 2005. Of course in VB6 there was no OOP so there are lots of
CLS files that do the work for each object type. I am proposing creating
a base class object that contains all the common properties and methods
for an object, then using inheritance, creating specific types of objects
from the base class. This is not a problem. This is a manufacturing
application and the manufacturing process is FOO ---Widget --->Piece.
All Widgets are created from FOO's and all Pieces are created from
Widgets. I have proposed creating a Widget base class and inheriting the
Piece classes from Widget. Widget will contain the FOO ID and FOO Part
Number as read only properties since they are really the only thing needed
for the Piece class. Not a problem. So to create a FOO I do the following
(pseudocode)

Dim x as new FOO
x.ID = 5
x.PartNumber = "12345B"
x.Weight = 2500
x.Traveler = "FOO 124(4)"
x.Standard = "FOO 344-(J)"
x.ChemistryID = 44
x.update.

This creates a new FOO item. Next I need to create a Piece from Widget so
pseudocoding again, I create a Piece Class (inheriting from Widget):

Dim Y as new Piece(54)
y.traveler = "Piece12345A" 'Set in Widget since all pieces have a
traveler
y.Standard = "Standard1234" 'Set in Widget since all pieces have a
standard
y.weight = 32 'Set in the Piece class since not all pieces have a weight
y.Step = 44 'Set in Widget since all pieces have a traveler step
y.PartNumber = "PieceX" 'Set in Widget since all pieces have a PartNumber
y.Batch = "44x" 'Set in Piece since not all pieces have a batch
y.FOOID = FOOID 'Readonly from the Widget Class
y.FOONumber = FOONumber 'Readonly from the Widget class
y.update

Now for the big question. While MOST of the time we only need the FOOID
and FOONumber as readonly data, there are occasions where someone would
need more information such as the chemistry and the weight (there will be
some cases where weight would be very necessary), should we create two
classes for FOO? One class would be created when we are creating a FOO
for the first time and entered into the system, the other would be
readonly data that a function in Widget would create. Example:

Public Class FOO
_Weight as Long
_ID as integer
_PartID as string

Properties here

Methods here

Public Class FOO2
_Weight as Long
_ID as integer
_PartID as string
Readonly Properties here
No methods.

Then call the class properties as follows:

Public Class Widget
'Widget Properties
Dim _X as new FOO2 ([ID])
Public Readonly Property FOOWeight as long
Return _x.Weight
Or should I create one FOO class and set readonly properties for FOO in my
Widget Class and set them as appropriate.
Public Class Widget
Dim _FOOID as Integer
Dim _FOONumber as String
Dim _FOOWeight as long
Public Readonly Property _FOOWeight as Long
return _FOOID
...More FOO Read only properties
...Widget Properties
...Widget Events
...Widget Methods
I know this is a lot but I would like some direction.

Thanks.

John Wright

[John Wright]

Sorry for the confusion. Let me try to clarify.

The relationship of FOO's to Widgets is 1 to many. I FOO creates many
widgets. The do not share any properties at all except for the widget
containing the FOO ID and FOO Number. The relationship of Widgets to Pieces
is 1 to many. I widget can create many pieces. Pieces will inherit from
widget because they so share many qualities. Like the example given of
BaseClass....person.....properties and creating different types of people,
the pieces class will create different types of pieces that all come from
widgets.

So

FOO --------Widget2-----Piece 1
| |_______Piece 2
| |_______Piece 3
|
|------------Widget2----Piece 1
|_______Piece 2
|_______Piece 3

Note the dashed line from FOO to widget is just showing the relationship of
Widgets to FOO by including a readonly property in widget containing the FOO
ID and FOO Part Number. The Pieces are all specifics with extended
properties for each piece type.

In the FOO class I do have some data I would like to get from the Piece
class. For example the FOO weight. This weight will help determine the
estimated weight of the piece after processing. So I would like to have the
ability to go get the weight by putting in piece1.foo.weight.

Now the FOO class will be created when a new FOO is generated. Most of
these properties will not be needed or accessible from Widget (and Piece by
default of inheritance). So do I create a new FOO2 class that Widget will
create that will contain only readonly properties, or do I put a method in
Widget that will create the FOO class and provide the readonly properties
this way.

As for skipping inheritance and putting it all in the database, we did that
in VB 6 and adding new pieces and widgets was nightmare, not to mention all
the duplicate coding.

John

[jeff]

john,

read my previous and reverse the order of FOO and Piece ....

Create a FOO class
....

Create a Widget class
....

Create a Piece class...

The foo class will have a list / collection of Widgets ... as a property
The Widget class will have a list / collection of Pieces ... as a property.

The FOO 'TotalWeigh' would be a method ...

Foo.getWeigth()
Dim lReturn as Decimal
For each Widget in WidgetsList
lReturn = Widget.GetWeight() + lReturn
Next
Widget.GetWieght()
Dim lReturn as Decimal
For each piece in pieces
lreturn = piece.wieght + lReturn
next

When you add NEW pieces ... do you mean that each piece could / would have
its own set of properties ??? Did you create a Seperate TABLE / SCHEMA for
new a piece or do you add a new ROW an existing PIECE table for the new
piece?

If yes, you should investigate inheritance...

Are you telling me that for each new 'Piece' Widget and FOO you have a
distinctly different TABLE?
"John Wright" <ri***********@hotmail.comwrote in message
news:uJ**************@TK2MSFTNGP05.phx.gbl...

Sorry for the confusion. Let me try to clarify.

The relationship of FOO's to Widgets is 1 to many. I FOO creates many
widgets. The do not share any properties at all except for the widget
containing the FOO ID and FOO Number. The relationship of Widgets to
Pieces is 1 to many. I widget can create many pieces. Pieces will inherit
from widget because they so share many qualities. Like the example given
of BaseClass....person.....properties and creating different types of
people, the pieces class will create different types of pieces that all
come from widgets.

So

FOO --------Widget2-----Piece 1
| |_______Piece 2
| |_______Piece 3
|
|------------Widget2----Piece 1
|_______Piece 2
|_______Piece 3

Note the dashed line from FOO to widget is just showing the relationship
of Widgets to FOO by including a readonly property in widget containing
the FOO ID and FOO Part Number. The Pieces are all specifics with
extended properties for each piece type.

In the FOO class I do have some data I would like to get from the Piece
class. For example the FOO weight. This weight will help determine the
estimated weight of the piece after processing. So I would like to have
the ability to go get the weight by putting in piece1.foo.weight.

Now the FOO class will be created when a new FOO is generated. Most of
these properties will not be needed or accessible from Widget (and Piece
by default of inheritance). So do I create a new FOO2 class that Widget
will create that will contain only readonly properties, or do I put a
method in Widget that will create the FOO class and provide the readonly
properties this way.

As for skipping inheritance and putting it all in the database, we did
that in VB 6 and adding new pieces and widgets was nightmare, not to
mention all the duplicate coding.

John

[Branco Medeiros]

John Wright wrote:
<backposted/>

So, you have a class Foo that creates Widgets:

Class Foo
Private mWidgets As New List(Of Widget)

Function NewWidget(Parameters) As Widget
Dim W As New Widget(Me)
'...initialize the new widget...
mWidgets.Add(W)
Return W
End Function

Public ReadOnly Default Property _
Widgets(Index As Integer) As Widget
Get: Return mWidgets(Index)
End Get
End Property

...
End Class

This is quite ok, and I don't see why the Widget class can't have a
Foo propety that would simply return a reference to the original
creator. This way, whoever was interested in whatever foo properties
could simply query the widget's foo reference. This is a simple parent-
child relationship, and is straight forward in VB.Net (in VB6 this
would be complicated because of the circular references, requiring you
to use intermediate objects or unspeakable hacks. In VB.Net this is a
non-issue - aleluia!).

What seems to be bothering you is that you want the foo that is
exposed by widget to be read only, i.e., you (seem to) want to prevent
code elsewhere from changing this foo's content. Before going further,
is this really necessary? Consider the possibilities of allowing this
foo to be modified by some code accessing it throwgh the widget's
reference... this can be a feature instead of an issue.

Anyway, if you're positive that you really don't want foo being
modified through the reference exposed by widget then one way to
achieve this is, as said before, to have a FooAdapter (or FooProxy,
FooInfo, Foo2, whatever you want to call it) that would expose only
readonly versions of the foo properties.

The problem with this approach is that you'd need to update the
adapter class whenever you changed the original foo class (by adding/
removing properties).

In this case, widget wouldn't have an actual reference to the real
foo, but only to an instance of a FooAdapter created from the original
foo.

HTH.

Regards,

Branco.

Sorry for the confusion. Let me try to clarify.

The relationship of FOO's to Widgets is 1 to many. I FOO creates many
widgets. The do not share any properties at all except for the widget
containing the FOO ID and FOO Number. The relationship of Widgets to Pieces
is 1 to many. I widget can create many pieces. Pieces will inherit from
widget because they so share many qualities. Like the example given of
BaseClass....person.....properties and creating different types of people,
the pieces class will create different types of pieces that all come from
widgets.

So

FOO --------Widget2-----Piece 1
| |_______Piece 2
| |_______Piece 3
|
|------------Widget2----Piece 1
|_______Piece 2
|_______Piece 3

Note the dashed line from FOO to widget is just showing the relationship of
Widgets to FOO by including a readonly property in widget containing the FOO
ID and FOO Part Number. The Pieces are all specifics with extended
properties for each piece type.

In the FOO class I do have some data I would like to get from the Piece
class. For example the FOO weight. This weight will help determine the
estimated weight of the piece after processing. So I would like to have the
ability to go get the weight by putting in piece1.foo.weight.

Now the FOO class will be created when a new FOO is generated. Most of
these properties will not be needed or accessible from Widget (and Piece by
default of inheritance). So do I create a new FOO2 class that Widget will
create that will contain only readonly properties, or do I put a method in
Widget that will create the FOO class and provide the readonly properties
this way.

As for skipping inheritance and putting it all in the database, we did that
in VB 6 and adding new pieces and widgets was nightmare, not to mention all
the duplicate coding.

John

[John Wright]

I think the Widget class will be able to return a reference of FOO that
created it and let the FOO properties be exposed through this class. Thanks
all for the suggestions.

John
"Branco Medeiros" <br*************@gmail.comwrote in message
news:11*********************@w1g2000hsg.googlegrou ps.com...

John Wright wrote:
<backposted/>

So, you have a class Foo that creates Widgets:

Class Foo
Private mWidgets As New List(Of Widget)

Function NewWidget(Parameters) As Widget
Dim W As New Widget(Me)
'...initialize the new widget...
mWidgets.Add(W)
Return W
End Function

Public ReadOnly Default Property _
Widgets(Index As Integer) As Widget
Get: Return mWidgets(Index)
End Get
End Property

...
End Class

This is quite ok, and I don't see why the Widget class can't have a
Foo propety that would simply return a reference to the original
creator. This way, whoever was interested in whatever foo properties
could simply query the widget's foo reference. This is a simple parent-
child relationship, and is straight forward in VB.Net (in VB6 this
would be complicated because of the circular references, requiring you
to use intermediate objects or unspeakable hacks. In VB.Net this is a
non-issue - aleluia!).

What seems to be bothering you is that you want the foo that is
exposed by widget to be read only, i.e., you (seem to) want to prevent
code elsewhere from changing this foo's content. Before going further,
is this really necessary? Consider the possibilities of allowing this
foo to be modified by some code accessing it throwgh the widget's
reference... this can be a feature instead of an issue.

Anyway, if you're positive that you really don't want foo being
modified through the reference exposed by widget then one way to
achieve this is, as said before, to have a FooAdapter (or FooProxy,
FooInfo, Foo2, whatever you want to call it) that would expose only
readonly versions of the foo properties.

The problem with this approach is that you'd need to update the
adapter class whenever you changed the original foo class (by adding/
removing properties).

In this case, widget wouldn't have an actual reference to the real
foo, but only to an instance of a FooAdapter created from the original
foo.

HTH.

Regards,

Branco.

>Sorry for the confusion. Let me try to clarify.

The relationship of FOO's to Widgets is 1 to many. I FOO creates many
widgets. The do not share any properties at all except for the widget
containing the FOO ID and FOO Number. The relationship of Widgets to
Pieces
is 1 to many. I widget can create many pieces. Pieces will inherit from
widget because they so share many qualities. Like the example given of
BaseClass....person.....properties and creating different types of
people,
the pieces class will create different types of pieces that all come from
widgets.

So

FOO --------Widget2-----Piece 1
| |_______Piece 2
| |_______Piece 3
|
|------------Widget2----Piece 1
|_______Piece 2
|_______Piece 3

Note the dashed line from FOO to widget is just showing the relationship
of
Widgets to FOO by including a readonly property in widget containing the
FOO
ID and FOO Part Number. The Pieces are all specifics with extended
properties for each piece type.

In the FOO class I do have some data I would like to get from the Piece
class. For example the FOO weight. This weight will help determine the
estimated weight of the piece after processing. So I would like to have
the
ability to go get the weight by putting in piece1.foo.weight.

Now the FOO class will be created when a new FOO is generated. Most of
these properties will not be needed or accessible from Widget (and Piece
by
default of inheritance). So do I create a new FOO2 class that Widget
will
create that will contain only readonly properties, or do I put a method
in
Widget that will create the FOO class and provide the readonly properties
this way.

As for skipping inheritance and putting it all in the database, we did
that
in VB 6 and adding new pieces and widgets was nightmare, not to mention
all
the duplicate coding.

John

[John Wright]

I think I found a solution that will work. I create a new reference to the
base class as a property in the Widget Class.

Public ReadOnly Property FOO() As FOO

Get

If _FOO Is Nothing Then

_FOO = New FOO(_FOOID, True)

End If

End Get

End Property

The second parameter in creating a new _FOO (true) sets a flag in the base
class called _Readonly. If _Readonly is set to true then any time someone
tries to set a property of FOO through the Widget class, it checks the flag.
If True the class was instantiated Readonly and the property is not set and
I throw an exception back. This will allow me to create a FOO class
directly with a False flag which will allow all properties that can be set
to be set. And if I need to add more properties to the FOO class that are
not readonly, I just need to add the code to check the flag and set the
property or return the error. Done.

John