[Tutor] designing POOP

bhaaluu bhaaluu at gmail.com
Wed Feb 6 11:24:22 CET 2008


On Feb 5, 2008 3:02 PM, Alan Gauld <alan.gauld at btinternet.com> wrote:
>
> 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.

This sounds like a good suggestion! I've already started, and have a rough
draft. I still need to knock the rough edges off the description. How
detailed do you make your description? Do you write an overview
that isn't very detailed, or do you describe every detail you can
think of? (My rough draft is quite detailed because I have just finished
writing the procedural program, and have all the details in my head.)

Actually, writing a description of the problem in Plain English is part
of designing any computer program (according to some old programming
texts I have). This is why beginning computer programmers should stay
awake in English class, and pay attention to grammar!

> 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.

Noted: "potential"

>
> 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.

I had a 'testing' directory when I wrote the procedural version of the
program. I tested snippets of code to see if they would work, before
putting them in the main program. I can see that a similar 'testing'
directory will be well used when designing this POOP version. 8^D

> 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

This is why I chose the Text Adventure Game as a learning program.
It is full of objects that can be thought of in physical terms! I'm not
quite clear how they will message each other (yet), but that will
probably become clearer as I work through this.

> 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.

Noted.

> 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.

This is exactly the kind of thing I was looking for....
I'm sure I'll have more questions as I go along.

> 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

Thank you Alan!
Happy Programming!
-- 
b h a a l u u at g m a i l dot c o m
"You assist an evil system most effectively by obeying its
orders and decrees. An evil system never deserves such
allegiance.  Allegiance to it means partaking of the evil.
A good person will resist an evil system with his or her
whole soul." [Mahatma Gandhi]


More information about the Tutor mailing list