Class diagrams - oo design

[Keith Godwin]

Hello all,

I'm new here and in fact very new to OO Design.

My first attempt is to design a contact management app. I'm reading a few books but there does seem to be a dark art arround what is 'right'.

So would you say this looks ok:



Specifically the use of inheritance with respect to the two tyes of address: contact and organisation which vary by their telephone number attributes. Should I use inheritance or some sort of a Map.

Any pointers (no pun) would be greatly appreciated.

cheers

Keith

ps I hope the image is ok.
[ November 25, 2008: Message edited by: Keith Godwin ]

[Brian Legg]

I always get confused when it comes to UML diagrams, lol. Is ContractAddress IS-A Address or HAS-A Address? As you can see I am fairly new as well.

[Keith Godwin]

ContactAddress IS An Address
OrganisationAddress IS An Address

They are both specializations of Address with differing Telephone attributes.

i.e. An Organisation has one main telephone line whereas a contact with have day time and evening telephone lines.

hope that's clearer.
[ November 25, 2008: Message edited by: Keith Godwin ]

[Nachiket Patel]

Whoa,
How much code is done??? Is this application already working??

I suggest, rather than telling you a story, just carefully go through this post.
https://coderanch.com/t/419376/patterns/OO-design

My views on your question.
Please understand, Class diagram is a part of design, not a design.

i think you provided all getter and setter for all the attributes. Nothing more. That is not OO way. It is indirect way of breaking encapsulation. You can find more about this getter and setter issue, just google it.

Try not to design upfront, keep refactoring your code and refining your design.

And, Welcome to JavaRanch.

Regards,
Nachiket

[Keith Godwin]

Originally posted by Nachiket Patel:
Whoa,
How much code is done??? Is this application already working??

No, I'm using net beans to make the class diagram, it put in the getters and setters.

I specifically wanted to know, in isolation, if I had an Address class could/should I create two specialized sub-classes if the difference between them was just two attributes.

From previous quote:

ContactAddress IS An Address
OrganisationAddress IS An Address

They are both specializations of Address with differing Telephone attributes.

i.e. An Organisation has one main telephone line whereas a contact will have day time and evening telephone lines.

I'm inclined to do away with the generalizations thus:

Contact Has An Address
Organisation Has An Address

Then define telephone attribute in the Address class to have attribute array of phone numbers.

what do you think?
[ November 26, 2008: Message edited by: Keith Godwin ]

[Andre Brito]

Hi.

Contact Has An Address
Organisation Has An Address

I guess that a good way to determine if this is valid or not is to thining like this: "Will this make my design more flexible?". I mean... Is this really necessary? When I say necessary, I'm saying like, How this is going to make your design more extendable and flexible?

Well, if you're subclasses have no atributes or have just "little things that doesn't matter", you don't have to create it. But sometimes, it's better to think in the future and, if you think that someday you'll need that superclass, you should create your subclasses.

I guess that it's hard to understand what I wrote... I'm sleepy and my english is a little dusty (better, a lot).

Hugs.

[Darya Akbari]

Originally posted by Nachiket Patel:
Try not to design upfront, keep refactoring your code and refining your design.

What do you mean by that ?

Of course you can not model requirements that still do not exist. But if you can model those requirements that already exists then go ahead and model them upfront.

[Nachiket Patel]

To darya,

Of course you can not model requirements that still do not exist. But if you can model those requirements that already exists then go ahead and model them upfront.

I think, Requirements of contact management application is clear only. So consider that we got all the requirements.
But,
I think if you are very well experienced and done lots of application designing and have a rock solid background in OO. Then yes. you can do all the design.

But, if you are fresh or beginner, not having extensive experience, then you will face problems [new/unknown or some ignored at design time] when coding happens, and which will force to change your design, and [keep in mind that you have already spent a lot of time in designing], now new design [change in design] may reflect other problems which were not there in older design.

There are few more things also, but i think Martin Fowler is far better teacher than me. you read Refactoring, by Martin Fowler.??
[ December 05, 2008: Message edited by: Nachiket Patel ]

[Darya Akbari]

Refactoring is nice but it doesn't help you with OO Design. OOAD is not hard, except you make it hard, but why?

Get a good book on that issue and become a master in object modeling. It's not hard at all.

I always recommend people the following non-expert-book:

[Nachiket Patel]

Sure, I'll definitely look at it. I love to read books on OOAD.

I am not the one who want to make it hard.

But i keep trying different methods of developing an application, although all the application are very small, [Supporting applications for our main application].
But, i found "refactoring" and "doing design while coding" very effective. Yes, it may be a case that the At the time i tried to design first, i was not much experienced.

So, Right now with my current personal practice, If you talk about designing application with clear requirements to me [and i am developing that application first time] , i'll start with main feature and implement one or two classes. [For sure, I'll make class diagram of all known domain entities, but those are not classes nor showing class relationship]

But as i said, i may give a shot to develop as you said [designing first approach], after reading this book or some other, if it will convince me.

please tell me some more things about this book.
I went through it's TOC, it looks interesting.
I don't think diagrams will be in UML, right?

Regards,
Nachiket
[ December 05, 2008: Message edited by: Nachiket Patel ]

[Darya Akbari]

Originally posted by Nachiket Patel:
Sure, I'll definitely look at it. I love to read books on OOAD.
...
please tell me some more things about this book.
I went through it's TOC, it looks interesting.
I don't think diagrams will be in UML, right?

The book teach you object modeling by five examples. Look the first example for free: Connie�s Convenience Store (A Point-of-Sale Application)

The diagrams are not UML but UML like. You should be aware that knowing UML doesn't make you a good object modeler. Being an UML master doesn't help you at all, simply because most people only understand 20% from UML. So why waste your time and create 100% UML?

[Nachiket Patel]

The diagrams are not UML but UML like. You should be aware that knowing UML doesn't make you a good object modeler. Being an UML master doesn't help you at all, simply because most people only understand 20% from UML. So why waste your time and create 100% UML?

yes, agreed. But when i claimed that UML makes you Object modeler.
I am one of that most of people, who knows only 20%.

Thats why, i am asking.. because I don't want to get into new set of notations.

And UML is better notation for OO then any other notations, Because of one and only one reason, and that it, it's standard and widely accepted.

[ December 08, 2008: Message edited by: Nachiket Patel ]
[ December 08, 2008: Message edited by: Nachiket Patel ]

[Darya Akbari]

Originally posted by Nachiket Patel:


yes, agreed. But when i claimed that UML makes you Object modeler.
I am one of that most of people, who knows only 20%.

Thats why, i am asking.. because I don't want to get into new set of notations.

And UML is better notation for OO then any other notations, Because of one and only one reason, and that it, it's standard and widely accepted.

If you know 20% of UML then you are fine to understand the notation in that book. The notation is UML like and is not important for understanding how to shape your domain object model.

Forget about the notation, have you taken a look at the sample chapter? That should give you a feeling what I'm talking about
[ December 08, 2008: Message edited by: Darya Akbari ]

[Alan Mehio]

Hi,
you mentione "Specifically the use of inheritance with respect to the two tyes of address: contact and organisation which vary by their telephone number attributes. Should I use inheritance or some sort of a Map."

So the only difference between them is that the contact has different telephone number attribute. If I were your, I will use Address for all type of addresses and the Address class is composite aggregation ( stronger relation) of Telephone which is an interface. If there is a way I can upload the image of what do I mean.
The Telephone has different implementation in this case. Which is for Org and for personal or mobile etc..


I used the composite rather then aggregation is based on my conceptual approach to consider Address as composing of Telephone, Zip, Street etc.. rather then aggregating them.

Regards,
Alan Mehio
London,UK

[Varun Chopra]

Specifically the use of inheritance with respect to the two tyes of address: contact and organisation which vary by their telephone number attributes. Should I use inheritance or some sort of a Map.

Prefer composition over inheritance. Do you need to inherit from Address? For e.g. do you have a requirement like 'Print all Addresses irrespective of their type'? If yes then inheriting from Address object can be useful, as you can play at Address object level. On the other hand if you always treat ContactAddress and OrganizationAddress separately, then compose an object of Address class in each. You will still have re-usability of code written in Address, and you won't have to worry about different attributes in these classes (as they have no common parent hence no relation).