Is OOP really a good thing?

[jwagner]

Interesting article I found:

http://zaemis.blogspot.com/2009/06/whats-wrong-with-oop.html

What are you guys thinking?

[NogDog]

I tend to agree with some of the comments, which suggest that it's not so much an issue of OOP being right or wrong but that many developers using OOP use in poorly or just plain incorrectly.

That being said, it is certainly not a "silver bullet" and is not necessarily the best paradigm for every possible software need. But I think if you learn to do it "right" and really understand it, you'll learn to appreciate it and make use of it for any applications above some arbitrary level of complexity and size. (I.e.: you won't gain much from it -- if anything -- for a single, simple web page that pulls a few items from a database; but you may gain a lot from it for a large, integrated web site that manipulates all sorts of data with many relationships and interactions.)

[laserlight]

jwagner wrote:

Interesting article I found:

http://zaemis.blogspot.com/2009/06/w...-with-oop.html

What are you guys thinking?

To provide a groundwork for my discourse, I define "object oriented programming" as consisting of four "pillars": abstraction into objects, encapsulation of data, inheritance, and polymorphism. Consequently, I view a lack of inheritance and polymorphism as not really "object oriented", but then "object oriented" is not synonymous with "good".

I concur with Boronczyk's point that:

Timothy Boronczyk wrote:

The truth is, procedural and OOP paradigms languages express the complexity of their problem space in different ways. Procedural code is flat and wide with functions. OO code is hierarchical with inheritance. OO-code is not inherently better organized than procedural code merely because it is encapsulated in objects. A reusable library can consist of functions just as easily as a collection of objects.

However, I think that Boronczyk's argument prior to this point is flawed. He posits that given this code:

PeanutButterJar.open()
Knife.spread(PeanutButter, Bread)

One must interpret it as "the peanut butter jar opens itself" and "the knife spreads the peanut butter on the bread". But one does not have to interpret it in that way. One can interpret it as "open the peanut butter jar" and "spread the peanut butter on the bread using the knife".

From what I see, in Boronczyk's example, inheritance is used, but polymorphism is not demonstrated. In fact, the code is effectively procedural. It has elements of OOP in terms of abstraction and presumably encapsulation (what one might call "object based programming"), but that is about it. Consequently, the difference between that example and this one is merely syntax:

open(PeanutButterJar)
spread(Knife, PeanutButter, Bread)

The above code does not necessarily mean a loss of encapsulation either: if open and spread make use of the interface of the relevant classes, encapsulation is actually increased since fewer functions have direct access to the internals of the relevant classes.

Therefore, if Boronczyk intended to answer the question of "what's wrong with OOP?", then I consider that he has failed completely.

To answer your question, however...

jwagner wrote:

Is OOP really a good thing?

Yes, if it is used appropriately.

[Kudose]

I may not be ripe with experience or have a college education, but I would say yes based on the last 7 years of migrating my programming habbits from procedural to object oriented code.

I also believe that OO is a way of thinking. Furthermore, I wish that I had not learned QBASIC "back in the day" and was first introduced into programming via a more OO language, like C++, or even a full on OO language like Java.

Just my 2 cents.

[rulian]

I think it's really about getting results. OO just makes more sense some times, and procedural make more sense other times. In fact I never use strickly one, and i'm willing to bet most of you do the same. Some things are just better handled by objects, and often times people who are devout in a practise will overkill simple tasks with complicated schemes.

[mpb001]

It is far easier to refactor procedural code into good OOP code if you know what you are doing than really bad OOP code.

This argument has been going on for over 20-30 years from proceduralists. I find this attitude somewhat selfish sometimes.

For an example of selfish

"open(PeanutButterJar)
spread(Knife, PeanutButter, Bread)"

The keywords open and spread has been stolen from all other application in the imagineering of the article.

"PeanutButterJar.open()
Knife.spread(PeanutButter, Bread)"

PeanutButterJar locks the open command to the domain of PeanutButterJar and Knife.spread locks it to Knife. That is a large benefit. Might be longer to type if you are using notepad, but no modern IDE enviroment forces that penalty. PDT,Zend( the paid for special PDT ), PHPEd all have very good object oriented programming environments. About 10 years behind Java, but still smart. Working smart reduces the hardness of the pain of every keystroke( a gripe proceduralists have against OOP and also a reason terseness in C was very prevalent - atoi being an example ).

What if 'I' want to open a submarine with a blowtorch. How in code will I achieve that?
( The new function will be called
"OpenSubmarineWithBlowTorch and then the old function should be renamed with all calls changed to OpenPeanutButterJarGripInTowelForExtraLeverage" for the sake of clarity.

OOP is as much about structured organisation than anything. Too increase organisation and reduce lack of naming conflicts in Drupal( procedural ) prefixing is used

http://drupal.org/node/252430

In Zend(OOP) it also uses prefixing Zend_
http://framework.zend.com/manual/en/zend.mail.html

Now if before namespaces the issue of name conflicts was deemed a big enough of an issue for the Zend contributors what does that say bout the possible limitations drupal may have. Is the Zend approach purely out of some paranoid fear?

Whatever preference someone has it should always be about organisation. Code is not for you it is for others who will face your code.

OOP came from inneficiencies of procedural, and while like most rules that people live by isn't 100% correct, there is no reason that functions cannot be grouped into utility classes comprising of static methods( except for the useless notepad one of more typing ). A global function is just quick and greedy.

[laserlight]

mpb001 wrote:

OOP is as much about structured organisation than anything.

The same can be said about good programming paradigms in general, including procedural programming.

mpb001 wrote:

OOP came from inneficiencies of procedural, and while like most rules that people live by isn't 100% correct, there is no reason that functions cannot be grouped into utility classes comprising of static methods( except for the useless notepad one of more typing ). A global function is just quick and greedy.

Sure, you can group functions into utility classes, but by itself that is not OOP. You could just as well group functions into a namespace in procedural programming. The use of a global function, or a free function in a namespace, is orthogonal to OOP.

[mpb001]

laserlight;10920448 wrote:

The same can be said about good programming paradigms in general, including procedural programming.

Sure, you can group functions into utility classes, but by itself that is not OOP. You could just as well group functions into a namespace in procedural programming. The use of a global function, or a free function in a namespace, is orthogonal to OOP.

The utility class thing is an aknowledgement that sometimess a more procedural approach can be valid, at least in the initial refactor from procedural to OOP.

It isn't OOP but can be a useful point to start with all existing code has to be put in parent structures. It was really aimed at the more stubborn proceduralists to keep their functions in related well named groups which a class or namespace enables. Though depending on your environment PHP 5.3 might be a way of. Even in mostly pure OOP projects there is not usually the degree of fascism that stops the use of utility classes. Plus but not allowing them at points it may be relevant it is stating procedural programming is 100% wrong which I don't think it is, leading to an argument with people who are procedurally minded and are waiting there for weakness in OOP land caused by puritanical ideals on both sides.

The reason I highlight the organisational/ structured aspect of OOP is I sometimes think it is lost when people start writing OOP. Sometimes when people make the jump the first thing they do is start writing big god objects that are each a programme. If organisation was prioritised( ie raising the questions at some level of how am I going to refactor, how much belt room is there to grow and does this class really own this responsibility ) then the quality of the code would probably be far greater than someone who does not do this this but understands all the more talked about concepts of extending, ecapsulation etc. Some people ask these questions intuitively with the words never formed but the questions are still there.

I am not saying procedural programming is not structured( I recognise the term structured programming comes from procedural programming and also there was a similar backlash to procedural programming when it was created ) just that OOP is a further refinement from the deficiencies that procedural programming had in real world environments with developers who had differing degrees of ability and self control working on systems when working with each other.

[Randy_Jackson]

Just speaking from my own experience, I tend to determine whether to use procedural vs. OO based on two factors:

1. How likely is it that I will be re-using this code?
2. How much time do I have to accomplish the task at hand.

Like everyone else here, I've written a number of functions and objects that I re-use frequently, but it doesn't always make sense to make an object out of everything, at least not to me.

[mpb001]

Randy Jackson;10920819 wrote:

2. How much time do I have to accomplish the task at hand.

Time should only be accounted for if you are happy with the technical debt
http://martinfowler.com/bliki/TechnicalDebt.html that this action causes. Sometimes the only reason there is no time to do it properly now is because something else was not done efficientley before.

Possibly due to lack of time then.
(http://martinfowler.com/bliki/DesignStaminaHypothesis.html

[ahundiak]

I agree that time is a significant factor. Whenever I'm short on time I always go with OOP.

[amy_damnit]

NogDog;10919302 wrote:

But I think if you learn to do it "right" and really understand it, you'll learn to appreciate it and make use of it for any applications above some arbitrary level of complexity and size. (I.e.: you won't gain much from it -- if anything -- for a single, simple web page that pulls a few items from a database; but you may gain a lot from it for a large, integrated web site that manipulates all sorts of data with many relationships and interactions.)

So, NogDog, where does one learn the "right" way to do OOP?? (Short of reading every book on the planet and working 30 years in the industry.)

Amy

[Weedpacket]

There is no Royal Road to programming. Just plenty of reading code and writing code (and running it, too, given the cheapness of the technology these days!).

[mpb001]

amy.damnit;10921069 wrote:

So, NogDog, where does one learn the "right" way to do OOP?? (Short of reading every book on the planet and working 30 years in the industry.)

Amy

Well I am not NogDog but there is one very good book on it
http://www.amazon.co.uk/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882. It is based on Java but is useful as Java has been around longer it also has had longer to find out what is not good. Like many things strength can be weakness and in the PHP world we are quite cuddly and don't hit each other with sticks which I think sometimes impedes us.

Good OOP is just learning the simple things and doing them well. The hard part is finding out what the simple things are and understanding how personaility can affect the quality. The 'cool' ninja is often selfish and the code they write is selfish and that makes it bad. The only reason they are classed as Ninjas is they have prematurely optimised their code in all the wrong places and made it look more complicated than it is. They think big instead of small as big is 'cool'.

There is a quote in a book that is very good, have it somewhere and I can't remember what book and it basically says "Always think that the next person who is coming to a piece of code is a sociopath and they knows where you live".

I find that quote very funny 🙂

I personally like code I write to be tranquil and code I have to work with from others to be tranquil. Not always attainable 100%, but untranquil areas such as heavy business logic can be isolated. This all comes from the KISS( Keep It Simple Stupid ) mentality that by making something more complicated than it needs to be it stupid. Though sometimes this can be used to attack OOP as it is deemed more complicated, though I treat this as a perversion of intention.

A good practice I find is to create classes with no code except public methods as it allows communication between the lower intuitive instincts with my upper consciousness. Some people use UML to achieve the same thing. Basically it creates two identities, one the natural coder and the other the guardian. The guardian keeps watch on how my emotional frame of mind is affecting the code and also whether engrained habits are lowering the quality.

There is no short path. I am pretty thankful for this as in a world market ability is the only hope of actually keeping employed and having a reasonbly good life style. Developers are often viewed as commodities that can switched easily for a different cheaper supplier etc. so there has to be a penalty for bad business decisions.

Learning anything properly comes from curiousity and being able to argue your corner when you are right and when you are wrong facing those reasons with a critical impersonal eye. When you are wrong try to laugh at yourself instead of getting upset, though this can be hard due to developers are not known for their tactfulness.

Asking the right questions gets you there a lot faster though. Developing software is as much an attitude and way of life than anything else. How good you are relies on a combination of natural ability and commitment. Commitment is actually more important even if the l33t out there think otherwise.

Sorry for the lack of a clear answer, my head hurts too much from last nights Guinness( the addictive developers drink ) and I find this topic a welcome distraction.

[NogDog]

amy.damnit;10921069 wrote:

So, NogDog, where does one learn the "right" way to do OOP?? (Short of reading every book on the planet and working 30 years in the industry.)

Amy

I think you have to do some reading, studying, class-work, or whatever (finding a willing, knowledgeable, and talented mentor, perhaps?). Simply reading code and trying to imitate it will only help if you luck into finding only "good" code to imitate. Even then, I'm not sure you can really grasp the underlying principles and practices unless you are particularly talented and insightful. At some point you have to read/study some theory and best practices.

Doctors learn how to do all sorts of amazing things by first studying the theory and specifics of various aspects of medicine, and then implementing them through actual application. They are not just given cadavers on day 1 of medical school and a set of surgical tools and then told to poke around, experiment, and try things out until they get a feel as to how the various systems of the body work and how to repair them. Certainly the pioneers of modern medicine may have started that way, but it would be a huge waste of time and resources to make every doctor-to-be learn that way when they could instead study the collected wisdom of their predecessors.

The actual "doing" is important, mind you, whether you are a medical student dissecting cadavers and then moving on to assisting in actual surgeries or whether you are a programmer working on exercises, personal web sites, and real work. The theory and the hands-on experience reinforce each other: either by itself has its limitations while the two together can get you to the promised land faster than either one by itself.

IMHO, of course. 😉

[amy_damnit]

mpb001,

Thanks for the long, philosophical response! (You must be fun to be around when people are buying the Guinness!) 🙂

I will have to re-read what you said several times, but I do agree in KISS.

My whole life I have said, "What you do should be clean, clear, and simple enough that you could hand it to someone on the street corner and they could pick up where you left off."

I pride myself on well-written and even better documented code.

At the same time, the whole conundrum is, "How do you know what you do not know?!"

That was my ultimate question to NogDog... There are so many millions of OOP, and Java and C++ and C "experts" that how is a newbie to know how to trust?!

Most things in my life I feel comfortable "going with my gut" and using common-sense, but I don't think IT is that easy - especially programming. (In my pessemistic view of the world, I think it is pretty easy to see that most of the IT world has no clue what it is doing. Just think of Windows, or every project I have EVER worked on...)

Sometimes you stumble across someone who is clearly an IT-god, but more often you find seemingly brilliant programmers who are really just opinionated pundits that ultimately live on an island.

I am seeking "TRUTH" and "wisdom of the ages" - the things that transcend what is "cool", "hip", "trendy" and usually driven by $$$ and EGOS!

In the end, to become a "Yoda" or "Buddah" I guess it just takes time and lots of hard work and reflection. (Not too many gurus are built by 25.)

But I digress...

Amy

[amy_damnit]

NogDog,

It sounds like the gist of what you advise is to "do it all"!! 🙂

I guess I knew that already.

What scares me about OOP is that is more than programming, it is "floorplan" for your whole system!

Now, ironically, my God-given talent in life is ORGANIZING things. And this has always come very intuitively to me. But with OOP and building large enterprise-level systems, I definitely feel like a "kid" that has no clue.

Because I truly appreciate how much I truly do NOT know, it is very humbling to undertake something like OOP, and it adds great anxiety knowing that if you don't lay the "footings" just right, you'll have a driveway full of hardened concrete that you cannot move later. (Oh the pressure?!)

But like any large task/goal in life, the exciting part is the uncertainty and that is what builds character and experience and wisdom - at elast for those that do not get crushed!

Amy

[NogDog]

The fact that OOD/OOP can force you to actually analyze, design, and then program ends up being a benefit in almost every aspect of building an application. As alluded to above, with small, relatively simple/trivial applications where you can essentially conceptualize in your head everything it needs to do, it may be simpler and faster to just hack out some procedural code and get it done. But most truly useful applications are not simple/trivial, and by going through the analysis and design steps before doing any detailed coding you actually save time in the long run: you spend less time going down wrong paths, testing and debugging are easier, and hopefully a lot less debugging will be needed. It also makes it easier for you to look for and incorporate pre-existing classes into your application, whether from your own personal library, open-source libraries, etc.

And when you start working on large projects with multiple developers, some sort of very modular approach becomes virtually mandatory if you aren't going to have developers constantly stepping on each others' toes, and OOP is certainly the most popular "very modular approach" right now.

In case I haven't mentioned it yet in this thread (I've mentioned it in so many others 🙂 ), PHP Objects, Patterns, and Practice does a very good job of helping the reader see how much of this stuff fits together.

[amy_damnit]

NogDog;10921339 wrote:

In case I haven't mentioned it yet in this thread (I've mentioned it in so many others 🙂 ), PHP Objects, Patterns, and Practice does a very good job of helping the reader see how much of this stuff fits together.

More good stuff - as always - NogDog.

After I finish my "PHP 5 Advanced" book and one more that I saw at B&N on PHP and OOP, I will try to dive into the books that you all have mentioned including this last one.

BTW, sorry to the Original Poster if I high-jacked your thread! (I just thought you asked good questions and there were great responses that made me want to jump in!)

Amy