Re: Architecting Dilemma
- From: "John Wright" <riley_wrightx@xxxxxxxxxxx>
- Date: Wed, 11 Apr 2007 11:32:46 -0600
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" <branco.medeiros@xxxxxxxxx> wrote in message
news:1176311468.152193.15250@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
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
.
- Follow-Ups:
- Re: Architecting Dilemma
- From: John Wright
- Re: Architecting Dilemma
- References:
- Architecting Dilemma
- From: John Wright
- Re: Architecting Dilemma
- From: John Wright
- Re: Architecting Dilemma
- From: Branco Medeiros
- Architecting Dilemma
- Prev by Date: Re: Architecting Dilemma
- Next by Date: Bluetooth
- Previous by thread: Re: Architecting Dilemma
- Next by thread: Re: Architecting Dilemma
- Index(es):
Relevant Pages
|