Design Objects with some common attribute/behavior. Is inheritance correct?
Hi,
In an application I am working on the domain/business layer has lots of domain objects. many of these domin objects aggregate to form other domain objects. Also in the application we have a class "User" that has the user information and privileges of the logged in "User."
When updates to the domain object have to be saved to the database we need this user information.
To make this we have created an AbstractDomainObject that has a private user and get and set methods.
All (almost all) domain objects in our system will extend from this Abstract DomainObject. So Contract, Shipment and Party all are domain objects and they extend AbstractDomainObject.
This way we do not need to code the get and set methods for user information in each object and also do not have to pass along the user object separately to the DataAccess layers.
But I think that this is wrong as we are using inheritance for code-reuse. (I have read about inheritance v/s composition) But it does save lot of code and any new domain object that gets written we have the user information available. (we have lots of domain objects)
Can somebody suggest what would be a better design with arguments that I could use to influence the other people in the team.
Thanks,
[1306 byte] By [
abhi73a] at [2007-10-3 3:13:27]
> But I think that this is wrong as we are using
> inheritance for code-reuse. (I have read about
> inheritance v/s composition)
I agree with that conclusion.
> But it does save lot of code
I suspect that is an illusion. The code is most likely moved not disapeared with what amounts to a setUser() and setPassword() calls for every domain object.
> and any new domain object that gets written
> we have the user information available. (we have
> lots of domain objects)
By all means have the user credentials in a base interface, but pass them in as a Memento. The domain objects should not typically include a persistence mechanism. They should delegate this to a persistence layer. Checkout the DAO/DTO patterns.
> Can somebody suggest what would be a better design
> with arguments that I could use to influence the
> other people in the team.
I would pass the user credentials into the persistence layer as a memento.
The main argument in favour of this approach is the principle of a single responsibility, though demters laws (tell dont ask) would also support this approach.
> By all means have the user credentials in a base
> interface, but pass them in as a Memento. The domain
> objects should not typically include a persistence
> mechanism. They should delegate this to a
> persistence layer. Checkout the DAO/DTO patterns.
I'm confused by what you mean by Memento. Are you talking about the Memento pattern? The typical example of Memento would be an undo mechanism. That doesn't seem to apply here.
http://pages.cpsc.ucalgary.ca/~kristen/memento.shtml
> But I think that this is wrong as we are using
> inheritance for code-reuse. (I have read about
> inheritance v/s composition) But it does save lot
> of code and any new domain object that gets written
> we have the user information available. (we have
> lots of domain objects)
I also think it is wrong but not for this reason in particular. You are associating a user with these Objects for (percieived) convienience.
It seems to me that you need to have a user session in your design and that these domain objects should be associated with a user session and/or a transaction inside that user's session.
In short, I think your Object relationships are upside-down. Whenever you run into a situation where a lot of Objects reference the same thing (but not vice-versa) consider that reversing the assocation can simplify things greatly.
> I'm confused by what you mean by Memento. Are you
> talking about the Memento pattern?
Yes I mean the Memento Pattern.
> The typical example of Memento would be an undo mechanism.
> That doesn't seem to apply here.
Undo is only a single application of Memento not it's intent. The core intent is to store and externalise a state, which is why this pattern is also called Token.
Applied to this example the state is the login credentials and possible a persistent connection. It is undesirable to store these in multiple domain objects.
> Undo is only a single application of Memento not it's
> intent. The core intent is to store and externalise
> a state, which is why this pattern is also called
> Token.
>
> Applied to this example the state is the login
> credentials and possible a persistent connection. It
> is undesirable to store these in multiple domain
> objects.
Why would you need externalize the state of the user credentials and connection in this situation? What problem does that solve. As far as I can tell, the OP is just trying to figure out where to store them. You don't need to externalize the state to avoid storing the credentials in many places.
> Undo is only a single application of Memento not it's
> intent. The core intent is to store and externalise
> a state, which is why this pattern is also called
> Token.
I'm not 100% sure but I believe this is a correct quote of the intent from GoF:
http://www.smallmemory.com/almanac/GammaEtc95.html
"Without violating encapsulation, capture and externalize an object's internal state so the object can be restored to the state."
I don't see anything about restoring state here. It's not even clear to me how externalizing the state (without breaking encapsulation i.e. no one else can see this externalized state) solves the OPs problem of retrieving the user credentials from many contexts.
> Why would you need externalize the state of the user
> credentials and connection in this situation?
Externalised is this context refers to them being used by another class e.g. java.sql.Connection, not persisting them.
> What problem does that solve.
Avoids the Domain object aquiring multiple responsibilities.
> As far as I can tell, the
> OP is just trying to figure out where to store them.
If with 'store' you mean which class to hold them. I agree.
> You don't need to externalize the state to avoid
> storing the credentials in many places.
I disagree, but I think that is because you assume I mean persist which I don't. In the Memento Pattern externalise means externalise properties from the object encapsulating them.
> I'm not 100% sure but I believe this is a correct
> quote of the intent from GoF:
>
> http://www.smallmemory.com/almanac/GammaEtc95.html
>
> "Without violating encapsulation, capture and
> externalize an object's internal state so the object
> can be restored to the state."
Yes.
> I don't see anything about restoring state here.
The state restored is user's credentials.
> It's not even clear to me how externalizing the
> state (without breaking encapsulation i.e. no one
> else can see this externalized state) solves the OPs
> problem of retrieving the user credentials from many
> contexts.
Because the memento is passed along with the flow of control. i.e. It's a parameter pass through the domain object to the persistence mechanism.
> > Why would you need externalize the state of the
> user
> > credentials and connection in this situation?
>
> Externalised is this context refers to them being
> used by another class e.g. java.sql.Connection, not
> persisting them.
But that's easily accomplished through a simple association. Why do you need to externalize the internal state of the users credentials to do this?
> > What problem does that solve.
>
> Avoids the Domain object aquiring multiple
> responsibilities.
A simple association also does this.
> > As far as I can tell, the
> > OP is just trying to figure out where to store
> them.
>
> If with 'store' you mean which class to hold them. I
> agree.
Yes. Why does the internale state of the data need to be externalized?
> > You don't need to externalize the state to avoid
> > storing the credentials in many places.
>
> I disagree, but I think that is because you assume I
> mean persist which I don't.
No that has nothing to do with my question.
> In the Memento Pattern
> externalise means externalise properties from the
> object encapsulating them.
The point of the Memento Pattern is to externalize the internal state of an Object such that you can keep track of suceessive changes and reverse them. That doesn't apply here.
> I don't see anything about restoring state here.
>
> The state restored is user's credentials.
I think you sare missing the point of memento entirely. You seem to be using the term 'restore' to mean 'retrieve'. Are you expecting the users credentials to change and need to be reverted? If so, what would that have to do with the OPs requirements?
> > It's not even clear to me how externalizing the
> > state (without breaking encapsulation i.e. no one
> > else can see this externalized state) solves the
> OPs
> > problem of retrieving the user credentials from
> many
> > contexts.
>
> Because the memento is passed along with the flow of
> control. i.e. It's a parameter pass through the
> domain object to the persistence mechanism.
To my understanding, that's not the point of the memento pattern. It's much more involved than that. What you are describing is quite trivial. If you disagree please show me some sort of reference that explains how it does or at least explain how you could apply it to solve this problem in conrete terms.
> But that's easily accomplished through a simple association.
No it would not. An association is a static relationship, it would have the domain object using the same credentials or have some messy code to match each users' thead to their credentials.
> Why do you need to externalize the
> internal state of the users credentials to do this?
To preserve encapsulation.
> > Avoids the Domain object aquiring multiple
> > responsibilities.
>
> A simple association also does this.
But it doesnt meat the OP's primary requirement.
> > > As far as I can tell, the
> > > OP is just trying to figure out where to store
> > them.
> >
> > If with 'store' you mean which class to hold them.
> I
> agree.
>
> Yes. Why does the internale state of the data need
> to be externalized?
To preserve encapsulation.
> > In the Memento Pattern
> > externalise means externalise properties from the
> > object encapsulating them.
>
> The point of the Memento Pattern is to externalize
> the internal state of an Object such that you
> can keep track of suceessive changes and reverse
> them.
Yes.
>That doesn't apply here.
The only alternative to externalisation is to violate encapsulation and access them directly. You might find that acceptable I dont.
> > I don't see anything about restoring state here.
> >
> > The state restored is user's credentials.
>
> I think you sare missing the point of memento
> entirely. You seem to be using the term 'restore' to
> mean 'retrieve'.
No, the 'state restored' is the user credentials state restored to the persistence layer behind the Domain objects.
> Are you expecting the users
> credentials to change and need to be reverted?
Yes.
> If so, what would that have to do with the OPs requirements?
I am working on the domain/business layer has lots of domain objects. many of these domin objects aggregate to form other domain objects. Also in the application we have a class "User" that has the user information and privileges of the logged in "User."
Note: logged in user, not database user.
> To my understanding, that's not the point of the
> memento pattern. It's much more involved than that.
> What you are describing is quite trivial.
The memento is one of the most straight forward patterns.
> If you
> disagree please show me some sort of reference that
> explains how it does or at least explain how you
> could apply it to solve this problem in conrete
> terms.
The best source is the original GOF pattern.
Externalisation is an application of the Demeter principle.
http://en.wikipedia.org/wiki/Law_of_Demeter
> > But that's easily accomplished through a simple
> association.
>
> No it would not. An association is a static
> relationship,
That's absolutely incorrect.
"The association shows the relationship between instances of classes"
http://pigseye.kennesaw.edu/~dbraun/csis4650/A&D/UML_tutorial/class.htm
You can Google on UML Association and find many other sites that say the same thing,
> it would have the domain object using
> the same credentials or have some messy code to match
> each users' thead to their credentials.
I have no idea what you are on about.
> > Why do you need to externalize the
> > internal state of the users credentials to do
> this?
>
> To preserve encapsulation.
You don't need the memento pattern to do this.
> > > Avoids the Domain object aquiring multiple
> > > responsibilities.
> >
> > A simple association also does this.
>
> But it doesnt meat the OP's primary requirement.
Of course it does. How doesn't it?
> > > > As far as I can tell, the
> > > > OP is just trying to figure out where to store
> > > them.
> > >
> > > If with 'store' you mean which class to hold
> them.
> > I
> > agree.
> >
> > Yes. Why does the internale state of the data
> need
> > to be externalized?
>
> To preserve encapsulation.
What do you think externalized means in this context.
> > > In the Memento Pattern
> > > externalise means externalise properties from
> the
> > > object encapsulating them.
> >
> > The point of the Memento Pattern is to externalize
> > the internal state of an Object such that
> you
> > can keep track of suceessive changes and reverse
> > them.
>
> Yes.
>
> >That doesn't apply here.
>
> The only alternative to externalisation is to violate
> encapsulation and access them directly. You might
> find that acceptable I dont.
That's totally false. Unless you can explain how the memento pattern would be used here, I really don't think there is anymore to say. I've looked at the pattern a couple times since we started this discussion and nothing in it suggests it's applicable to this situation.
> > > I don't see anything about restoring state
> here.
> > >
> > > The state restored is user's credentials.
> >
> > I think you sare missing the point of memento
> > entirely. You seem to be using the term 'restore'
> to
> > mean 'retrieve'.
>
> No, the 'state restored' is the user credentials
> state restored to the persistence layer behind the
> Domain objects.
What does persistence have to do with this? Where would the credentials be retored from?
> > Are you expecting the users
> > credentials to change and need to be reverted?
>
> Yes.
To an out-of-date set of credentials? That doesn't seem very smart.
> > If so, what would that have to do with the OPs
> requirements?
>
> I am working on the domain/business layer has lots
> of domain objects. many of these domin objects
> aggregate to form other domain objects. Also in the
> application we have a class "User" that has the user
> information and privileges of the logged in
> "User."
So the question still stands, how does the Memento Pattern solve this?
> Note: logged in user, not database user.
Why are you bringing that up?
> > To my understanding, that's not the point of the
> > memento pattern. It's much more involved than
> that.
> > What you are describing is quite trivial.
>
> The memento is one of the most straight forward
> patterns.
And still is more than what is needed.
> > If you
> > disagree please show me some sort of reference
> that
> > explains how it does or at least explain how you
> > could apply it to solve this problem in conrete
> > terms.
>
> The best source is the original GOF pattern.
I have it. It doesn't say anything about this kind of problem.
> Externalisation is an application of the Demeter
> principle.
What do you think 'externalization' means in this context?
> > > I don't see anything about restoring state
> here.
> > >
> > > The state restored is user's credentials.
> >
> > I think you sare missing the point of memento
> > entirely. You seem to be using the term 'restore'
> to
> > mean 'retrieve'.
>
> No, the 'state restored' is the user credentials
> state restored to the persistence layer behind the
> Domain objects..
The state is the internal state of the user Object. You seem to be confusing this with getting the user Object. That's not restoring something. That's retrieving it. 'Restoring' the state would be, for example, after I remove an authorization from that user, readding that authorization authomatically.
I don't see anything in the OPs post saying there is a need to restore users to prior states. The only requirement is that they need the users credentials at the time of persistence. You don't need to externalize i.e. extract the User Object's internal state to do this. All you need to do is retrieve the User Object.
What advantage do you gain by externaliztng the internal state of the User Objects?
> > No it would not. An association is a static
> > relationship,
>
> That's absolutely incorrect.
Association are most definitely part of the UML static structure model. I suggest you read the Unified Modeling Language: Superstructure document from OMG. Page 660.
http://www.omg.org/docs/formal/05-07-04.pdf
> > it would have the domain object using
> > the same credentials or have some messy code to
> > match each users' thead to their credentials.
>
> I have no idea what you are on about.
The client (caretaker in the memento pattern) knows who its user is from their login. It passes these credentials to the domain model, which passes them to the persistence layer, which uses them to login.
If the persistence layer held those credentials it somehow has to find out who its current user is, lookup their credentials and use them. Messy (and a possible security hole).
> >
> > But it doesnt meat the OP's primary requirement.
>
> Of course it does. How doesn't it?
covered elsewhere.
> What do you think externalized means in this context.
covered elsewhere.
> > The only alternative to externalisation is to
> > violate
> > encapsulation and access them directly. You might
> > find that acceptable I dont.
>
> That's totally false. Unless you can explain how the
> memento pattern would be used here, I really don't
> think there is anymore to say. I've looked at the
> pattern a couple times since we started this
> discussion and nothing in it suggests it's applicable
> to this situation.
Then I suggest you go back and reread GOF it until you understand it and spend less time trolling other peoples threads.
> > > No it would not. An association is a static
> > > relationship,
> >
> > That's absolutely incorrect.
>
> Association are most definitely part of the UML
> static structure model. I suggest you read the
> Unified Modeling Language: Superstructure document
> from OMG. Page 660.
>
> http://www.omg.org/docs/formal/05-07-04.pdf
What does this have to do with this discussion? I never said it wasn't part of the static structure diagram. Classes are part of the static structure diagram. Does that mean they aren't useful either? It seemed to me that you thought associations were static (in the Java sense) and they are definitely not. If that wasn't what you meant, what was your point?
> > it would have the domain object using
> > the same credentials or have some messy code to
> > match each users' thead to their credentials.
>
> I have no idea what you are on about.
>
> The client (caretaker in the memento pattern) knows
> who its user is from their login. It passes these
> credentials to the domain model, which passes them to
> the persistence layer, which uses them to login.
Yes, that's what the OPs current design appears to do.
> If the persistence layer held those credentials it
> somehow has to find out who its current user is,
> lookup their credentials and use them. Messy (and a
> possible security hole).
How does the Memento Pattern fit in? How do you use it to solve this problem?
> > That's totally false. Unless you can explain how
> the
> > memento pattern would be used here, I really don't
> > think there is anymore to say. I've looked at the
> > pattern a couple times since we started this
> > discussion and nothing in it suggests it's
> applicable
> > to this situation.
>
> Then I suggest you go back and reread GOF it until
> you understand it and spend less time trolling other
> peoples threads.
I suggest that you don't go around telling people to use patterns you clearly don't understand. If you can't explain how this would be used, you don't know how. You are just talking out ouf your ss.
I understand the Memento Pattern. I've used it. I was involved in this thread as early as you were.
