Perl OO = Evil ?
In response to Chris' comment about "OO=Evil" and his perl program that he said would have been easier to change had it been written in Java:
by saying "...much easier to alter if it were written in java." , I think you meant to say "much easier if it was properly encapsulated, layered with clearly defined interfaces between components and recognizable abstractions and design patterns"
Object Orientation paradigm is all about that:
- Modularity through encapsulation, abstraction, interfaces
- Re-usability through polymorphisms, inheritance, interfaces
The existence of documented and proven design patterns for OO further helps build and refactor OO programs.
These are characteristics of OO programming in general, not specific to a language.
You can write proper Object Oriented Programs in perl (see Damian Conway's PBP or better, the recent effort around Moose)
You can apply the OO design patterns to such perl programs (e.g: see Object::PerlDesignPatterns)
and they will have the same benefits as properly written Java programs (easy to refactor and to reuse code).
It's just that:
- Java was designed for Object Orientation, therefore if you write java you are forced into this paradigm. Because of that they are more tools for java to assist OO programming (especially for refactoring).
- OO in Perl 5 has too many unsatisfactory way to do it and a too verbose syntax
Regarding the talk on Perl's Worst Practices and the seemingly controversial "OO=Evil":
what Mark Fowler meant is that, OO is not only the paradigm in computing and it's not always the best way to solve a problem.
You've got OO programming, procedural programming, functional programming, aspect oriented programming,...
The nature of perl doesn't force you in any of these ("There's More Than One Way To Do It"), and each of these paradigms are better than the others for their own class of problems.
In other words, a skilled programmer should use the paradigm that suit best the domain of problems it tries to solve.
Of course, all programmers involved in writing or changing such programs need to have the same understanding of the domain and the best suited paradigm otherwise ...
Mark Fowler also hinted at the multiple unsatisfactory ways along with heavy syntax when doing OO with perl 5 as a reason for OO=Evil.
Perl 6 has a new object system which is very good and it is being ported on perl 5 as Moose.
Regarding my views on OO=Evil
I'm a big fan of Object Orientation as implemented with Objective-C or Small Talk.
Java OO is less elegant than
ST/Objective-C's.
Perl 5 OO implementation upsets me more, but at least I can choose not do OO in perl.
Also, the prospects of Perl 6 and the influence it had on Perl 5 (Moose) is starting to make OO in perl more interesting and desirable.
I think OO is not always the best paradigm, and I'm liking Functional Programming more and more.
Mark Jason Dominus' High Order Perl is the "FP design patterns" reference for perl programmers.
I found it difficult to get my head around (I'm still in the first chapters of HOP) and also I don't know
the best practices for unit testing FP programs.
I can restrospectively see a bunch of code of mine that might have benefitted of FP. Conversely, I have also unappropriately applied FP to some code. My current project though is better served by using OO.
Going back to OO, Ruby's OO is close to Small Talk, and Perl 6 is also borrowing things from Small Talk (ST traits will be known as roles in Perl 6) among other languages.
So, OO in Perl 5 is the devil, but often you have to sleep with it and at the end you get used to it.
If I can identify problems in code I create or change that are better solved by FP (I really need to make progress with HOP), I'll go for it.
In Perl 6, OO (and FP too) will be dramatically improved.
If you can't wait, go for Ruby or Perl 5+Moose.