Re: Yet another OO question...

It is a long time ago I had this question ...

I am a bit surprised because usually the problem is choosing the -
objects- (or classes), and I still think these should come first.

Your objects are the things that play an active role in your problem
statement. The confusing part of many examples is, is that people doe
not specify a problem. Without a problem you can not say if something
is an object, nor what kind of object. If you write a mortgage program
you might start out with a House object. However, it is unlikely you
need the width and height for this object because it has no role in
your problem domain. If you analyse further, you are likely to find
out that you get to a more abstract class that plays the role of thing
that is borrowed against. Its estimated value, ownership, etc are the
important qualities. However, if you model a house in a 3D program it
is likely you need much more details of its geometry and it is likely
that you do not care at all about its other house qualities. So most
important: first define your problem, then look for the actors.

Finding the objects is like writing a play. Who are the actors, how do
they interact. Objects allow you to minimize the complexity of a
program by simplifying the interaction between those objects. When you
design, I always like to push off the complexity. Lets say I design
method x on class X and need to interact with an object Y and Z. I try
to make x do as little as possible and forward any complexity that
requires knowledge about Y and Z to those classes. In my experience,
you then suddenly find out that you designed the system but are a bit
suspicious where the complexity went.

A crucial aspect in this is polymorphism. You do not always need
knowledge of a concrete class, an abstract trait of the class is
enough to be able to use it. Lets say you have a Printer interface (or
base class) and many subclasses. The key methods to render are
required to print are defined. However, on top of those primitive
methods you could add formatting, pagination, adding a first page,
etc. This is one of the key OO advantages, trying to do this in C, you
must use switch statements in many places. What you therefore often
see in C is that people create data structures with a pointer to a
function table: effectively creating an OO system. OO Languages like
Java have special constructs to make this very easy to do. It allows
you to add more concrete types later (like for example new printer
drivers).

So it all boils down to find a description of your program that
minimizes the interaction between the actors. The interactions are
your methods and the actors are your objects. However, keep thinking.
Minimizing complexity, reducing coupling, and increasing cohesion are
the most important things you want to achieve. Well, and it should of
course work ... And do not forget, an object is always related to a
perspective which should be your problem domain.

Hope this helps, kind regards,

Peter Kriens






On Mar 26, 8:57 pm, "ChrisW" <c.c.w...@xxxxxxxxx> wrote:
This might seem like a really stupid question, but I've realised that
one of the main problems I've got understanding OO (and teaching
myself) is that I don't actually know what to put into different
methods. I'm relatively happy doing basic procedural stuff, and I've
got a ~300 line program which I'm trying to make OO, but I don't know
where to start because I don't know where to split my program into
different methods (if that makes sense...). I'm about a third of the
way through Thinking In Java, and it's a lot better than most of the
other books I've read, but until I understand *what* to actually put
into a method I guess I'm not going to get very far! If anybody's got
any suggestions where I can get more info, or people can explain how
they got through this (surely everyone must go through this mind-set
when they start OO stuff, or do some people just get it naturally?!).
I can explain the program I'm trying to convert and / or post some
pseudo code if that helps,

TIA,
Chris


.