NEWBIE: Is this a proper class design? 5

[DeanConsulting]

Hello,

I am new to OOP programming and struggling a little. So, please be easy on me.

I want to design a small software application that keeps track of a user's software keys. The program will be able to add, edit, and delete keys from a file. The data for a key will be: title, version, purchase date, key1, key2, author, and contact.

I want to do this in Java. I am not so much interested in the code to do it rather I am interested in how to create classes and objects.

Here is what I have come up with: (Comments/Suggestions please)

Class:
softtitle

Properties: name,version,purchaseDate,key1,key2,author,contact

Methods:
saveTitle(),loadTitle(),deleteTitle(),displayTitle()

Is this even close to being right or am I not grasping the concepts of OOP yet?

Thanks in advance,
Noble





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

http://www.noblesoftware.com

http://www.noblebell.com

 

[cpjust]

If you want this to be a GUI based program (or even console for that matter), you'll need more than 1 giant "do it all" class.
Try breaking it down further into a class that reads/writes the data from the file, a class for the data that is read or written to the file, a class for the GUI...

 

[DeanConsulting]

Thanks for your input, cpjust. That is what I am talking about. Is there some rule to creating classes so that I don't always end up with a giant, "do it all", class??

nb


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

http://www.noblesoftware.com

http://www.noblebell.com

 

[cpjust]

Yes -- break large problems down into a bunch of smaller ones, and keep breaking them down smaller until you can't go any farther.
One method that textbooks like to promote is writing down the problem in English (or whatever your native language might be) and explaining how you want the program to work. Then look through what you wrote and look for nouns -- those nouns will usually indicate the need for a class. Then look for verbs -- they will indicate the functions that those classes will perform.
You might also want to look into UML. It's a diagram meta-language (kind of like flow charts on steroids) that people use to design their classes visually.

 

[DeanConsulting]

Does anyone know of any UML software that I could get for free? I am sure that there is something out there. I have Viso at work and it does some uml but I need something for home.


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

http://www.noblesoftware.com

http://www.noblebell.com

 

[stevexff]

Try ArgoUML. Just Google it for the website. Eclipse is supposed to have some modelling extensions but I've never tried them.

There aren't many free ones...

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]

You want to look into the concepts of cohesion and coupling. Basically, a class should have tight cohesion and loose coupling. This means that a class should stick to doing one thing well, and not have to communicate a great deal with other classes to accomplish its purposes.

Now, then. If your class has a great deal of internal decision logic (as a "do it all" class would), much of its overhead is taken up in deciding what to do. This represents a problem with cohesion. Consider refactoring the class into several classes, each of which is more focused on a specific purpose. If there are excessive back and forth calls between associated classes, consider pulling them together into one class, evaluating as you do any increase in decision logic.

This should give you a general rule of thumb. For further reading (LOTS of further reading), the prime reference for all things OOAD is

http://www.cetus-links.org.

HTH

Bob

 

[BobRodes]

A good book on UML is "the UML Bible" by Tom Pender.

 

[DeanConsulting]

I will look into those links. Thanks Bob.


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

http://www.noblesoftware.com

http://www.noblebell.com

 

[DeanConsulting]

I will check that software out too, Steve. Thanks.


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

http://www.noblesoftware.com

http://www.noblebell.com

 

[stevexff]

Fowler's UML Distilled is a good pragmatic introduction to UML. It doesn't pretend to cover the whole UML, just the most useful bits. Make sure you get the latest edition.

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]

Yes, that's an excellent book, and there are many well-thumbed copies. There are two main differences between that one and Pender's book:

1. Fowler's tries to distill UML concepts and does an excellent job, Pender goes into exhaustive detail and also does an excellent job.

2. I wasn't a technical editor on Fowler's book. ;-)

Bob

 

[stevexff]

Honesty. Always the best policy...

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 agree with you there, Steve. All kidding aside, I read most of Pender's book before I agreed to work on it, and I worked on it because I thought it really was a very good book.

 

[grooke]

I have come to this a bit late, but am concerned about some of the answers. They are all good, but they are pushing the concepts well beyond the question. The question was whether DeanConsulting has approached it correctly.

My answeris that they have done an almost perfect job. 9.8/10 for the example they gave.

They wrote an English description:
"... a small software application that keeps track of a user's software keys. The program will be able to add, edit, and delete keys from a file. The data for a key will be: title, version, purchase date, key1, key2, author, and contact."

The class name is a bit naff. This is a small but important point. Your English calls it 'Software keys" and the class is called 'Softtitle'. Why not call it 'SoftwareKey'.
Firstly, my mother, very literate but NOT a techie, would understand the second name but would hesitate at your one. I couldn't find in the dictionary either. This is a huge mistake made by most modellers. They want to invent new names that other people will find hard to remember, particularly when there may be hundreds of them. If 'Software keys' are what you are describing, why not call them 'SoftwareKey's. I have seen a huge projects halved in size by getting that right.
Secondly, by using the word 'Title' in the class name, you felt obliged to change the English 'Title' into 'name'. You must decide what it is your are modelling, and what that first attribute really really is. Then call them that.
When I look back, the class you describe contains keys (plural) and other things. Would it be better to call it something like 'SoftwareRecord' or 'SoftwareCatalogueEntry' or 'SoftwareKeyRecord'. I might like to keep the Username needed for support and the password in it as well. Then I think that 'keys' would be totally wrong. Maybe SoftwareDetails'.
Why only software? My ISP broadband box has an Id theat the ISP people want quoted as well as a username and password. My fire safe has combination keys. So maybe it is better to not restrict it, because the internal data is not restrictive. Perhaps 'KeyDetails'?

Whatever you do, I want my mother to be able to understand it. This is NOT coding. This is high level Documentation that your CEO, Finance Director and others should understand. In UML, part of the class diagram is the 'Business Domain'. It should model the business and names of things are part of the business.
Above all, keep consistency. Is it a 'title' or is it a 'name'?

The other 0.1 marks went on not having a 'view' function. I guess, you think that the 'edit' one doubles as this. If so fine, but always start with all four concepts. The point of having the program seems to be so that you can find the keys for a program accessed by title. Version, Purchase Date, Author etc, are for secondary use. So maybe you have two views: one the title and Keys, and the other as for editing.

You were advised to produce display objects. This is probably overkill in this situation. But taking their point, now you have two object classes, either of which can be displayed. One is 'KeyDetails' and the other is 'IdentifiedKeyValues'; this last one only contains title and
and keys. But dont create Display classes unless they are required. This example is totally atypical because of its simplicity; most examples do need them.

Finally, there is an excellent free IDE with an excellent UML tool provided by Sun. It is called 'Java Studio Enterprise 8'.

http://developers.sun.com/prodtech/javatools/jsenterprise/index.jsp

Better than Rational Rose, a bit better than Visio, and may be better than Rational Software Modeller, not quite as good as Visual Paradigm. But it is free.

Gil

 

[dragonwell]

Good point, Gil. This sounds like what the domain driven folks call ubiquitous language.

 

[grooke]

Now you have introduced me to a new term?

I favour domain driven approaches, and I have never seen the real need for changing the name of something just to be different. So yes it is.

I watched a huge project for a web site, Enjoy England', collating all the UK tourists sites under one web site. The project manager could never enforce any standard UML approach and so decided that he would make a complete class model and insist that everyone from the coders to the Brochure writers used the same terminology. Some names took over half a day to agree, but if it was NOT agreed, then it was NOT included. He believes that this alone probably halved the cost of the project. I dont think he knew it was called UbiquitousLanguage either ;-)

Gil

 

[BobRodes]

Excellent point about semantics, Gil. Another recommendation is to keep a dictionary of the semantics of the problem domain, such that once everyone agreed on a term as you describe, it went into a dictionary or glossary. No doubt the manager in the story you relate did precisely that, but it's important to do so I'm pointing it out anyway.

Bob

 

[grooke]

Actually Not. He put the names on the classes and that made people read the class diagrams.
I agree with him. We put use case descriptions and lots of other things belonging to UML outside the UML tool. This has two problems:
1. You are then maintaining two sets of the same information. (High cost)
2. WHEN the do get out of step, the simpler more widely published glossary is given the status of TRUE. Then UML is NOT true and programmers, thinking that it is NOT true, decide to draw their own versions.

My view is that definitions, and business rules should ALL be put ONLY in the UML. Then write a UML report that produces a Glossary and Business Rules document at appropriate intervals.

Only one copy of any information. That is the point of my other article on Agile Analysis. You dont actually need a Spec. You have one description of the system in UML and provide the business with either copies of that or simplified reports. Then the designers etc are working from that same model. Finally, stop the programmers from redrawing every thing again, and you suddenly cut costs dramatically. At EDS, I counted four class diagrams all at the same level and all contradicting oneanother. EDS are not alone.

Gil

 

[BobRodes]

<definitions, and business rules should ALL be put ONLY in the UML.

Yes, well, maybe, but I'm not sure I see how. So, what's a "UML Report"? I'm unfamiliar with it as an "official" artifact in the UML spec. Is it such, or is it something else?

Bob