Beefy Boxes and Bandwidth Generously Provided by pair Networks
Think about Loose Coupling
 
PerlMonks  

Re: Often Overlooked OO Programming Guidelines

by pg (Canon)
on Dec 30, 2003 at 02:56 UTC ( [id://317611]=note: print w/replies, xml ) Need Help??


in reply to Often Overlooked OO Programming Guidelines

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.

Replies are listed 'Best First'.
Re: Re: Often Overlooked OO Programming Guidelines
by Anonymous Monk on Dec 30, 2003 at 05:40 UTC
    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).

Re^2: Often Overlooked OO Programming Guidelines
by Aristotle (Chancellor) on Dec 30, 2003 at 13:49 UTC
    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.

Re: Re: Often Overlooked OO Programming Guidelines
by Steve_p (Priest) on Jan 02, 2004 at 21:33 UTC

    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.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://317611]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others having an uproarious good time at the Monastery: (2)
As of 2024-03-19 06:51 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found