in reply to OO 2 death?

My personal experience has been that when I code using OO techniques, I actualy write less (usualy significantly less) code.

The specific itch you mentioned was having to write constructors for each of your objects. Could that have been solved via inheritence?

In most of the OO projects I've worked on, we create a Base class that has an inheritable constructor that most or all of the objects inherit from. 

package Base;
use strict;
use warnings;
our @ISA = qw();

sub new 
{
  my $this = shift;
  my $class = ref($this) || $this;
  my $self = {};
  bless $self, $class;
  $self->init(@_);
  return $self;
}

# default init, does nothing...
sub init {1;}

# get/set a scalar member variable
sub _gss { @_ > 2 ? $_[0]->{$_[1]} = $_[2] : $_[0]->{$_[1]}; }

sub throw
{
  my $self = shift;
  my($p,$f,$l) = caller();
  die "Exception at: ",$p,"->$f($l)\n  ",join('',@_);
}


1;
########################################
package MyObject;
use strict;
use warnings;
our @ISA = qw(Base);

sub init
{
  my($self) = @_;
  $self->someSetting('default value');
  return 1;
}

sub someSetting {shift->_gss('_myObject__someSetting',@_);}

sub someAction
{
  my($self) = @_;
  print "setting: ", $self->someSetting(), "\n";
}

1;
########################################
package main;
use strict;
use warnings;
my $obj = MyObject->new();
$obj->someAction();
$obj->someSetting('new setting');
$obj->someAction();

exit 0;

[download]
In that example, MyObject doesn't need it's on explicit constructor, as it will inherit the one from Base.

Is this applicable to your project, or am I missing the point?

Best regards,
Kyle

Replies are listed 'Best First'.
Re: Re: OO 2 death?
by Cestus (Acolyte) on Dec 06, 2001 at 20:23 UTC
    Not really - what I was doing was simple - formatting a week at a glance page. Stuff for each day comes in, HTML goes out. However, my teacher is schizoid on being able to easily modify code - he wouldn't let me have Monday and Tuesday be the same. I had to seperate those into seperate classes. I used inheritance as much as I could, but that was because he placed a 1.5 page limit (with comments and whitespace) on my modules. I couldn't cram a constructor, initializer and actual code into the module like I wanted to. I frequently use inheritance, but this case was so simple it was overkill - I didn't even need the most basic of OO tools to do this. Ridiculous thing is, while I'm taking this course I'm doing a coding co-op, and my employer openly encourages the simple solution - top->down, reuse, 3rd party stuff ... I've done much more complicated projects in less time than that dumb one.

    So, no, there wasn't anything I could really do in that instance - OO was forced, to a negative end. I'm pretty sure it sucks more resources than it needs as well.

    Cestus

    Microsoft and Shinra are the same. They're both killing the planet.
[reply]
      "he wouldn't let me have Monday and Tuesday be the same. I had to seperate those into seperate classes"

      Aha! Rather than having seven different classes, you should have used one (over-simplified and untested code): 

      package Day;

sub new {
  my ($class,$dayname) = @_;
  my $self = { 
      day => $dayname
  };
  return bless $self, $class;
}

      [download]
      And then you instantiate them like so: 
      my @days = map { Day->new($_) } qw(Sun Mon Tue Wed Thur Fri Sat);

      [download]
      Sometimes you don't need seperate classes, just seperate object instantiations.

      jeffa 

      L-LL-L--L-LL-L--L-LL-L--
-R--R-RR-R--R-RR-R--R-RR
F--F--F--F--F--F--F--F--
(the triplet paradiddle)
[reply]
[d/l]
[select]
      Ah. Your problem is simple then.

      You have a stupid teacher. I completely sympathize. I have had to deal with the same problem.

      While there are good reasons to limit a function to a page, there is no good reason to so limit an entire module. Furthermore your teacher's insistence on separating out similar things in the name of "modifiability" is just plain silly. What you are doing is, as you discovered, guaranteeing spending a lot of time writing similar code. More code means more room for mistakes. Most code means that any change has to be made in more places, and the opportunity for doing so means more room for mistakes. More code that is very similar means that you will spend time doing cut-and-paste code. Cutting and pasting is a guarantee that if you catch a mistake, you are going to have a fun time trying to fix it in every other place where it appears.

      Instead it is far better to find ways to put each piece of real information in as few places as possible (hopefully 1). That means gathering together similar things, having common execution paths, etc. This does not preclude any kind of later modification. In fact it makes it easier. Should you need to split things farther, you can do so later at no more work than it would be to do now. Should you need to reorganize or change common functionality, you will find that easier than it would otherwise be.

      I therefore encourage you to look past the bad and counter-productive restrictions placed on you by your teacher, and continue (even if you have to do it on your own) learning how to program well, including how to code OO well.

[reply]
      Ah well, just think of it as a learning exercise, getting arbitrary restrictions put on you, and having to get by as well as possible. Kind of like playing chess with no queens, or twelve tone music. In this case, your restriction is that it must please your stupid teacher :-)
[reply]

In Section Meditations