The point of OO is to take the "objects" of your problem, and represent them in your program as "Objects" with behavior and state, and to also capture similarities of object behavior in an inheritance hierarchy for code reuse.

So, no, one nested hash does not a candidate for Objects make. {grin}

-- Randal L. Schwartz, Perl hacker

Well,
I thought I wanted Client to be an class, with accessors for the attributes and then have several instances of them, one for each client.

The same for orders and items

Perhaps a class for konfiguration data instead of globals floating around

And then to avoid redundancy the TYPE could be "class"-ifyed

I known my post is muddy at best, but what I was trying to avoid is that the communication between objects would nessitate having to juggle several objects of different classes to perform the action.

As an example consider selecting what media a certain client wants his confirmation, which would be found in the client instance and pertinent data would also be found in the configuration instance.

And yeah I know, messed up design, but that was really the reason for my question

I am sorry but I don't understand the first statement. I know I am (much) less experienced then you but I thought people often encapsulate data in objects and use accessor methods to get at the data. The accessor methods provide verifcation of data structure over and above what the use of datatypes can provide.

With all due respect,

--blm--

That would be "procedural programming with objects".

You can find much better approaches out there. (Yeah, it is in Java. Take good advice where you find it.)

    my $obj = Orderconfirmer->new;
    $obj->fetchdata(type => all);
    $obj->fetchdata(name => 'foo');
    $obj->createinvoice(type => 'msword', name => 'foo);
[download]

What youre doing is creating an interface for anothoer prgy to use. The advantage is that you have "abstraction". You create all the business logic in one script, encapsulate your data fetching/processing in another script, so when your backend changes, you re-write your OO module (being careful to preserve the interface you've defined) and dont have to touch your business logic.

Of course in the above example you can abstract further, having one module fetch all the data from a database, and the other module build your word/pdf/whatever invoices.

So an object has methods, the methods do *something*, they can do whatever you program them to do. An object also has attributes, these attributes are things like "name". A method can use an attribute to to its processing, using the above example, the fetchdata method uses the attribute of name to define what to search for...

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.

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?

I'd like to order such a "bar stimulator", please.. >;)