Hi Guys,
I was going through a thread in this forum and there is one very good reply to this thread.
In the past Ive never used such techniques to idetntify how many classes would I create in my program, thus my programs used to be complex.
Can you suggest some more ideas like these on how to breakdown the requirements into classes and methods.
Hi, JC here again. Could you be referring to my prior post? If so. thank you.
In real life people use complex tools (UML modelling) to do this kind of thing, but for starters I would recommend keeping it simple and low-tech. I've used this technique many many times when mentoring teams on their first OO project:
1. Use the "underline the nouns" technique to get a candidate list of classes. Tidy up obvious duplicates etc, but don't try to get it perfect yet.
2. Get a load of cards or small sheets of paper, one per class, and write the name of one class at the top of each sheet.
3. Now use the "underline the verbs" technique to identify candidate methods and write those on the card for the class that seems most likely to be able to implement such a method.
4. Tidy up, but don't try to get it perfect yet.
5. (This is the fun bit). Look at the first scenario ("use case") as a whole. Spread all the cards out in front of you. Step through the use case identifying which methods in which classes need to get called by who to make it all happen.
You will immediately discover some missing classes, if only for the user interface. Write more cards for those. Eventually you should be able to step through a use case by following the complete trail of method calls through all the classes.
[At this stage you will have lots of stuff that goes like "action handler for OK button calls search method in database class to get the data then creates a new instance of a display form and call that to display the data"]
All the way through this you will keep finding things that are missing or that just don't work well, so keep refining and updating it.
6. Go through all the methods thinking about parameters and return values. Add these to the method names. Think about what other info those methods need to do their job - maybe add variables to the class, or more calls to lower-level methods. Run through the use cases again checking that when the methods are called, the calling class can supply the correct parameters and get the return value it really needs.
Quite often this will reveal that methods may even be in the wrong class, so move them and try again.
By now you will have a scruffy pile of much-corrected cards in front of you. But each card now represents a java class file, with all its important method signatures and variables. Now is the time to turn on the PC and type that all into your favourite Java editor. If you put a few "dummy" return statements into the methods you will probably be able to compile (but not yet execute) all that code. Congratulations. You now have an architecture for your app.
Simply fill in all the missing code, test and debug, document and ship.
If there's a single simple message behind all that it is: don't be in a hurry to start coding. Fixing an architecture error on a card takes 3 seconds. Fixing it in code takes many minutes.
(Wow, that must be my longest ever single DaniWeb post. I just happen to be stck somewhere at the moment with time on my hands).
We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.