"bhaaluu" <[EMAIL PROTECTED]> wrote > Now I am interested in learning how to DESIGN an object-oriented > version
A useful distinction. You need to understand what classes are before you can use them but the art of desiogn is indeed different to the skills of construction > Can I use the procedural program as a specification? Yes, it defines input and required output. > However, I'd like to design the program so > it can be expanded in the future. > If I'm not mistaken, 'reuse' is a design criteria? Reuse is different to expansion of the existing design. But both are valid design criteria, and both are quite hard to do until you have some experience. Initially focus on just getting a set of objects that collaborate to give the right results. Then you can rework (or refactor to use the technical jargon) for reuse etc. One of the earliest ways of doing this has now fallen sonewhat out of favour but in practie I find it works quite well for beginners is: Describe the problem in plain English text(or whatever you language is!). Underline the nouns and separate into proper and common nouns. Common nouns are likely classes (although be careful to check for synonyms - the same class described by different nouns) while proper nouns are likely to be instances of classes (which classes may or may not be in your list of common nouns) Identify the common noun (class) that applies and add to your list. Now go through and identify the verbs and adjectives in the text. Assign each to a noun. Verns are potential methods of the classes and adjectives are potential attributes. The end result is a candidate set of classes with potential methods and attributes. Now try linking them together to identify relationships. Don't be surprised if not all classes are related to others - you will usuially identify more classes than you need and some classes will be "demoted" to attributes of other more significant classes. And a few attributes may get promoted to classes in their own right. Once you have your candidate classes pick a few that look like they will be core to the problem and try to work through some scenarios focussing on the interactions between the objects. At this point its often good to think of the objects in physical terms - as if you were building a mechanical model of the problem rather than a software version. What kinds of signals or messagews would you send to each object and how would each object interact with those around it Don't at this stage worry too much about inheritance. Focus on function. If you find that several classes have the same or similar methods then consider if they are sub types of an abstract superclass. Do NOT use data attributes for this, always base inheritance heirarchies on behaviour. Worth a try. It will miss many OOP tricks but as a starter methodology it is how millions of OOP programmers began. As you gain experience you will identify common abstract patterns. Once that starts then go and read the design patterns book by Gamma et al. Thats how I'd do it, I'm sure others will suggest other approaches. -- Alan Gauld Author of the Learn to Program web site http://www.freenetpages.co.uk/hp/alan.gauld _______________________________________________ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
