File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes OO, Patterns, UML and Refactoring and the fly likes OO - where to start Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "OO - where to start" Watch "OO - where to start" New topic
Author

OO - where to start

KOla Oyedeji
Greenhorn

Joined: Aug 28, 2001
Posts: 20
Hi
I am building an application for an estate agents and I'm not sure the best way to determine how objects are related. For example if I have a landlord object and a property object how should these be related? Some would say a property 'has a' landlord and therefore the landlord should be a member field. another way of looking at is a landlord may have multiple properties so properties could be stored as a field in the landlord object.
I would be grateful for any guidelines or pointers to resources on how to go about deciding relationships between objects or what should be an object. Thanks
ersin eser
Ranch Hand

Joined: Feb 22, 2001
Posts: 1072
Craig Larmans book: talks about GRASP ( patterns of general principles in assigning responsibilities )
Vladimir Ergovic
Ranch Hand

Joined: Apr 22, 2001
Posts: 63
I would say many to many.
So you can say something like this:

public class Landlord{
private Vector properites;
....
}
public class Props{
private Vector landlords;
....
}
So you will have all relations.

Vladimir Ergovic
KOla Oyedeji
Greenhorn

Joined: Aug 28, 2001
Posts: 20
I did think of this, after discussing it with someone else on another list I was told that this could lead to unneccesary complexity. Are there any practical problems with this?
Junilu Lacar
Bartender

Joined: Feb 26, 2001
Posts: 4679
    
    7

Sorry Vladimir, but I think that's a bad way to start off.
To reiterate ersin's advice: read Craig Larman's book. Larman writes "Attributes should not be used to relate conceptual classses in the domain model." Besides, just like in relational database design, many-to-many relationships should usually be simplified by using a go-between map to make the relationships 1-n on both sides.
Again, from Larman: "There are many ways to relate objects--foreign keys being one--and we will defer how to implement the relation until design, in order to avoid design creep."
Junilu
Originally posted by Vladimir Ergovich:
I would say many to many.
So you can say something like this:

public class Landlord{
private Vector properites;
....
}
public class Props{
private Vector landlords;
....
}
So you will have all relations.


Junilu - [How to Ask Questions] [How to Answer Questions]
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Larman writes "Attributes should not be used to relate conceptual classses in the domain model."

I don't think, the OP was asking about the domain model. I think he war more asking something like "Which parts of the domain model should be reflected as objects in the system and how should I implement their relations?" I might be wrong, of course...
Besides, just like in relational database design, many-to-many relationships should usually be simplified by using a go-between map to make the relationships 1-n on both sides.

I hope you didn't want to imply that your object model should be driven by database design... ;-)
Also, before using some map between landlords and properties I would like to analyze if the relation really is bidirectional. That is, for example, does a property really have to know about all 'their' landlords? And even if you answer this question "yes, sometimes" - perhaps it could ask the appropriate landlords wether itself applies to them when it needs to know?
That is, when thinking about an object model, I don't really care about "relationships" that much. Instead I do care about responsibilities and collaborations. That is, I don't care about wether a landlord "has a" property - for me the question is: What is the responsibility of a landlord and does it need the collaboration of a property to fullfill its responsibility?
Regards, Ilja


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Matts Smith
Ranch Hand

Joined: Feb 03, 2001
Posts: 113
I hope you didn't want to imply that your object model should be driven by database design

I've seen projects with so called top-notch object models fail because they were not taking into account the DB design. On the other hand the fastest app I've seen was using a 1to1 mapping between DB and object model.
I'm not saying a 1 to 1 mapping is always good. Still you need to consider DB design when modeling your objects. especially with work tables since you need to persist them.
Junilu Lacar
Bartender

Joined: Feb 26, 2001
Posts: 4679
    
    7

Originally posted by Ilja Preuss:
I hope you didn't want to imply that your object model should be driven by database design... ;-)

What I am trying to get at is that I have found that there is also some sort of "normalization" process when you do object modeling, same as when you do database design. During this normalization process, it helps to keep relationships simple and direct. Keeping m2m relationships out of the model is just one way of doing this. Makes it a lot easier to do O/R mapping later.
Junilu
Junilu Lacar
Bartender

Joined: Feb 26, 2001
Posts: 4679
    
    7

Originally posted by Ilja Preuss:
That is, when thinking about an object model, I don't really care about "relationships" that much. Instead I do care about responsibilities and collaborations. That is, I don't care about wether a landlord "has a" property - for me the question is: What is the responsibility of a landlord and does it need the collaboration of a property to fullfill its responsibility?

Good point, Ilja. This is actually the context from which the quote from Larman was taken. You should focus on the relationships/collaborations and responsibilities before you start looking at attributes. If you focus on attributes too early, you may unwittingly lock yourself into a specific solution. This is what I think Larman refers to as "design creep". Worse still, by prematurely locking yourself into a specific solution, you will likely create a mental "screen" that will keep you from seeing other possible solutions.
Junilu
[This message has been edited by JUNILU LACAR (edited December 20, 2001).]
KOla Oyedeji
Greenhorn

Joined: Aug 28, 2001
Posts: 20
This is another thing I've always wondered about. How does java 'work with databases' assumuing you have a database that may be accessed by other applications such as a website or vb application, how do you map object fields to database feilds?
Thanks
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Matts Smith:
I've seen projects with so called top-notch object models fail because they were not taking into account the DB design.

Interesting - could you elaborate on this? Where did the problems emerge?
Matts Smith
Ranch Hand

Joined: Feb 03, 2001
Posts: 113
Originally posted by Ilja Preuss:
Interesting - could you elaborate on this? Where did the problems emerge?

Basically, when the application persisted the data in the database, since the object model was so far away from DB design the persistence classes where not cohesive and tightly coupled. It led to maintenance nightmares. The architect got fired on that particular project... In practice, read-only data (lookup tables) should be accessed by cache objects (see Grand98 page 251) and work tables by EJBs because of easy transaction management (no entity beans please) whenever possible. My favorite way of doing it is SLSB calling DAOs. It might lead to poor design over time but in the project I've worked in it never got close to unmanageable. this is on 150+ tables in a schema.
Junilu Lacar
Bartender

Joined: Feb 26, 2001
Posts: 4679
    
    7

Originally posted by Matts Smith:
Basically, when the application persisted the data in the database, since the object model was so far away from DB design the persistence classes where not cohesive and tightly coupled. It led to maintenance nightmares. The architect got fired on that particular project...

I've seen this happen, too, only the architect got promoted
classic "Dilbert", I tell you.

Junilu

Pho Tek
Ranch Hand

Joined: Nov 05, 2000
Posts: 761

I read somewhere that you should let your domain model dictate the database model; not the other way round.
Pho


Regards,

Pho
Matts Smith
Ranch Hand

Joined: Feb 03, 2001
Posts: 113
Originally posted by Pho Tek:
I read somewhere that you should let your domain model dictate the database model; not the other way round.
Pho

This is in an utopic world. In the real world most companies already have a database designed. Unless you start from scratch, you definitely have to consider the DB design
Todd Newbold
Ranch Hand

Joined: Sep 20, 2001
Posts: 85
Remember the 3 main features of 00:
encapsulation - private implementation, public interface
inheritance - is-a relationship
polymorphism - implementation based on type
David Weitzman
Ranch Hand

Joined: Jul 27, 2001
Posts: 1365
I would say that Landlords own property and property is oblivious to everything. I'm thinking in terms of responsibilities. Is property responsible for anything? What methods would it have? Property can have value, so there might be getValue() and setValue(). Does property obtain landlords or do landlords obtain property? Clearly the latter. 'Obtain' is a verb the will eventually be translated into a method, Landlord.addProperty(). It is more important that you be able to determine what properties a landlord owns than what landlords own a property (taxes are payed by landlords, not properties). 'Owns' is a good word for this. Property has a landlord, but it doesn't own a landlord.
This is a look at a very specific case of course, but it can apply anywhere. Think of the actions and changes a system will undergo and what object is responsible for carrying out those actions. If you don't get it right the first time, your code will probably exhibit some of the 'bad smells' described in Refactoring. You can fix the relationships as you refactor.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: OO - where to start