Re: Interfaces and Java Client
Re: Interfaces and Java Client
- Subject: Re: Interfaces and Java Client
- From: David Avendasora <email@hidden>
- Date: Mon, 1 May 2006 14:57:01 +0100
On Apr 28, 2006, at 4:02 PM, Paul Lynch wrote:
On 28 Apr 2006, at 06:03, David Avendasora wrote:
I am using inheritance in the model as well as interfaces but the
problem isn't the inheritance! I'm having a hard time explaining
the structure of my application so I've done my first-ever UML
Class Diagram to try to explain it better. I've attached it -
hopefully it makes it.
I don't think I'm doing anything crazy. I think it is pretty
standard OO stuff (straight out of Head First Design Patterns).
Can anyone tell me a better structure?
Looks to my like a classic MRP model, a little over-refined. The
interfaces are an implementation details, and are really a red
herring.
Right now, the Part superclass is Abstract. Without coding specific
relationships to each part type that can be a component or have
components, how do I design this system? I could make the Part class
not abstract, but then when I go to save the model I get "Entity Part
(parent entity of Finished) needs a restricting qualifier in order to
filter out rows in table dbo.Part that are only holding data for
Finished instances." I get this for each subclass. I don't understand
how to put a three qualifiers (Finished, Intermediate & Raw) on one
entity (Part).
This is just one example of several relationships in my model that
that relate back to one or more part types. I REALLY don't want to be
forced to create individual relationships for each part type's
relationship to an entity - definitely NOT the OO way.
I guess the best strategy is to make them all relate to Part (if I
get the Qualifier thing figured out) and then simply restrict which
part types are available in the UI for each relationship.
The design you displayed could be implemented in a zillion
different ways, and that's even ignoring the interfaces decisions.
EOModeler is going to want to have relationships defined using
entities, rather than interfaces, because EOF needs to be able to
instantiate instances of the related objects, which I think is fair
enough.
Gotcha. Interfaces are now OUT of the EOModel. It would be cool if
they could figure out how to allow this in some future version of WO.
You can make entities Abstract, so why not Interfaces?. There will be
a future version of WO, right?
In the absence of any information to the contrary, I'd probably use
a Part and a BoM table. I notice that the interfaces in some cases
are identical in the UML (which is an over-refinement hint). I'd
probably use a type field in Part to distinguish between your three
subparts, and make them separate entities. The BoM table doesn't
need to be separated. Relationships live in your Part entity/
class, and ignore the ones you don't want. Depending on your
industry, it's not unknown for "Intermediate" parts to suddenly
become raw materials or finished goods at times; this will also
affect your design.
The reason for the BOM entity in addition to the BOM-Component entity
is that each part can have multiple BOMs, allowing the same part to
be built in different ways. This is a requirement of the system to
allow construction of a given intermediate or finihsed part from
different recipes.
Paul
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden