http://www.perlmonks.org?node_id=317520


NAME

Often Overlooked Object Oriented Programming Guidelines


SYNOPSIS

The following is not about how to write OO code in Perl. There's plenty of nodes covering that topic. Instead, this is a general list of tips that I like to keep in mind when I'm writing OO code. It's not exhaustive, but it does cover a number of areas that I see many people (including myself), get wrong or overlook.


PROBLEMS

Useless OO

  • Don't use what you don't need.
  • Don't use OO if you don't need it. No sense in creating an object if there is nothing to encapsulate.
    sub new { my ($class,%data) = @_; return bless \%data, $class; }

    This constructor is not unusual, but it's suggestive of a useless use of OO. A good example of this is Acme::Playmate (er, maybe not the best example). The module is comprised of a constructor. That's it. And here's the documented usage:

    use Acme::Playmate; my $playmate = new Acme::Playmate("2003", "04"); print "Details for playmate " . $playmate->{ "Name" } . "\n"; print "Birthdate" . $playmate->{ "BirthDate" } . "\n"; print "Birthplace" . $playmate->{ "BirthPlace" } . "\n";

    Regardless of whether or not you feel this is a useful module, there's nothing OO about it. In fact, with the exception of methods this module inherits from UNIVERSAL::, it has no methods other than the constructor. All it does is return a data structure that just happens to be blessed (the jokes are obvious; we don't need to go there).

    Of course, this is merely an Acme:: module, so discussing how well a joke conforms to good programming practices is probably not warranted, but read through Damian Conway's 10 Rules for When to Use OO to get a good feel for when OO is appropriate.

Object Heirarchy

  • Don't subclass simply to alter data
  • Subclass when you need a more specific instance of a class, not just to change data. If you do that, you simply want an instance of the object, not a new class. Subclass to alter or add behavior. While I don't see this problem a lot, I see it enough that it merits discussion.

    package Some::User; sub new { bless {}, shift; } sub user { die "user() must be implemented in subclass" } sub pass { die "pass() must be implemented in subclass" } sub url { die "url() must be implemented in subclass" }

    On the surface, this might appear to simply be an interface that will be used as a base class for a set of classes. However, sometimes people get confused and simply override those methods to return data:

    package Some::User::Foo; sub user { 'bob' } sub pass { 'seKret' } sub url { '<a href="http://somesite.com/">http://somesite.com/</a +>' }

    There's really no reason for that. Make it an instance:

    my $foo = Some::User->new('Foo');

    Thus, if you need to change how things work internally, you're doing that on only one class rather than hunting through a bunch of useless subclasses.

  • Law of Demeter
  • The Law of Demeter simply states that you should only talk to your immediate friends -- using a chain of method calls to navigate an object heirarchy is begging for trouble. For example, if an office object has a manager object, an instance of that manager might have a name.
    print $office->manager->name;

    That seems all fine and dandy. Now, imagine that you have that in 20 places in your code, but in the manager class, someone changes name to full_name. Because the code using the office object was forced to walk through the object heirarchy to get at the data it actually needs, you've created fragile code. Now the manager class must support a name method to be backwards compatible (and we get to start on our big ball of mud), or every reference to it must be changed -- but we've created far too many.

    The solution is to do this:

    print $office->manager_name; # manager_name calls $manager->name

    Now, instead of hunting down all of the places where this was accessed, we've limited this call to one spot and made maintenance much easier. This can, however, lead to code bloat. Make sure you understand the tradeoffs involved.

  • Liskov substitution principle
  • While there is disagreement over what this means, this principle states (paraphrasing) that a subclass must present the same interface as its superclass. Some argue that the behavior or subclasses (or subtypes) should not change, though I feel that with proper encapsulation, this distinction goes away. For example, imagine a cash register program where a person's order is paid via a combination of credit card, check, and cash (such as when three people annoy the waiter by splitting the bill).
    foreach my $tender (@tenders) { $tender->apply($order); }

    In this case, let's assume there is a Tender::Cash superclass and subclasses along the lines of Tender::CreditCard and Tender::LetsHopeThisDoesntBounce. The credit card and check classes can be used exactly as if they were cash. Their apply() methods are probably different internally, but every method that's available for cash should be available for the subclasses and data which is returned should be identical in form. (this might be a bad example as a generic Tender interface may be more appropriate).

    Another example is HTML::TokeParser::Simple. This is a drop-in replacement for HTML::TokeParser. You don't need to change the actual code, but you can then use all of the extra nifty features built in.

Methods

  • Don't encourage promiscuous behavior
  • Hide your data, even that data which is public. Provide setters and getters for properties (accessors and mutators, if you prefer), rather than allowing people to reach into the object. Use these internally, too. You need them as much as users of your code need them.
    $object->{foo};

    This is a common idiom, but it's an example of an anti-pattern. What happens when you want to change that to an array ref? What happens when you want to use inside-out objects? What happens when you want to validate an assignment to this value?

    All of these issues and more crop up when you let people reach into the object. One of the major points of OO programming is to allow proper encapsulation of what's going on inside of the object. As soon as you let your defensive programming guard down, you're going to get bug reports. Use proper methods to handle this:

    $object->foo; $object->set_foo($foo);

  • Don't expose state if you don't have to.
  • if ($object->error) { $object->log_errors } # bad!

    Whoops! Now we have a problem. Not only does every place in the code that might want to log errors have to first check if those errors exist, your log_errors method might erroneously assume that this has been checked. Check the state inside of the method.

    sub log_errors { my $self = shift; return $self unless $self->error; $self->_log_errors; }

    Better yet, there's a good chance that you're not concerned about the error log at runtime, so you could simply specify an error log in your constructor (or have the class use a default log), and let the module handle all of that internally.

    sub connect { my $self = shift; unless ($self->_get_rss_feed) { $self->_log_errors; $self->_fetch_cached_copy; } $self; }

    In the above example, there's an error that should be noted, but since a cached copy of data is acceptable, there's no need for the program to deal with this directly. The object notes the problem internally, adopts a fallback remedy and everything is peachy.

  • Keep your data structures uniform
  • (I saw this on use.perl but I can't remember who posted it)

    Assuming that a corresponding mutator exists, accessors should return a data structure that the mutators will accept. The following must always work:

    $object->set_foo( $object->get_foo );

    Failure to do this will cause no end of grief for programmers who assume that that the object accepts the data structures that it emits.

Debugging

  • $object->as_string
  • Create a method (be cautious about overloading string conversions for this) to dump the state of an object. Many simply use YAML or Data::Dumper, but having a nice, human readable format can mean a world of difference when trying to debug a problem.

    Here's the YAML dump of a hypothetical product. Remember that, amongst other things, YAML is supposed to be human-readable.

    --- #YAML:1.0 !perl/Product bin: 19 data: category: 7 cost: 2.13 name: Shirt price: 3.13 id: 7 inv: 22 modified: 0

    Now here's hypothetical as_string() output that might be used in debugging (though you might want to tailor the method for public display).

    Product 7 Name: Shirt Category: Clothing (7) Cost: $2.13 Price: $3.13 On-hand: 22 Bin: Aisle 3, Shelf 5b (19) Record not modified

    That's easier to read and, by doing lookups on the category and bin ids, you can present output that's easier to understand.

  • Test
  • I've saved the best for last for a good reason. Write a full set of tests! One of the nicest things about tests is that you can ask someone to run them if they submit a bug report. Failing that, it's a perfect way to ensure that a bug does not return, that your objects behave as documented and that you don't have ``extra features'' that you weren't expecting.

    One of the strongest objections to OO perl is the idiomatic object constructor:

    sub new { my ($class, %data) = @_; bless \%data => $class; }

    Which can then be followed with:

    sub set_some_property { my ($self, $property) = @_; $self->{some_prorety} = $property; # (sic) return $self; } sub some_property { $_[0]->{some_property} }

    And the tests:

    ok($object->set_some_property($foo), 'Setting a property should su +cceed'); is($object->some_property, $foo, "... and fetching it should a +lso succeed");

    Because blessing a hash reference is the most common method of creating objects in Perl, we lose many of the benefits of strict. However, a proper test suite will catch issues like this and ensure that they don't recur. On a personal note, I've noticed that since I've begun testing, I sometimes forget to use strict, but my code has not been suffering for it. In fact, sometimes it's better because I frequently write code for which strict would be a hassle, but that's another example of where the rules get broken, but they're broken because the programmer knows when to break them.

    Yet another fascinating thing about tests is the freedom they give you. If you have a comprehensive test suite, you can start taking liberties with your code in a way that you haven't before. Are you having performance problems because you're using an accessor in the bottom of a nested loop? If the object is a blessed hashref, you might get quite a performance boost by just ``reaching inside'' and grabbing the data you need directly. While many will tell you this is a no-no, the reason they mention this is for maintainability. However, a good test suite will protect you against many of the maintainability problems you may face (though it still won't make fixing your encapsulation violations any easier once you are bitten).

    That last paragraph might sound a bit curious. Is Ovid really telling people it's OK to violate encapsulation, particularly after he pointed out the evils of it?

    Yes, I am saying that. I'm not recommending that, but one thing that often gets lost in the shuffle when ``paradigm'' flame wars begin is that programming is a series of compromises. Rare indeed is the programmer who has claimed that she's never compromised the integrity of her code for performance, cost, or deadline pressures. We want to have a perfect system that people will ``ooh'' and ``aah'' over, but when you see the boss coming down the hall with a worried look, you realize that the latest nasty hack is going to make its way into production. Tests, therefore, are your friend. Tests will tell you if the nasty little hack works. Tests will tell you when the nasty little hack breaks.

    Test, damn you!


CONCLUSION

Many Perl programmers, including myself, learned Perl's OO syntax without knowing much about object-oriented programming. It's worth picking up a book or two and doing some reading about OO theory and pick up some of the tricks that, upon reflection, seem so obvious. Let the object do the work for you. Hide its internals carefully and don't force the programmer to worry about the object's state. All of the guidelines above can be broken, but knowing about them and why you want to follow them will tell you when it's OK to break them.

Update: I really should have called this "Often Overlooked Object Oriented Observations". Then we could refer to this node as "'O'x5".

Cheers,
Ovid

New address of my CGI Course.

Replies are listed 'Best First'.
Re: Often Overlooked OO Programming Guidelines
by Anonymous Monk on Dec 29, 2003 at 21:20 UTC

    If I might add one more observation: Don't think about classes (at all) when doing domain modelling! Classes are a structural element of the code not an element of the problem domain. Just think about the objects (what they need to do, what they need to know). Thinking 'classes' too early subverts object-oriented design into class-oriented design, and the result is highly stuctured code (often with deep hierarchies) that doesn't map well to the problem space.

      You know, that has to be one of the most intelligent comments I've heard about OO programming.

      Cheers,
      Ovid

      New address of my CGI Course.

      The purpose of programming. Roger seconds Ovid's comment.

Re: Often Overlooked OO Programming Guidelines
by hardburn (Abbot) on Dec 29, 2003 at 21:00 UTC

    Some argue that the behavior or subclasses (or subtypes) should not change . . .

    I dunno. HTML::Template::Dumper significantly changes the behavior of HTML::Template. If people want to argue that this breaks Liskov, that's fine, but it doesn't stop HTML::Template::Dumper from being useful.

    $object->as_string

    One important benifit is that YAML/Data::Dumper only show the state of the object's internal data structure, but not lexicals used for storing private data (see below). It might be private, but if it's for debugging or human-readability, it might still be important to print it out. So a mere Dump($obj); is often not enough.

    Other observations:

    1) One thing I often see is people storing things in the object's structure that should be private, or storing things in lexicals that should be accessible to subclasses. As a general rule, if you want a subclass to get at it, it should be in the blessed reference of the object. Or provide accessors/mutators that are only available to subclasses (not public, unless your design explicitly calls for it). If the data needs to be truely private, put it in lexicals declared at the top of the package.

    2) If you have a factory method, do not hardcode the name of the class. Instead, put it in a subroutine, like this:

    package My::Foo; sub BAR_CLASS { 'My::Bar' } sub bar_factory { my $my_class = shift; my $bar_class = $class->BAR_CLASS; bless { }, $bar_class; }

    This better supports subclasses, which would otherwise need to override the entire bar_factory method (which could be extremely complex). Now they only need to say sub BAR_CLASS { 'My::Bar::Subclass' } to change exact output of the factory method. (It's the responsibility of the subclass to make sure My::Bar::Subclass implements the same methods as My::Bar).

    3) Calling all your own methods should be done in $obj->method( @args ) form. Not method( $obj, @args ) or (worse) method( @args ). Both the bad examples break inheirtance, and the second one isn't a method at all. I could see an argument made for the method( $obj, @args ) form if performance is a concern and you don't care about subclasses or if it's a private method, but I see no excuse for the second form.

    4) Document protected methods. Unlike some other languages, Perl doesn't have any very good ways to specify what methods should only be accessible to subclasses (though it has a multitude of hacked solutions). Ultimately, you need to document your protected methods, with warnings of fire coming down from heaven if somebody on the outside uses them. And make sure fire won't come down on ligitimate subclasses.

    ----
    I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
    -- Schemer

    : () { :|:& };:

    Note: All code is untested, unless otherwise stated

      These are some interesting points you made. What stands out to me in your comments is that you've further shown (whether you intended it or not) how Perl's OO, while useful, is a hack and has some serious limitations. I've been working on an piece which shows Perl's limitations and uses Java's OO style as an example (because I know Java better than other OO languages, not because Java is the pinnacle of OO). I think some of your points will fit in quite nicely there.

      Cheers,
      Ovid

      New address of my CGI Course.

        Hi again Ovid,

        I've gone on personal missions to "fix" Perl's hackish OO. Object::Lexical is one attempt - instance data is held in lexicals and accessors/mutators are closures, created with Sub::Lexical. To quote the POD:

        <code> use Object::Lexical; use Sub::Lexical; sub new { my $counter; our $this; my sub inc { $counter++; } my sub dec { $counter--; } my sub inc3x { $this->inc() for(1..3); } instance(); }

        This skirts a few issues, which are issues unique to Perl:

      • Different syntax for instance data than other variables (my, local) makes refactoring code hard - every "$foo" must be changed to "$self->{foo}" manually.
      • No help from "use strict" and "use warnings" about only using a name once. None of the protection of requiring that a variable be declared first. In short, hash entries don't get all of the diagnostic helpfullness perl gives lexicals.
      • CPU overhead for hash lookups, memory overhead for storing hashes.

        Each object is given its own stash (namespace) which inherits from the namespace of the current package. The stash is populated with closures. Viola! Thanks to Juerd, by the way, who suggested creating things and stuffing them into stashes instead of sticking an AUTOLOAD to proxy to methods stored in hashes.

        Then there is typesafety: http://search.cpan.org/~swalters/typesafety-0.04/ with its massive userbase of 0 users. This cultural divide miffs me - no Java user would ever consider a language that didn't have typesafety, and no Perl programmer would ever willingly use typesafety. Actually, I know (or know of atleast) a lot of people that lost their Perl jobs and had to get Java jobs, and now would never go back to Perl because of things like the lack of typesafety and other OO hackishness in Perl, which just goes to show, people don't know what's good for them.

        -scott
        I disagree with the categorization of Perl's OO as a hack. I think it provides the minimal tools as part of the core language, and gives lots of room for addition, restriction, expansion, and factorization. This is evidenced by the wide variety of modules to change/enhance/replace/invert/etc. perl's core object model.

        Whether it is good to have such a plethora of ways and means (that you have to go looking for) instead of a Single True Way To Do It, Blessed By The Core, is a separate discussion.

        Update: Yes, Perl OO is constrained, and yes, it was grafted onto an existing language; I don't agree that the constraints are a consequence of the grafting. I think they are an intentional design decision (though from recent evidence, Larry wouldn't make the same decisions now).

        Update: Seems we just disagree on what hack means. To me it means poor features based on external constraints (whether that be time, backward compatibility, grafting new features onto old code, or whatever). I think the limitations of Perl OO due to intentional design, not constraint, so I would call it minimalist rather than hacked.

        Update: Perl has no useful subroutine prototypes even for non-methods, by the definition of prototypes in other popular languages. The purpose of Perl prototypes (user subs that work like builtins) doesn't apply to object methods.

        Update: It's strange to see multiple inheritance cited as a reason to call Perl OO hackish. It's the one feature that isn't what I would call minimalist. It's also hard to see how you could accidentally use it. It's not my fault, Officer, the language made me use multiple inheritance. Click go the closing handcuffs.

Re: Often Overlooked OO Programming Guidelines
by princepawn (Parson) on Dec 29, 2003 at 20:34 UTC
    Subclass to alter or add behavior.
    scrottie recently said that delegation was an alternative to subclassing... I would really like some references on why delegation is a viable/better option.
    That seems all fine and dandy. Now, imagine that you have that in 20 places in your code, but in the manager class, someone changes name to full_name. Because the code using the office object was forced to walk through the object heirarchy to get at the data it actually needs, you've created fragile code. Now the manager class must support a name method to be backwards compatible (and we get to start on our big ball of mud), or every reference to it must be changed -- but we've created far too many.
    Not too many for :
    perl -i.bak -p -e 's/manager->name/manager_fullname/';
    also, you might bring up the concept of a Facade: you might not go changing the object's interface: you could keep the hold and delegate of the old to the new method.

    PApp::SQL and CGI::Application rock the house

      Subclassing can be handy, but it's also a problematic aspect of OO programming. Also, Perl's AUTOLOAD function can lead to horrible bugs in inheritance implementation, further confusing the issue. Subclassing is a form of composition, but delegation can solve some of the issues that composition can lead to.

      As an example of problematic subclassing in Perl, take a look at this code:

      package Foo; + + sub new { my ($class, @args) = @_; bless \@args, $class } + + sub wonk { my $self = shift; $self->_fiddle(@_); } + + sub _fiddle { my $self = shift; return map { scalar reverse $_ } @_; } + + package Bar; @ISA = 'Foo'; + + sub thing { my $self = shift; $self->_fiddle(@_); } + + sub _fiddle { my ($self, @args) = @_; return map { ++$_ } @args; }

      Foo::_fiddle has no relation to the Bar::_fiddle method and the similarity of names is a coincidence. Unfortunately, calling the Foo::wonk method via an instance of Bar will still call the Bar::_fiddle method, even though this may not be desireable behavior. Not having clean encapsulation of private methods makes this very difficult to get around. You could try to get around it like this:

      # in package Foo sub wonk { my $self = shift; _fiddle($self, @_); }

      That looks better, but if the private method violates encapsulation and reaches into the object (a common practice), it might be making assumptions about what's there, even if those assumptions are not warranted.

      Delegation can solve this.

      + package Bar; use Foo; + + sub new { my ($class, %args) = @_; $args{_foo} = Foo->new; bless \%args, $class; } sub wonk { my $self = shift; $self->{_foo}->wonk(@_); # delegation! }

      Now, it doesn't matter what's in the internals of the Foo package. Inheritence doesn't bite you and everything is nice and clean.

      Cheers,
      Ovid

      New address of my CGI Course.

        Holding refs to subroutines seems like a perfectly good way to do private methods:

        package Foo; . . . my $fiddle = sub { my $self = shift; return map { scalar reverse $_ } @_; }; sub wonk { my $self = shift; $self->$fiddle(@_); } package Bar; sub wonk { my $self = shift; $self->$fiddle(@_); # runtime error }

        The real problem is that Perl doesn't have a good way of denoting protected methods or attributes. I don't consider litering your code with $obj->isa( . . . ) or die; to be a good way.

        ----
        I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
        -- Schemer

        : () { :|:& };:

        Note: All code is untested, unless otherwise stated

        Foo::_fiddle has no relation to the Bar::_fiddle method and the similarity of names is a coincidence. Unfortunately, calling the Foo::wonk method via an instance of Bar will still call the Bar::_fiddle method, even though this may not be desireable behavior. Not having clean encapsulation of private methods makes this very difficult to get around. You could try to get around it like this:
        # in package Foo sub wonk { my $self = shift; _fiddle($self, @_); }
        I'd prefer to write that $self->Foo::_fiddle, even though it would be slower.
        That looks better, but if the private method violates encapsulation and reaches into the object (a common practice), it might be making assumptions about what's there, even if those assumptions are not warranted.
        Don't understand what problem/assumptions you see as problematic here. Can you elaborate?

        I don't think I would use delegation for private methods; it feels like using a wrench to unscrew a lightbulb.

        I am with you on the use of delegation. However, you could take your example one step further and use dependency injection to fully decouple the two classes.
        package Bar; sub new { my ($class, %args) = @_; bless \%args, $class; } sub wonk { my $self = shift; $self->{_foo}->wonk(@_); # delegation! } package main; use Bar; use Foo; my $bar = Bar->new(_foo => Foo->new());
        Now Bar is fully independent of Foo (coupled only by the implied "interface" which consists of the wonk() method). This also makes testing easier.
      Delegation is better than inheiritance when the object doesn't want to export the full interface of the parent class. It is also useful when the object wants to change the behavior so much that it isn't a direct replacement. Also, it is helpful when the relationship needs to be dynamic, if the "parent" class is dynamic, or the referenced object needs change dynamically.

      For example, many network client classes inheirit from IO::Socket::INET. This is convienent for both internal and external use. But it fixes the clients to only use IPv4 sockets. There are other types of sockets, like IO::Socket::INET6 and IO::Socket::SSL, that could be used if the inheiritance wasn't fixed.

      Also, there is a need to change the socket but keep the same client object. Some protocols support negiotiating SSL over the existing TCP connection. The easiest way to support this is replace the reference to the IP socket with an SSL socket object.

        Hi folks,

        This is really a reply to the thread so far.

        First, nice work Ovid. I'm jealous of anyone who can write clear, simple examples - I haven't developed the skill yet.

        princepawn and iburrell - one objection I raised to subclassing rather than delegating is the breakdown of structure in the program. The best analogy I can think of is databases. Databases with one large table can't effectively be reported on - they have no structure. No relation. No parts that exist seperate from each other. You can always self-join - that is, join a table against itself, but this quickly becomes pathological. SelfJoingData at the Perl Design Patterns Repository is my attempt to flesh out this concept.

        Obviously, this fits in very strongly with the LawOfDemeter. Once you have structure, it must be navigated sanely, but if you have no structure, why even try to navigate it?

        Reporting is the database analogy. Reporting requires one-to-many and many-to-many relationships and everything required to create those - collectively known as database normalization. With object oriented code, you normally don't use the structure to report, but rather model state.One hot dog might have multiple topings. One table might order multiple hot dogs. One table might have multiple seperate checks. They might also have a pizza with multiple orders of the same topping - cheese, perhaps. If I had a nickel for every perl programmer that couldn't handle the slightist bit of one-to-many or many-to-many in code, I'd be a rich man. I've also suffered vast numbers of one-big-table Microsoft Access databases in my life.

        Database with exactly one table are a pathological case, but databases with one table and all other tables joining on only it are only a small improvement. Some reporting can be done, but only explicitly supported things. Some structure exists, but only where it is fancied for the purpose the creator had in mind. Any other reports, any other purpose, the structure is useless. Data must be gleaned dispite the structure. Or in spite of the lack of structure. Or something. This is the GodObject - one large object that knows all, sees all, controls, and only temporarily gives up control of the CPU to make method calls that are sure to return back so it can continue being in control. It is this desire to centralize control that waylays effort or interest in opening up to the wide world of event handlers, listeners, state machines, and so on and so forth - the bread and butter of the object world. You can't write a good OO program with centralized control, and you can't decentralize control as long as you build large compound objects and erase the distinction between different types of things.

        Someone in this thread used IO::Handle as an example of something to subclass - that's a good example. The rule of thumb is: subclass to create a more specific kind of something that already exists, create a new class to create a new kind of thing, and delegate to create something which knows how to do things that are defined in multiple seperate classes. IO::Handle's existing and future subclasses are specialized versions of IO::Handle: they read, write, flush, and do the things that IO::Handle does, but in special situations, and they do some related things that don't belong elsewhere. You don't get IO::Handles that work on database sockets that also know how to query the database, or if you do, hopefully they create a $dbh instance, passing it their socket, and delegate requests to that.

        I've done this rant a hundred times. Can you tell? =)

        One last bloody stab - re: Objects aren't always the way to go, absolutely. Perl Design Patterns starts off on a bender about you never know before hand that a program will grow, require additions, modifications, not to mention what it will need. You can't plan for the future, and most of the time, you shouldn't even try. I think the real art is two-fold: 1. Knowing how to start building classes, delegations, aggregations onto something procedural (or simplisticly OO) in such a way that the program grows gracefully and scales. 2. Know top down design, bottom up design, functional programming, procedural programming, relational modeling, and so on. Pick the right idiom. OO isn't for everything. People in the Java camp tend to add too much structure and thus obscure the problem and the solution they've devised, not to mention oblivion to other idioms. Using the wrong idiom is just as ineffective as using the correct idiom badly.

        A programmer who hasn't been exposed to all four of the imperative, functional, objective, and logical programming styles has one or more conceptual blindspots. It's like knowing how to boil but not fry. Programming is not a skill one develops in five easy lessons. -- Tom Christiansen in 34786.

        -scott

        jdporter - Fixed the markup error on "GodObject"

        Most of the times I prefer delegation. It is a useful technique, because it is really easy to reuse modules that way. But it depends on your programming style. I usually write small modules, which have one or two functions. I have for example a module Logging, which does exactly that: 'Logging'. I use delegation to build with them. For example I can put them in a facade, which does some more complex things.
        Inheritance I mostly use, when I want some method to be shared by all my objects.
      This has been a debate in the OO community for some time. The initial paper on this subject was "Encapsulation and Inheritance in Object-Oriented Programming Languages". The only discussion I recall seeing in a normal book on programming was Effective Java by Joshua Bloch. There are several examples of "bad" things happening in the real world. The highest profile one I remember was an upgrade of Java's Servlet classes. Many early servlet applications were created by inheriting from Sun's Java classes. Well, with the upgrade, certain portions of the class internals were changed, causing the base API to return differing values between the versions. So, to upgrade, many people had to rewrite their applications. Bloch and others argue that this can be avoided by encapsulating classes in many cases, especially if you have no control over the other class (i.e. you have the class from a vendor but not the code for it). This topic is still open to debate, and there are many cases where one is much more applicable than others.
Re: Often Overlooked OO Programming Guidelines
by Anonymous Monk on Dec 29, 2003 at 20:56 UTC
    Now, imagine that you have that in 20 places in your code, but in the manager class, someone changes name to full_name.

    That is a problem with changing a "published" (as opposed to merely public) interface. Your solution is really no solution at all, it just moves the problem: now we have twenty calls to $office->manager_name, and someone changes the office class and renames that method. If something returns an object, you need to feel free to call that object's methods ... otherwise, what is the point of returning the object in the first place?

      Yes, you're correct. I used a rotten example. Here's a clearer example. A corporate customer is assigned to a company, which has an office which has a manager.

        my $manager = $customer->company->office->manager;

      Later on, we realize that this is a bad class heirarchy and the customer should belong to an office and the company is superflous to this, but we've hardcoded a chain of method calls and this makes life difficult. What if we had done this:

      sub Customer::manager { my $self = shift; return $self->{delegates}{company}->manager; } sub Company::manager { my $self = shift; return $self->{delegates}{office}->manager; } sub Office::manager { my $self = shift; return $self->{delegates}{manager}; }

      Now the fix is easy, when we want to drop the Company class reference in the Customer object.

      sub Customer::manager { my $self = shift; # return $self->{delegates}{company}->manager return $self->{delegates}{office}->manager; }

      Cheers,
      Ovid

      New address of my CGI Course.

Re: Often Overlooked OO Programming Guidelines
by pg (Canon) on Dec 30, 2003 at 02:56 UTC

    I seriously disagree with the first section "useless OO". There is simpy no such thing as "useless OO".

    When we look at this issue, we don't look at it from a programming point of view, but rather should look at it from a methodology point of view:

    1. Everything in the real world is an object (class is the collective abstraction of object).
    2. Programming is the way used to resolve real world problems.
    3. In order to be able to resolve the problem, especially through a machine, you need a way to (observe and ) describe the entities concerned, and the process to resolve the problem.
    4. OO is one way to describe real world (or to be precise, to perceive it and then describe it.)

    The essential reason for the existance of objects is not for programming, but to descibe the world, however it helps programming. As long as an object matches an entity in the real world, the object has every reason to exist, and those reasons are beyond programming itself.

    Acme::Playmate is not the best example for "useless OO". It is not even an example, and there is no example to prove there is useless OO.

    On the contrary, to me, Acme::Playmate is a very good example of a simple object, and it encapsulates at least those three attributes you had in your sample code. Most importantly, the class does abstract an entity the author perceives. Whether it has any method other than the constructor can not be used to disqualify Acme::Playmate as a class (As those three attributes are by default exposed to outside world, there is no need for accessors, where there usually should be, and this is just due to the nature of the programming, and not really related to our discussion).

    However there are cases, that objects are poorly defined and designed (the real world is perceived in a messy way, rather than a clear and precise way), but that's a different issue beyond this discussion.

    For the rest of your note, you have given some very good tips on Perl OO programming. But I had a general observation that it is a mixture of two totally different aspects: programming skill and programming methodology. Sometime, the note intends to use programming skill to guide programming methodology, when the proper way is simply the opposite.

      On the contrary, to me, Acme::Playmate is a very good example of a simple object, and it encapsulates at least those three attributes you had in your sample code. Most importantly, the class does abstract an entity the author perceives.

      I'm with Ovid on this one. The example under discussion is just a plain old data structure dressed up in a little OO clothing. If you remove the bless line from the constructor, you get back a plain ordinary hash reference that has *all* of the functionality of the so-called object. It is useless OO, as is the following:

      #!/usr/bin/perl -w use strict; sub whatever { bless {name => 'pg', forum => 'perlmonks'}, 'NonObject'; } my $obj = whatever(); print $obj->{name},"\n"; print $obj->{forum},"\n";
      1.Everything in the real world is an object (class is the collective abstraction of object).

      Everything in the real world is *not* an object, and, conversely, a good many of the objects we create in our programs are 'objectifications' of process (not that that is a bad thing).

      Eh? The constructor in Acme::Playmate could have been called get_playmate_data and returned an unblessed hash? The semantics of using the module would have been exactly the same. I don't see how that warrants OO in any manner. Besides the constructor being a constructor there's nothing OO about even the existing interface at all.

      Makeshifts last the longest.

      Sorry pg, I was going to go with you on this until I took a look at Acme::Playmate. Unfortunately, since one of the main purpose of OO is to encapsulate your data, a class without any methods has a hard time claiming that it is truly a class.