Re^2: looking towards learning OOP

Replies are listed 'Best First'.
Re^3: looking towards learning OOP by doom (Deacon) on Sep 12, 2008 at 19:03 UTC
Just to take the opposite side of this argument: it is not at all clear to me that the doctrine of "Object-Oriented Design" has anything going for it -- this isn't the sort of thing anyone ever takes the trouble to do studies of, so instead we're all left shouting our anecdotes and personal impressions at each other. Notably, what exactly OO Design is is somewhat up for grabs, and has certainly changed over the years (any failures in OO designs, you see, can never be the fault of OO design itself, but instead must be the result of a poor implementation... and so we have ancilliary doctrines accumulating around the original doctrine, e.g. "design patterns"). One could make the case that using objects in perl is a little less onerous than in a more fundamentally object-oriented language, because you can be a little sloppier about it and let the abstractions leak when they need to. My own take would be that pursuing some grand understanding of the fundamental principles of objects before you proceed with actually using them would be totally crazy: you'll never be done with it, and never get down to the concrete-level to see if using objects actually does anything for you. Most likely you'll need to pursue both levels at the same time, and a good way to start may very well be to think about object classes as a collection of routines that share data via a blessed hashref. Some of my own suggestions (for what they're worth, and I'm not sure how much they are): I still favor hashref-based objects over "insideout" objects (it's very convenient to be able to dump the hashref when you're debugging, and in general they seem more perlish to me); I currently use the very simple Class::Base to base my objects on, though I usually add my own AUTOLOAD section to generate accessors -- manually created accessors aren't bad to start with however, particularly if you have some sort of editor macros to create them. I strongly favor aggregation (object fields that contain other objects) over inheritance -- but if you find yourself adding a field named "type" to your object classes, it's a sign you might need to be using inheritance instead. Instead of working from theory on down, you might think about examples of things you've seen work: it's better to hold DBI/DBD in mind than jargon about "the factory pattern" or some such. Remember, the name of the game is to split large tasks into small that it's easier to wrap your brain around. If you've got an elaborate framework of classes that needs to be understood it may be doing more harm than good.	[reply]

Replies are listed 'Best First'.

Re^3: looking towards learning OOP
by doom (Deacon) on Sep 12, 2008 at 19:03 UTC

One could make the case that using objects in perl is a little less onerous than in a more fundamentally object-oriented language, because you can be a little sloppier about it and let the abstractions leak when they need to.

My own take would be that pursuing some grand understanding of the fundamental principles of objects before you proceed with actually using them would be totally crazy: you'll never be done with it, and never get down to the concrete-level to see if using objects actually does anything for you. Most likely you'll need to pursue both levels at the same time, and a good way to start may very well be to think about object classes as a collection of routines that share data via a blessed hashref.

Some of my own suggestions (for what they're worth, and I'm not sure how much they are):

I still favor hashref-based objects over "insideout" objects (it's very convenient to be able to dump the hashref when you're debugging, and in general they seem more perlish to me);
I currently use the very simple Class::Base to base my objects on, though I usually add my own AUTOLOAD section to generate accessors -- manually created accessors aren't bad to start with however, particularly if you have some sort of editor macros to create them.
I strongly favor aggregation (object fields that contain other objects) over inheritance -- but if you find yourself adding a field named "type" to your object classes, it's a sign you might need to be using inheritance instead.
Instead of working from theory on down, you might think about examples of things you've seen work: it's better to hold DBI/DBD in mind than jargon about "the factory pattern" or some such.
Remember, the name of the game is to split large tasks into small that it's easier to wrap your brain around. If you've got an elaborate framework of classes that needs to be understood it may be doing more harm than good.

[reply]