Hey Rapi,
The fundamental distinction between object oriented programming and procedural programming lies in the concept of using if statements to differentiate behavior (procedural) versus using hierarchies to differentiate behavior (object-oriented).
Hi Jeff,
Long time reader, first time commenter. I really enjoyed this post, and pretty much all the comments on it. I’ve come from a VB4 - VB6 - C# background (there’s a mix) and agree that with OOP you can make things exceedingly complex, however, OO-at-the-right-level is a very powerful thing.
I worked for an HR company doing payroll and personnel apps, and we catered for Oracle and SQL. It was only after two additional, more OO developers joined that I learnt the joys of the Factory pattern and abstract classes. That was tempered with the use of plain old strongly-typed datasets instead of the framework for data that two other developers had written because it was far, far easier to use and maintain.
The two “true” OO developers subclassed almost everything they touched, and insisted the other developers went through their objects for coding, when all that was required was just retrieve some data, process it, and output it to a file. Why use someone else’s object (with all its caveats and foibles) when the exact functionality you require already exists?
And oh, the lure of re-usable code! “Let’s make this generic,” says the manager; “Can’t we re-use this?”, says another manager, neither of them realising that two apps which appear to do the same thing do it entirely differently behind the scenes due to customer requirements.
Reusability is a lofty goal - I remember being at a talk given in VBITS 99 in Chicago (ooh, get me). Microsoft Transaction Server had been released and I was attending a talk about it. The speaker was asked a question about the use of MTS and basically said, “Well, MS says to do it this way, and we need to stick to OO principles”. The speaker replied with, “In development, there’s always two schools on how to code: what is good and scholarly, and what works”.
I always code as if an axe-wielding psycopath will be maintaining my code after I’m hit by a bus; the KISS principle also makes code less likely to break. There, I said it.
Great post, sorry for the long comment.
Kind regards,
Mike K.
Hi Jeff,
I came accross your site using stumbleupon, I suppose I was a part of your bandwidth blitzkrieg last week 
What do objects give us? Modularity.
What is modularity for programmers? Encapsulation and abstraction.
What is encapsulation and abstraction?
Encapsulation is the ability to separate our routines into separate “chunks” of logic.
Abstraction is the external interface of each “chunk” such that:
a) unrelated pieces of logic arent allowed to meddle with one another
b)the logic appears simpler from the outside of the “chunk”.
Do you need a similar chunk of code to operate in slightly different contexts, or could you benefit from dividing the logic of your program into multiple loosely coupled components?
If not, you dont need them. OO is just another tool in the toolbox, with right and wrong times to use it.
At our business, we have two enterprise applications, one written in classic asp, and another written in asp.net C#. The .NET one uses NHibernate, an ORM mapper, and leverages extensive OO design patterns. The asp program is written using vbscript and stored procedures. Both have roughly the same amount of business logic intensity.
Guess which one costs vastly less to maintain?
Guess which one we have trouble staffing, because all the programmers quit out of frustration?
Which project would you rather work with?
No offense, but reading through most of these comments, Im convinced most of these people (eg: old school VB programmers) never learned how to correctly harness OOP to their advantage… maybe they had a bad initial experience with it.
Dont abhor or fear the concept if you dont have much practice with it. The majority of “good” programmers can clearly visualize the benefits of OO
-pete
Pete, in regards to most people who hate OOP or seem to instinctively fear those 3 letters when they see them, I think that is true to an extent. Often they come from a VB background and they felt like they had it down and then .NET came out (I’m speaking very MS oriented, I know. People who came from a Java background might not fully appreciate this).
But, as I am sure many here agree, the VB6/VbScript to .NET transition was a needed shift for Microsoft. Those who made the leap and are thriving in the workforce are much, much stronger programmers for it.
I am one of those developers who came from a very procedural VB background and jumped across to C# a few years ago. I had an “understanding” of OOP and could have probably passed a verbal interview’s worth of questions even. But, and this is sad in retrospect, it didnt start clicking for me until Visual Studio .NET and I started enjoying much better intellisense in my IDE (I think VS2005 is the greatest IDE ever, FYI. I might even arm wrestle you over that, though I have not checked out Borland tools in a while). What and which methods/properties were exposed and why, the time-saving and increased manageability found in inheritance, and portability of code across applications just became vivid to me because of intellisense. I started documenting my classes, methods and params so the next developer could have a little tag pop-up and say “Hey this is what I do, why, and how I should be applied”. In the web dev world, its difficult to get that kind of reuse and documentation out of procedural code unless the developer goes to the actual file location and reads exactly what that block of code they’re supposed to include does.
Most of what I do now is all ASP.NET so, for me often instancing an object and using available methods is almost like a replacement for an old-school #include directive, but that added structure makes maintence much, much easier. Plus, that added level of abstraction generally speeds up development once the foundation class coding is laid. BUT, thats just it. DONT lay down all of that code if you do not need to.
Knowing WHEN to use OOP is just as important as HOW.
The good book "Object-Oriented Analysis And Design with Applications"
By Grady Booch starts off with chapter 1 stating that OO is for managing complexity. I think the point well-made here is that OO taken too far only adds complexity.
No offense to all commentors, but I think Ed said it best…
“OO to me just provides a better way to hide implementation and abstract ideas away so I can create more complex, but logically simpler programs because I don’t have to hold onto all the nuances of everything at once. It’s no panacea, but it is nicer to work with when done right.”
ok, we got OOP. we got POO.
Let’s make another acronym: Perfect at Objected Oriented Progamming. (POOP). you can make this a certification that people can get by taking an exam or something. it can be sponsored or standardized by different vendors. You can be MCSPOOP, or Sun certified POOP. you can have all different flavors of POOP.(yuck)
“Object-oriented programming generates a lot of what looks like work. Back in the days of fanfold, there was a type of programmer who would only put five or ten lines of code on a page, preceded by twenty lines of elaborately formatted comments. Object-oriented programming is like crack for these people: it lets you incorporate all this scaffolding right into your source code. Something that a Lisp hacker might handle by pushing a symbol onto a list becomes a whole file of classes and methods. So it is a good tool if you want to convince yourself, or someone else, that you are doing a lot of work.”
According to me, the programmer Paul Graham is talking about in the above excerpt, is doing a great job and is being most productive. Code writing is not difficult. It is maintaining code that is difficult and accounts for 70% of development cost. So, if the programmer is writing elaborate comments about the code, he is doing excellent service for the programmer who will be modifying his code later on in the software development life cycle. It is right up with the spirit of POO that you yourself are talking about.
Cosmic Ovungal
I can relate 100%. I have worked with the same company for 6 years and recently started interviewing for a new job and what a disappointment it has been. I meet the manager and then they send in the guns, the ‘technical’ person, the “Architect”. This new term “Architect”, I try not to laugh in their faces when someone claims to be one thinking of George Castanza. They ask me how I go about designing software, and I ask, “which software” and the interview is over. I know they want me to have read the same crap NET book they read and explain some canned one size fits all oop process and they look at me like I am from Mars when I explain that the amount of design ceremony depends on the risk and complexity of each situation. Microsoft is moving technology so fast that “cutting edge” shops are tossing projects and rewriting them as new technology comes along. As long as deadlines are met, no one is the wiser to the failure of the product since there never is a measure or accountability before it is rewritten. In my last two interviews, I asked what their oldest set of code was and neither had anything older than a year and in both cases they said they would rewrite when VS 2007 comes out. So… in this case, probably does not matter how they design their software since it is so short term.
I’d say, just go for wordpress
seriously, though, OOP is great for re-use. It’s like Mondrian vs. Pollock.
The methodology used by most programmers is not OOP, it is not POO, it is CAP: Copy And Paste. And remarkably, CAP is by far the most productive methodology. More programmers use CAP to get work done vs. any other methodology.
By embracing CAP, Microsoft used MSDN to utterly dominate the programming tools market. Nothing could compare to the vast volumes of examples that were provided via MSDN.
Today we see the open source world has embraced CAP even more deeply and is now, in turn, dominating Microsoft.
As for OOP, I’ve programmed long enough in the OOP world to know it is basically just another way of making noodle dishes. Usually the noodles take longer to cook and cost a bit more vs. procedural noodles. But they taste just about the same.
I also have to say that I’ve been learning about IoC recently.
So far, I have discovered that “Inversion of Complexity” doesn’t do much more than “Make Work for Object Brother”. And really, if I were an object, would I want to be injected (by a stranger and not a friend, nonetheless) with dependencies?
The one thing they got right is that objects go into a container.
Very good read. Our company is currently struggling to find a balance between OOP and code that a developer two years from now can support.
We have a person strongly pushing using all aspects of OOP regardless of the projects needs and others pushing back for a simpler approach to handling our coding.
In the end it’s probably in the middle, but it’s good to see others seeing it taken to a point where poor joe programmer starting with a company a year from now gets to sit down and figure out why this relatively simply project is so so complex.
One does what one likes as an artist.
Most artists are unoriginal.
But most are motivated by others work.
OOP seems to resonate with many coding artisans.
It easy to be judgemental about OOP.
As you are here in this quote, “In my experience the best code, like the best user interfaces, seems to magically anticipate what you want or need to do next. Yet it’s discussed infrequently relative to OO. Maybe what’s missing is a buzzword. So let’s make one up, Programming fOr Others, or POO for short.”
In the end, it’s all about the target audience and their concerns and desires. One’s OOP is another’s POO. Try to keep perpective. What will this all really matter in a generation?
Some excellent thoughts on the topic.
There is not much mention of multi paradigm programming. I suppose most people don’t want to master everything a language like C++ has to offer. It frustrates me when people here of C++ they think only of OOP.
Yo…
I’m sorry but OOP or POO?
Thats the funiest fuckin title I have ever seen
Listen, I’m NOT a OO snob or apologist, but when OO is done correctly, there’s nothing like it. When the pointy-haired boss comes by the cube farm with a bunch of new requirements, a well designed OO project can usually handle all the new stuff seamlessly.
The problem is designing an OO project is an incredibly difficult/complex thing to do.
And judging by the comments here, you’ve all run across some really bad OO code. Unfortunately, the language and/or methodology gets a bad rap when the people have a hard with it. It’s still up to the human; the best IDE, language, methodology, etc. will still allow you to cut off your fingers without warning. That and computer science courses in college aren’t teaching objects… the cover of the book may say so but after page 1’s “hello world”, there’s 500 lines of code in main().
I see a lot of myths from the functionally decomposed folks in the crowd:
OO has nothing to scope nor schedule… furthermore, if the objects couldn’t be extended, then they aren’t really objects in the first place. The use of the new keyword in and of itself does not == object.
That person is not writing OO code and the factory pattern is used incorrectly if you honestly think this.
A true OO project does not return values… the objects should know where to get it. Unfortunately, and I’m guilty of this, mutator/accessor methods have become pervasive and associated with OO code but that is the wrong way to do it. And yeah the language lets you do it but the language also has the “goto” keyword but I don’t seem anyone using that anymore.
Hardly OO’s or the language’s fault… sounds like a developer trying to write top-down code in an OO language. Well defined objects are hardly bloated.
Because your example is NOT OO code… that’s very functionally written; the return type is a dead giveaway!!!
This is NOT a personal comment but the IDE does not make someone a better developer. If you’re in VS2005 and banging away on the dot or ctrl + space to see what interfaces and methods are available to your types, I betcha you’re still writing very procedural code.
Finally, and for goodness sake… don’t mix the two. When you mix procedural and OO, cohesion and encapsulation start to suffer very quickly.
I for one love oop. I have long been a procedural programmer with experience in assembly, c, and php and never used any comments. I detested oop but once I used javascript I fell in love with it.
The idea of working with objects and manipulating them is amazing. It allows easy modifications and upgrades to the software I develop. I also think oop is the way forward. If we keep thinking of tax then we would all be programming in assembly language.
People used this same reasoning during the migration from assembly to compiled language. But today no one even thinks of coding in assembly. As computers get faster, the extra load will soon not be noticed. So like I say: I LOVE OOP. LONG LIVE OOP.
JavaScript is neither Java nor OO. Try again!
quote Jack on March 4, 2007 10:13 PM
i love VB because i don’t have to code it the OOP way but how do you reuse your code if you don’t use OOP?
You can code in a procedural language like you have OOP. Put the data structures and the functions that use them in a header file (dreams of C). If you need that “objects” functionality, include that header. Viola the code is reusable. For the most part, you own the code that your reusing, so if you need to add a function to that “object” add it to the header file. Use a revision control system, and document, and then document some more.
Something like:
// build with version 1.1.3 of this header file
Should help when the user gets errors saying the new function isn’t available.
Quite fun. I often find that a lot of OOP ends up looking like POO. Thanks for this post, I thoroughly enjoyed it.