Re: Re: OO or just OOps ?

You write about a single class Orderconfirmer which all methods belong to.

Using a singleton gains little compared to

  my %obj;
  fetchdata(\%obj, type => all);
  fetchdata(\%obj, name => 'foo');
  createinvoice(\%obj, type => 'msword', name => 'foo);
[download]

IMVHO (v stands for very)

It is in fact how my abovementioned non-OO version was designed.

What I wanted was to put different things in different classes, having their own methods and accessors.

I guess 5-6 classes would seem resonably for this application, some classes would have just one instance and others like ORDER and ITEM would have plenty of instances, created and populated during data fetch. These instances would have to be accessed during the invoice building so there needs to be a way to access instances of other classes there.

And that was my real question from the beginning, even though I failed to communicate that.

The real problem is that I don't have any OO background, apart from Damians book, Perl toot and Perl boot, (thanks merlyn)

Anyway thanks for your input, things seem to demuddle as I try to explain myself.

Comment on Re: Re: OO or just OOps ? Download Code

Replies are listed 'Best First'.
Re: Re: Re: OO or just OOps ? by Anonymous Monk on Sep 24, 2002 at 03:00 UTC
Why are you going about this backwards? You can't figure out how to do an OO design. But you already know what you want to have in classes, how many classes you need, and so on. Where are you pulling these things from? Thin air? Lesson 1. OO programming works differently than procedural does. It is a different way of decomposing your problem space. Think of a machine. Procedural programming is like describing the sequence of actions that take place in a machine resulting in the action. OO programming is like describing what a screw is. Building on that to describe a hinge. And so on until you have a description of a machine that does useful stuff. So what components would be useful for you? What kinds of things would they do? Don't jump to how they might do them! Just focus on the components and their interfaces. Each type of component is a class, and the interface is its methods. The methods need not include accessors. Would you ask a door how it is made? Then why would you expect an object in an OO system to need to do so?	[reply]

Replies are listed 'Best First'.

Re: Re: Re: OO or just OOps ?
by Anonymous Monk on Sep 24, 2002 at 03:00 UTC

You can't figure out how to do an OO design. But you already know what you want to have in classes, how many classes you need, and so on. Where are you pulling these things from? Thin air?

Lesson 1. OO programming works differently than procedural does. It is a different way of decomposing your problem space. Think of a machine. Procedural programming is like describing the sequence of actions that take place in a machine resulting in the action. OO programming is like describing what a screw is. Building on that to describe a hinge. And so on until you have a description of a machine that does useful stuff.

So what components would be useful for you? What kinds of things would they do? Don't jump to how they might do them! Just focus on the components and their interfaces. Each type of component is a class, and the interface is its methods. The methods need not include accessors. Would you ask a door how it is made? Then why would you expect an object in an OO system to need to do so?

[reply]