in reply to OO or just OOps ?

How about your object doing something like returning your data structure ala:
    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...

Replies are listed 'Best First'.
Re: Re: OO or just OOps ?
by guha (Priest) on Sep 23, 2002 at 21:32 UTC

    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.

[reply]
[d/l]
      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]

In Section Seekers of Perl Wisdom