[deleted]

Hi mr foo bar

My way of answering such questions is:

• An object is a worker which provides access to the services embodied in the code and data of the class. This parallels how a database server provides services (say via a db or stmt handle) to let you access the data in the db. Likewise, it parallels how a web server provides services to let you access the web site’s static pages or CGI scripts. So you can call the class the server, and each object is created to deal with 1 client.

• To turn that around, a class can only justify its existence by providing services. As an extreme counter example, I recall when C++ hit the deck someone published - seriously - a class to allow you to set and get the value of a variable of type char. Yep - you had to call a method to set, and another to get, that value. Compared to a simple assignment stmt, it’s massive overhead. It would have been OK if the demo was showing the syntax of a class, but it wasn’t.

• You might prefer to call the object the server, rather than calling the class the server. I don’t mind either way, since it’s the understanding gained, about provision of services, that matters to me.

Cheers
Ron

The first point of objects is really not much more than namespacing. You want to define a set of operations that all require complex state. Instead of letting the caller keep track of dozens of variables for you, you package them into a complex type that you pass around to each of the operations. And now you can also avoid having to prefix all the subs with gtk_button_ to reduce the likelihood of identifier collisions, which makes things easier to read.

The second point, which really made OO click for me is Replace Conditional With Polymorphism. This refactor is the essence of OO design. Instead of having dozens of switch blocks scattered around your code, which examine a type flag in some complex type to decide what to do with a complex value, you give the complex type a dispatch table and indirect a call to a method that does that job through the table. Now, adding another type to your program no longer requires finding and changing dozens of switch statements pertaining to it; instead, you can just define a new class, which has all its methods in one place. (This is why Liskov substitution matters. If you have not adhered to that, then you don’t get the full extent of this benefit.)

It’s different from a dispatch table because it’s the opposite, or maybe you’d call it an inside-out dispatch table.

With a dispatch table all the implementations of one operation are defined in one place for all possible types (and the different operations are scattered all around your codebase across different dispatch tables – same as with a switch statement, so a dispatch table differs from it only in name, it’s just a different way of writing a switch).

With objects, you implement all the different operations in one place for just one type.

In essence you slice up all those switch statements by their branches, then take those branches and scatter them to the wind… where they separate according to the type they pertain to, class Wheat from class Chaff. I.e. this:

switch foo {
    case Bar:  save_bar
    case Baz:  save_baz
    case Quux: save_quux
}
...
switch foo {
    case Bar:  load_bar
    case Baz:  load_baz
    case Quux: load_quux
}
...
switch foo {
    case Bar:  alter_bar
    case Baz:  alter_baz
    case Quux: alter_quux
}

becomes this:

foo.save
...
foo.load
...
foo.alter
...
class Bar {
    method save  { ... }
    method load  { ... }
    method alter { ... }
}
class Baz {
    method save  { ... }
    method load  { ... }
    method alter { ... }
}
class Quux {
    method save  { ... }
    method load  { ... }
    method alter { ... }
}

Notice what happened: each class contains former branches from all switch statements.

And whether you have static types has nothing to do with the utility of Liskov subtitution, in fact, you have to be more careful in a dynamically typed language.

The point is that if you have an abstract Stream class, from which you derive subclasses like Socket and File, then the write method in one of these should not expect a different number, order or meaning of parameters, nor should it do something semantically completely different like self-destructing the computer. Otherwise you cannot give objects of that subclass to someone who says they want an instance of Stream, because you have made random changes to the interface (or its semantics) of the superclass, and if they try to use your object according to their expectations based on that superclass, things will go horribly or – worse! – subtly wrong.

Duck typing or not is irrelevant to the validity of that principle.

The idea that OO reduces implementation complexity because conditionals are superseded by polymorphism doesn't stack up for me.

For example "Factories" are popular - you have a class which creates objects of different classes depending on what data you give the factory method. The method needs to do some discrimination on input:

sub factory {

 my ($type_wanted) = shift;

## What is type_wanted? string? int? Other?
## Whatever it is you have to discriminate
## whether switch, if..then..else if ... or
## dispatch.
## Or ... why not make type_wanted a class that
## has a method 'discriminate' & put the rest
## of @ARGV in there?
$type_wanted->discriminate(@ARGV);
## Sure. So how does 'discriminate' work?

}

And soon enough you end up with this sort of thing
( http://en.wikipedia.org/wiki/Type_introspection#Perl ):

package Animal;

sub new {

    my $class = shift;

    return bless {}, $class;

}

 

package Dog;

use base 'Animal';

 

package main;

my $animal = Animal->new();

my $dog = Dog->new();

print "This is an Animal.\n" if ref $animal eq 'Animal';
print "Dog is an Animal.\n" if $dog->isa('Animal');

To eliminate 'if's I'll make 'the_box_i_belong_to' part of the remit of the
inheritance hierarchy that contains Animal and Dog.

sub Animal::the_box_i_belong_to { 'Animal' }
sub Dog::the_box_i_belong_to {
my $self = shift;
$self->SUPER::the_box_i_belong_to() }

## Later ..

print "Dog is an ${\($dog->the_box_i_belong_to())}.\n";

This works so long as your operation (print to whatever stdout is set to in this case) makes sense on the return type of the method. So - I'll make everything belong to a class that inherits from a super class that expects a 'print_the_box_i_belong_to' method.

Yeah - but print to where:
STDOUT?
STDIN?
?

No problem:

sub Animal::print_the_box_i_belong_to { 

my ($thing_ref,$output_dest) = @_;

$output_dest->print('Animal');

}

sub Dog::print_the_box_i_belong_to {
my $self = shift;
$self->SUPER::print_the_box_i_belong_to(@_)
}

## Later ..
print ("Dog is an ") ,$dog->print_the_box_i_belong_to(my $fh = \*STDOUT);

Ok - but failure to print to a dvd drive and failure to print to a network socket will have different consequences. Should I then handle the different exceptions? How do I discriminate between them? A polymorphic 'acknowledge_exception' method?

Of course this is a ludicrously over-engineered way to print an arbitrary namespace string. Yet I've seen similarly contorted polymorphicisation of procedural logic. Hell - I've done it myself.

To take it to its logical extreme you'd have to have *all* your behaviour in polymorphic methods to make your OO code completely switchless. Right down to your 'if':

$obj->if(@list_of_condition_obj_clause_obj_pairs);

"switchless programming"? To a point.

Since when is “doesn’t stack up” equivalent to “doesn’t work when taken to its absolute extreme (in a language that has cumbersome OO)”?

(Polymorphism is exactly how conditionals are implemented in Smalltalk, FWIW.)

@Aristotle: "The idea that OO reduces implementation complexity because conditionals are superseded by polymorphism .."
vs
"Since when is “doesn’t stack up” ..."

Never said it (polymorphism) doesn't "work". Merely that, in my opinion, the effort to replace conditionals via polymorphism can and does lead to counter-productive contortions. Hence it does not guarantee reduction in implementation complexity. The example is a not completely outlandish caricature of real life code I have written and/or worked with.

Not everyone shares your dim view of Perl's polymorphism support it would seem: (http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming) "Polymorphism in Perl is inherently straightforward to write because of the language's use of sigils and references."

mrstlee:

Hence it does not guarantee reduction in implementation complexity.

No single modelling technique does. You use it where appropriate and don’t where not.

mr foo bar:

I think smalltalk and self style OOP are completely different from the inside-out-dispatch table. It seems to me that they make the disptach-table and replace it with a more general dispatch middleman with objects as clients.

It’s not fundamentally different. They just make it meta-circular: essentially the inside-out dispatch table is itself an object too. (But don’t take this literally, I only mean it in terms of analogy.) At least, if that’s what you’re talking about. But the principles of why, when and how OO is desirable remain unaffected by that.