|P is for Practical|
Re: I dislike object-oriented programming in generalby doom (Deacon)
|on Oct 20, 2007 at 19:52 UTC||Need Help??|
A few corrections:
I don't think the right phrase is "anthropomorphic terminology", I think what you're really complaining about is the over-use of "metaphors" as the only way of understanding an abstraction. There are people who still think that "identify the nouns" is a good principle in OOP design, but that's kind of silly. If you look at the typical "objects" we really use, they tend to be totally made-up entities like "database handles" and "statement handles" and so on.
Some of the things you're complaining about are already understood to be problems within the OOP crowd: it's understood that you should avoid over-reliance on inheritence. Slogans recommending "aggregation over inheritence" are pretty common (as is the point that "inheritence breaks encapsulation").
A few comments:
Myself, I tentatively suggest that inheritence should usually be reserved for fixing problems in the original design. You should code to allow sub-classing, but find other ways to share common code.
An "object class" should just be thought of as a bunch of routines that need to share some data. There are a lot of ways of doing that (e.g. closures) and I largely just use OOP because I think it's familiar to more people, i.e. I use OOP for social reasons more so than technical reasons.
However there is a technical advantage of OOP: the ability to generate multiple "objects" (i.e. data namespaces) all of the same "class" (i.e. using the same method namespace ) within a single perl process. (But I wouldn't be surprised to learn that "functional" programming world has it's own way of doing this).
I don't think that OOP is tremendously useful for polymorphism, by the way, I think plug-in architectures work better, (ala DBI/DBD).
 Looking at this again, I see I'm oversimplifying by ignoring class data... I almost never use class data, myself.