• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

OO - where to start

 
KOla Oyedeji
Greenhorn
Posts: 20
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 1072
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Craig Larmans book: talks about GRASP ( patterns of general principles in assigning responsibilities )
 
Vladimir Ergovic
Ranch Hand
Posts: 63
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
KOla Oyedeji
Greenhorn
Posts: 20
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Pie
Posts: 7749
60
Android Eclipse IDE IntelliJ IDE Java Linux Mac Scala Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.

 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
Matts Smith
Ranch Hand
Posts: 113
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Pie
Posts: 7749
60
Android Eclipse IDE IntelliJ IDE Java Linux Mac Scala Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Pie
Posts: 7749
60
Android Eclipse IDE IntelliJ IDE Java Linux Mac Scala Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 20
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 113
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Pie
Posts: 7749
60
Android Eclipse IDE IntelliJ IDE Java Linux Mac Scala Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 782
Chrome Python Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I read somewhere that you should let your domain model dictate the database model; not the other way round.
Pho
 
Matts Smith
Ranch Hand
Posts: 113
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 85
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 1365
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic