NEWBIE: Class Design Update

[DeanConsulting]

A few months ago I asked a question about getting a design right. I got several great answers but had to put every thing on hold for a couple of months.

I would like some comments/suggestions on the following "class diagram" that I am trying to create.

Statement:
Keep up with contact information which includes name,address,city,state,zip,phone,and email. You will be able to add,edit,delete contacts from a database. You can also print the entire contact list. The program will be a GUI program written for Windows using C#.

Nouns(Classes)
--------------
contact
name
address
city
state
zip
phone
email
database
gui

Verbs(Methods)
--------------
Add
Edit
Delete
View
Print
Save
Load

This is what I have designed so far:

Class: Contact
Properties: name
Methods: GetName,SetName,add,edit,delete

Class: Address
Properties: address,city,state,zip,phone,email
Methods: GetAddress,SetAddress,GetCity,SetCity,GetState,SetState,GetZip,SetZip,GetPhone,SetPhone,GetEmail,SetEmail

Class: Database
Properties: connectionString
Methods: Save,Load,Print

Class: GUI
Properties:txtName,txtAddress,txtCity,txtState,txtZip,txtPhone,txtEmail,btnAdd,btnEdit,btnDelete,btnPrint,List:Contacts
Methods: DisplayContact(Contact)

My question, am I even anywhere close to doing this right?

nb








---------------------------------------
Noble D. Bell

http://www.noblesoftware.com

http://www.noblebell.com

 

[cpjust]

I remember doing this same project in my grade 10 computer science class, except back then it was on DOS and written in C.

I believe Contact should contain the following members:
name
address
city
state
zip
phone
email

And I don't think Add, Edit & Delete belong in Contact; that sounds more like a job for the database. A Contact is just a collection of information.

All of the methods look like they'd also be good to have in the GUI.

 

[stevexff]

I'm not normally a fan of Doing The Simplest Thing That Could Possibly Work[sup]TM[/sup] but in this case it is justified. As cpjust notes, there is no benefit in making Address a separate class unless you think that multiple contacts might need to share the same address. Probably more trouble than it's worth.

That leaves you focusing on a Contact class (the Model), a GUI class (the View), and a controller class (the Controller). Then Google "MVC pattern".

Steve

[small]"Every program can be reduced by one instruction, and every program has at least one bug. Therefore, any program can be reduced to one instruction which doesn't work." (Object:erlDesignPatterns)[/small]

 

[DeanConsulting]

Interesting. I don't think that I will ever get a good handle on this stuff. I come from the old world of top-down design and am trying to learn a good solid foundation in oop. I want to use Java and C#. Don't really know why other than I think each are pretty cool if not one in the same. I have also been looking into SmallTalk too.

But, I still have to get this OOP stuff down before tackling the language syntax.

It does feel more comfortable to do away with the address class and add it back into the contact class. It also feels right to have the "add,edit,delete,print" in the database class. I am unclear on what else needs to go into the GUI class other than a "View" method.

Thanks for your answers and your patience. I'll get it eventually.

nb


---------------------------------------
Noble D. Bell

http://www.noblesoftware.com

http://www.noblebell.com

 

[stevexff]

Java and C# are more commercially attractive. C# has the benefit of being the newest, and has been able to learn from the mistakes of those that have gone before. But Java will run on more OSes, whereas C# is Windows only (unless you count Mono, but AFAIK this is 1.1 support only).

Back to your classes, the main thing to remember is to allocate the responsibility to the right place. The model objects represent the 'business' nouns in your system. The view gets information from the model objects, and renders them for the user. The user interacts with the screen controls on the view, which send events to the controller. The controller uses this information to update the model objects, and the view is redisplayed.



Steve

[small]"Every program can be reduced by one instruction, and every program has at least one bug. Therefore, any program can be reduced to one instruction which doesn't work." (Object:erlDesignPatterns)[/small]

 

[DeanConsulting]

@Steve: So the "controller" class is actually like a database class?



---------------------------------------
Noble D. Bell

http://www.noblesoftware.com

http://www.noblebell.com

 

[stevexff]

Not really. But it may make use of database related classes. Because of the hassle of writing data access code, (Should my business objects know how to persist themselves? In my constructor, where does the primary key come from? Do I have to add all that persistence code to every business object? etc. etc.) many people use an object-relational mapping layer such as Hibernate (NHibernate on .NET) to manage the persistence of objects. This allows you to design your business objects freely, and let the persistence layer worry about the database plumbing.

Steve

[small]"Every program can be reduced by one instruction, and every program has at least one bug. Therefore, any program can be reduced to one instruction which doesn't work." (Object:erlDesignPatterns)[/small]

 

[BobRodes]

>I don't think that I will ever get a good handle on this stuff

Deanc, the process is iterative. Go from a rough whack to increasingly smaller refinements until you have things the way that you feel they ought to be.

I would read up on the concepts of "cohesion" and "coupling", keeping these two goals in mind as you go through your iterations.

You may find that these "forest level" concepts keep you out of the weeds.

HTH

Bob

 

[DeanConsulting]

Yes, thank you Bob. I will look into those concepts this weekend.I like staying out of the weeds! You never know what's in there!!

nb



---------------------------------------
Noble D. Bell

http://www.noblesoftware.com

http://www.noblebell.com