Software Development

Stop the systematic abuse of object-oriented programming

Justin James says developers really need to get off the couch, learn proper object-oriented programming, and use it correctly.

Object-oriented programming (OOP) has become the dominant type of programming over the last 10 years or so; a major driver of this has been Java, VB.NET, and C#. But what I keep seeing more and more is that too many programmers using object-oriented languages really do not understand OOP.

A huge misunderstanding is the concept of encapsulation. Encapsulation is meant to hide the underlying implementation of a concept from the code that makes use of the object -- not to expose it. The idea is that the consuming code does not need to know or care about the particular implementation "under the hood," so it can be changed without affecting anything else. Encapsulation works hand-in-hand with polymorphism.

Between encapsulation and polymorphism, code can (and should) be extremely loosely coupled. But really it isn't in many pieces of code that I have seen. Far too many objects end up simply being equivalent to a Pascal "type" structure, a strongly typed collection of other types, gathered in one spot for easy reference. Another fairly common misuse of OOP is to write "classes" that play out like hashtables of hashtables of hashtables. While that type of programming made sense in Perl for a variety of reasons (not the least of which is the lack of a comprehensible object system in Perl), it is not in the spirit of OOP.

Why are these techniques a problem? For one thing, they require too much knowledge by the consumer of the underlying functionality. The first example leads to these statements that look like this:

FooObject.Property.Item(Index).Method(Parameter 1, Parameter2).Property = BarObject.Method(Parameter 1).Property.ToKludgeObjectType()

If the consumer has no idea what any of those sub-properties, methods, and so on do, they cannot get too far using either of these classes. On top of that, by exposing so many of the internals to the consumer in what will need to be a full-access manner, the encapsulating object hands over full control. This can cause some real damage, particularly if those contained classes have properties or methods with negative consequences.

The second type that I describe typically looks something like this:

FooObject("Property").Item(Index).Method(Parameter 1, Parameter 2)("Property") = CType(BarObject.Method(Parameter 1).Item("Property"), KludgeObjectType)

Wow... what an utter disaster. Can you imagine working with this? The worst part is that, with all of those collection lookups, you can throw compile time checking out of the window. The person who writes this manages to combine a very dangerous aspect of dynamic languages (lack of compile time checking) with the worst of compiled languages (design time knowledge of types) into something that derives none of the benefits of either type of language. One "fat finger mistake" in all of those lookup values will compile just fine, but come run time, they will become errors of one sort or another. It would not be so bad if a simple mistake just lead to an outright exception like "Index out of range," but if the mistake just happens to be purely logical (e.g., the item named does exist, but the wrong item was named), there is a solid chance that the code will keep running but with silent and hard-to-detect corruption of data and/or logic.

I know part of the problem here is simple laziness. I am guilty of it plenty of times. For me, what usually happens is that I am using an OO language for something that I really just need a procedural or mostly procedural language for. Let's face it, not every application requires too much OO design -- they really just need a way of quickly passing a bunch of loosely related data around. But these "shuttle classes" always seem to take on a life of their own, and the next thing you know, you are writing static/shared classes with static/shared members to process the data within the "shuttle classes." Why? Because you really meant to be using Perl, Pascal, or maybe even Smalltalk or a simple shell script, not C++, Java, C#, or VB.NET (at least for this one part of the project, that is).

Folks, this is where the rubber stops meeting the road. Those earliest experiences with programming will always color our current thought process regarding programming. And nearly universally, we were introduced to programming with a procedural language or a very procedural use of a non-procedural language. Add to that the fact that contrary to popular belief, Java, VB.NET, and C# are not purely noun-oriented OO. After all, they have some primitive verbs in there. What we really just want to do sometimes is to extend the language itself (add new primitive verbs) --that is where those anti-OO static classes of static methods come from, and it is the only way we can really add a new verb to the language. Those pseudo-procedural-functions end up needing a ton of parameters passed to them (just like procedural code), since the data that they are working on is no longer included in the class that they are members of.

At the end of the day, this type of programming is indicative of one or more of the following things:

  • The programmer was "born and bred" in a non-OO environment and is untrained in proper OO.
  • The programmer does not feel like using the proper OO techniques for whatever reasons.
  • The language being used is the wrong language for the job.

I think the last item is a lot more common than most of us care to admit. After all, we turned to OO to save us a lot of headaches, increase code reuse, etc. But none of the OO promises can be fulfilled when we treat an OO language like it is something that it is not. And if we are going to program away the benefits of OO, why bother using the languages?

I guess this is yet another reason why I am fairly pro on the .NET CLR (and would be on the JVM if Sun was more supportive of other languages). It is possible (in theory) to write the right code in the right languages. Sadly, the only two languages with massive support in .NET right now are the nearly identical twins, VB.NET and C#. It looks like the first language to get formal "kid brother" status is the functional language F#. IronRuby and IronPython are still "CodePlex cousins," in which Microsoft might donate some time, server space, and documentation but little real support. Ruby is also attractive to me because it seems to blend procedural and OO code pretty well. I really, really need to try Ruby out.

The takeaway here is that you really need to get off the couch, learn proper OO, and use it correctly. Otherwise, you are hurting your own efficiency, writing slow code (all of those collection lookups and OO tree traversals are rather expensive!), and making your code difficult to maintain. If you still cannot figure out how to write what you need in an OO-friendly manner, you may need to think about switching languages.

J.Ja

About

Justin James is the Lead Architect for Conigent.

96 comments
SnoopDougEDoug
SnoopDougEDoug

In the greater scheme of things you sometimes are stuck with a specific language. Woe to the developer who just decides to write a routine in Lisp if he/she is the only person on the team who understands the language. Better to write a static Java class than is maintainable by the whole team than a better solution that is maintainable by one. And don't forget code reviews. I've seen a lot of gnarly code get beaten into submission in just an hour or so with the help of colleagues. doug

jose.a.nunez
jose.a.nunez

Static methods and even static classes are not Anti-OO programming. They are there for a reason. We can say inheritance may not be needed many of the times, or even polymorphism. I think the mistake is trying to use those properties when they aren't needed. That just adds unneded complexity.

webx
webx

First, I think the world of programmers has to stop thinking that the only only efficient programming languages are tohse somehow related to C. And second, I honestly beleive that C#, VB.net and related OO languages are ONLY good with mathematical/statistical data. For databases, Xbase compatibles and Foxpro still rocks !. PHp/MySql is ok, but lacks easy representation capabilities in grids, and others like C# and .net are way too complicated. And java(any kind of java) is simply too much strain for a computer.

gwcarter
gwcarter

I agree strongly with Justin James as far as he goes; however, he does not take it far enough. Several times in the text he uses the word "proper", without any indication of what "proper" means. This etlls me that he is making personal esthetic judgements rather than explaining the principles behind the judgements. I concur with his assessment of the first two examples, and with his list of problems whose symptoms are shown inn the examples. I feel left hanging, though, by the omission of an explanation of what he feels is "proper". I am one who must code to survive. Standards and conventions, both of coding style, are the very air I must breathe. Please, Justin, drop the other shoe and tell us whaat you thenk "proper" means. Maybe some meta-standards or meta-conventions?

pccoder28
pccoder28

While I agree in principle with Justin James here, it's important to realize that OO Nirvana comes at a price. It's not easy to get loosely-coupled components and classes in the real world--much planning and analysis is required to get to that blessed state. To do real-world programming, dependencies pop up no matter how well you "think" you've designed your app...redesign is required on the fly. Who really has the time? And, Ruby is just MVC misapplied...it's today's 'golden hammer' anti-pattern writ large. If you really want program correctness, go Haskell, Church et al. OO solves one mess only to recreate the same mess in a different place--it's really the Ghost of GoTos Past come back to haunt us.

Tony Hopkinson
Tony Hopkinson

Before someone has wasted half your coding time doing. Customer.Order[OrderNo].Lines[LineNo].Part.Cost.PerUOM(Box);

jslarochelle
jslarochelle

Static methods are often abused exactly in the way that Justin showed in his example: Procedural code using an OO language (procedures and the equivalent of good old C struct). If someone did this in a really disciplined and consistent manner I am not sure that it would be that bad. However, I can see at least three problems with this: 1) You do not get the full benefit of OOP 2) You would not be able to avoid the impedance mismatch between your code and the libraries that ship with the language because those must be fairly OO. You would inevitably end-up with a mix of procedural and OO code. 3) The procedural code might actually be bad procedural code. I have seen this in pure C code: complicated sequence of if where a lookup table should have been used, ... For most of us (and for the benefit of other people reading this) I think it would be better to learn to do OOP correctly and in this case use static members for class data and static methods for class operations (works with the supplied parameters and possibly static data members). One other correct use of static methods in a OO context is for utility methods that work on build-in types (in Java that would be: int, Integer, float, Float, Date, String, etc...) and returns a value. Generally if one of the parameters of the static method is one of your business classes and you need to read instance data to perform the operation you would probably be better of having an instance method on that class instead of a static method. Watch for circular dependency: often a sign that the data to perform an operation is not all in the right place or the operation (responsibility) is not defined on the right class. Watch for a class that does a lot of get on another class to perform its job (data in the wrong place...) I gave some good references in another entry in this thread. People really interested in improving their OOP skill should check those out ("Object Design" is a very good book). JS

wcannon
wcannon

Yes, there are places that call for static methods -- methods that apply to all instances of a class, factory methods, etc. However, when you see classes with nothing but static methods (or even mostly static methods), you have to ask whether OO is really an appropriate paradigm or whether the programmer really understands how to apply OO. Classes with nothing but static methods (often referred to as utility methods, for example) is really more of a function-oriented style (like the C-language). You pass data in as parameters to one of the functions which operate on the data. Occasionally you need a bit of function-oriented code in the midst of an OO application. However, if you see much of this style, it is more likely that you have some experienced function-oriented programmers who don't really understand how to apply OO principles. I was told in the early days of OO programming (Smalltalk, Objective-C, & LOOPS -- pre-Java) that you really cannot learn OO properly while still working in a function-oriented job -- that you really need to be able to separate yourself from function-oriented work, take time to unscrew your head, turn it around, and screw it back on in an OO way. I've found that to be very true. That's not easy to achieve, in practice, but I've found that telling people that helps them to better turn loose of their function-oriented thinking and better learn to see the OO path through the forest.

Justin James
Justin James

I might discuss that in a week or two, thanks for the suggestion! I kind of sidestepped it, because it is such a huge topic. Proper use of OO (or any other coding style!) is a small book (100 - 200 pages) in and of itself, and even more if you want it to be useful in a practical and pragmatic way. :( J.Ja

SnoopDougEDoug
SnoopDougEDoug

If the only tool you have is a hammer, every problem looks like a nail.

Justin James
Justin James

To me, the price of OO Nirvana is a huge planning stage. I think that OO lends itself very well to those gigantic Waterfall projects that take 6 months to plan and 2 years to execute. Indeed, it probably is the best way to work on a project like that. The simple truth is, on a monolithic project, only a small percentage of the programmers will be "rock stars", and OO helps manage the average and mediocre programmers very well. For smaller projects, I find that OO is often a stumbling block, especially if there will never be a need or even possibility of using anything like polymorphism and such. J.Ja

wcannon
wcannon

I strongly disagree with applying this to only OO. Any programming style can shine when good attention is paid to the design. I don't care about change -- design for change. However, if you don't spend the time on a good design, the code will die in a very short time for lack of maintainability, extensibility, readability, or any number of other ...ility's. If you need something quick and can live with a hack job, fine. But anything that needs to have any lifetime needs to be "designed", not just thrown together. Once it is "designed", you truly can achieve near-"nirvana", whether Object-Oriented, Function-Oriented, or Declarative.

jreddy
jreddy

Object-based code, but not object-oriented code... if (User.Password = GivenPwd) { //do something } Object-Oriented code: if (User.IsPasswordCorrect(GivenPwd) { //do something } All the "rules" of OO cannot be applied in all scenarios of development, or they cannot be applied without too many sacrifices or pain. Almost every application requires data maintenace where all the data "behind" and object must be exposed to be seen on a form, edited by a user and stuck back in the database. However, for all business code (not basic CRUD stuff, but the really important stuff that makes your code "correct") you would be hard pressed to convince me that immutable object-oriented objects cannot be used throughout the business model code. I would argue they can and should be.

Justin James
Justin James

There may (or may not) be more or less languages out there for the JVM compared to the .Net CLR. How many (on either platform?) are in a state close to "complete" or "usable"? The .Net Framework has 4 languages in that condition: VB.Net, C#, Managed C++ (ugh...), J# (double ugh...). It also has 3 more in "nearly great" status: F#, IronPython, IronRuby. The JVM, *to the best of my knowledge* has: * Java * Jython (so-so state) * Groovy (seems to be coming along nicely, from what I hear) Please correct me if I am wrong; I freely admit that my knowledge of the non-Java JVM choices is pretty limited and basic. It really is not about whether or not the JVM is better than the .Net CLR. Indeed, I think that they are both pretty darned good at what they do. I am pretty good at seperating the flaws of the particular VM system from the languages themselves. It is fairly rare that I say anything negative about the JVM or the .Net CLR. However, it does say a lot about the Java world that the JVM and the Java language are synonymous in the eyes of many folks, while it is a rare person indeed who cannot see the difference between VB.Net, C#, and the .Net CLR. J.Ja

jean-simon.s.larochelle
jean-simon.s.larochelle

It had been a while since I last visited this site. Looking at the list of languages I saw some really original (weird?) stuff. Thinking back on some of your last blog entries I thought some of the people involved might actually be interested in some of the languages developed for the jvm. Of course their degree of allergy to the Java platform will be a factor. Also, many of the languages might not be viable for commercial use. Still, it might be worth a look. One good news for Python fan is that the Jython project was updated. So that makes it three language that I know might be ok for commercial use: Groovy (stabilized in 2007) JRuby Jython Have fun! JS

Justin James
Justin James

... is that while most programmers now use OO languages 100% of the time, the projects they work on may be well addressed by an OO language only 50% of the time, or less. As many have already pointed out, OO languages and design are more syntactic hinderances than true aides for many projects, particularly smaller projects. After all, when the project (or problem domain) is so small that abstraction is difficult, why work around all of these interfaces and base classes and sealed this and static that, when really all you need is a way of simply expressing some very straightforward logic? So of course you kludge together a mess (a ton of static classes filled with static methods to emulate what "include" used to gracefully deal with) because you want to get a simple job done, not architect the next OO materpeice. In a nutshell, proper OO requires too much overhead to be useful on a great many projects, pragmatic OO is a wreck, and we are all using OO languages now because no alternative legitimately exists at this point. J.Ja

EM1109
EM1109

It's all OOP Poop...The root of the problem goes back to two distinct issues. How the subject matter is taught either in school or for those out of school in refresher courses. Most examples and post-school courses where OOP was discussed used simple models based on animals, cars, and that does not always transform well into solving business problems that also involve a hefty amount of restraints (politics,etc.) that contribute to OOP diarrea. Now I'm an old timer, pre OOP Poop taught in the early 90s, so my training has been on my own. And I have yet to see many books that tackle OOP effectivly. I will check out some titles other have mentioned. I've yet to see good OOP design for .NET/SQL Crud applications outside of papers I read on Codeproject and other programming sites. Of course, I don't spend a lot of time looking for OOP-Nirvana either. Many companies don't have the time for you to OOP their projects correctly or build a base of business OOP objects properly for the business problems at hand. Very often you come into a company using a mismash of older technologies, promising newer technologies and somewhere in between the truth lies. In fact, more often than not, you will be dealing with management that only knows OOP rhymes with POOP.

Justin James
Justin James

... that situation usually means that I want the library that the mainstream OO libraries come with, but really just need to write a simple procedural application, with an event driven UI. It is times like this that I *almost* think that classic VB made a heck of a lot of sense. J.Ja

Justin James
Justin James

You are right that this is not just an OO specific problem. But with OO languages being the dominant languages in mainstream usage, it is where we see it most often and prominently. J.Ja

Justin James
Justin James

You gave a pretty darned good example there of OO misuse. Heck, it is one that I do on a periodic basis. For me, it is typically a sign of a lack of time and/or requirements that change after the work has started. After all, if what goes in "User" keeps changing why bother putting an "IsPasswordCorrect" method? And in those cases, it really just needs a simple refactoring, but of course there is no time for that either. :( J.Ja

alaniane
alaniane

you need it to be developed at the Business Analysis level. The problem is too often companies pass spec ad-hoc to the programmers. It is next to impossible to use strict OO programming when your spec changes on a daily basis. Some objects can be spec'd out as generic objects and strict OO code can be applied. However, most spec that I deal with does not present itself in a fashion that makes strict OO code worthwhile. I would agree that maybe most business code should be OO; however, I disagree that it can be OO. Most organizations (especially smaller organizations) are not going to spend the time planning and designing at the Business analysis level. They are going to tell you that I need a screen to input x and display report y. When you design the screen for input x then they will say oh we forgot you need to manipulate x by dividing it by w for this case and p for that case. When you have implemented that code, then they will remember that you need to multiply by w and divide by p squared when such and such condition occurs. For OO code to be of benefit, you have to be able to have a stable interface for the objects. After all, the benefit of encapsulation is that you can change the underlying code without affecting how it interfaces with other objects. But, when your spec is in constant flux, you can no longer guarantee that your interface is going to be stable. So, instead of building objects that can be re-used, you start building objects that are project specific. So, you end up with libraries of similiar but not interchangeable objects like the libraries of similar but not interchangeable functions of the past. There is a lot more overhead in maintaining objects as opposed to functions.

jean-simon.s.larochelle
jean-simon.s.larochelle

For a good book on this subject check-out:Object Design. This book presents the "Responsibility Driven" approach and the "Candidate Role Collaborator" technique (a subtle variation on the "Class Role Collaborator" technique). If you really want to hammer down the OOP principles the "Head first" series has a good book on the subject: Head first Object Oriented Analysis and Design. Although this is primarily an introductory text you could view it as intermedite in the way that it will make the principles really stick. JS

SnoopDougEDoug
SnoopDougEDoug

Personally I could almost care less about the supported languages as the level of debugging support. I am so tired of weak-*ss debuggers. I want breakpoints, watches, and would love the old VB "update code and rerun on the fly". That would make us much more productive than most any language. doug

jslarochelle
jslarochelle

This is not a contest but for those interested in alternative language on the Java platform it is interesting to know that alternatives do exist. For a good recent overview (discusses licencing, benchmark and usability) check out: Scripting in Java round two In this article you will learn about the following viable (active and in working condition) alternative: Jacl a subset of Tcl JRuby supports the Ruby syntax. BeanShell 2.0 Capable of interpreting ordinary Java source files Jython a Python implementation Rhino a JavaScript implementation JudoScript has an easy to learn syntax Groovy a dialect similar to Java in some respect but with closures and limited mixin capability Pnuts a language with a syntax similar to Java Be careful about the benchmark because both JRuby and Groovy have improved since this article was published. Both JRuby and Groovy can be compiled to Java .class ahead of time. Both also still support the interpreted mode (with a JIT compiler in the case of JRuby!). Some of the other languages also compile to Java .class. You might also want to check-out the Bean Scripting Framework This as support for the following languages: Javascript (using Rhino ECMAScript, from the Mozilla project) NetRexx (an extension of the IBM REXX scripting language in Java) Python (using Jython) Tcl (using Jacl) XSLT Stylesheets (as a component of Apache XML project's Xalan and Xerces) In addition, the following languages are supported with their own BSF engines: Java (using BeanShell, from the BeanShell project) Groovy JLog (PROLOG implemented in Java) JRuby JudoScript ObjectScript ooRexx (Open Object Rexx), using BSF4Rexx. With the Scripting API in Java 6 this might eventually become deprecated. Make sure you check-out the original reference because there are some really original alternative languages for the Java VM. Have fun! JS

$dunk$
$dunk$

"For example, you want to make a base class or an abstract class consisting of the common points in related types, that is a great use of OO. But it requires planning up front to really identify those commonalities and abstract them out, decide if you want to use a concrete or abstract base clase, interface, etc. " If you are taking lots of time planning on using base and abstract classes upfront then odds are pretty good you are doing something wrong. (e.g. blindly applying patterns, without really knowing why) If you are doing it right then the base and abstract class will almost always define themselves. Anyone who puts a ton of layers on a small project is not very ...umm... skilled (retract my original thought). That is, unless the plan is for this small project to turn into a big one. There's absolutely no reason that an OO project should take any longer than a non-OO project no matter how big or small.

normhaga
normhaga

Thank you J. Ja. Your post now makes sense to me.

Justin James
Justin James

Procedural code breaks things into the smallest action steps needed, which is very easy to do for a smaller program. Really taking advantage of OO means to model the problem domain. For example, you want to make a base class or an abstract class consisting of the common points in related types, that is a great use of OO. But it requires planning up front to really identify those commonalities and abstract them out, decide if you want to use a concrete or abstract base clase, interface, etc. And then you need to write it. And so on. That's a lot of work, particularly when all you really need to do is something trivial. If what you are doing cannot benefit from that work, the extra layers on top of OO are like an achor. If what you are doing *ccould* benefit from it, but you don't take the time to do it, it will be much worse than if you "shot from the hip" in a procedural language. J.Ja

normhaga
normhaga

J. Ja. I learned to program on the 8080/Z80 platform. At that time there were not the plethora of programming languages that there are today, so I learned Fortran, Basic, and Assembly (both psuedo and machine level).o What I learned in assembly was that while it is easy to use flow-through design, you often re-created the wheel and each wheel had different bumps. In self defense, I began practicing modularity in assembly. If you will, structured programming from an assembly perspective. Jump to the present with an eye on the past. I view OO as modular encapsulated code at its simplest form. What I am looking at is that proper coding uses this design architecture from the ground up unless the app is spaghetti code. With this in mind, would you please clarify for me what you mean by "its nature requires architecture and a lot more up-front work than most other styles, otherwise you immediately lose all OO advantages, and probably make the code worse in the process." Thank you.

Justin James
Justin James

I said that there is no way to pragmatically write OO code. OO by its nature requires architecture and a lot more up-front work than most other styles, otherwise you immediately lose all OO advantages, and probably make the code worse in the process. J.Ja

normhaga
normhaga

Why do you say that there is no pragmatic alternative to OO programming? I can think of several if you are old school and willing to use unpopular languages, though your boss may have a cow with some of them and they would be a maintenance nightmare.

SnoopDougEDoug
SnoopDougEDoug

Give me that case of one language--or discipline for that matter--that prevents unintentional use? Were procedural languages taught more correctly in the '80s? Obviously there must have been no bugs in that code, right? Of course OO starts with simple models. What was the first C function? Oh yeah, hello world. Now there was a biz problem solved. And I wondered why company X fired all of its cobol dinosaurs when they rewrote their network code in C++. This curmudgeonly attitude that "the new techniques suck" is because they are new and you do not understand them. How sad. doug

jslarochelle
jslarochelle

...programming technology. Training in APL circa 1979. Fortran and COBOL on mainframe and punch cards! Around the office I am not considered a bad OOP programmer so it is possible to learn the methodology. JS

jslarochelle
jslarochelle

The funny thing about this is that these days I do my procedural incursion in Ruby and Ruby is even more OO than Java (my main language). But I fell perfectly ok with this because the problems that I solve with Ruby are one page long in that language. The last one I did was to extract the last entry in the version control history header for the files modified since a given date and store the file name and extracted programmer description in a .csv file. I guess I could have created a VersionControlHeader class however it would have only added overhead in this case. I might do this in the future if the script expands or if I want to easily reuse the header parsing logic. I guess the principal danger with this kind of script is to keep it procedural beyond the point were it is still ok. The main thing I guess is that if you choose to use a procedural approach you should do it correctly and if you use OOP you should also do it correctly. And in all of this choose the right tool for the job. JS

Justin James
Justin James

Doug - I do that fairly often, sadly. :( It bothers me to know that I could be doing so much more with a language, but can't. It's like having a shed filled with awesome power tools, but only being asked to put new numbers on the mailbox. J.Ja

Tony Hopkinson
Tony Hopkinson

Several times in fact. Delphi was even better than .Net for this, it's class methods can be inherited and or polymorphic. Possibly unncessary in this scenario. :D

SnoopDougEDoug
SnoopDougEDoug

Just make everything static. No mamby-pamby encapsulation, etc. Just give me the bare metal and stand back! doug

Justin James
Justin James

I like OO, a lot. That's why this is titled "stope the systematic abuse of OO", not "stop using OO". :) Like Alaniane said, a huge problem is that the only mainstream languaqes out there with any support are OO languages (or in the case of VB.Net, a poor procedural language transformed into an OO language), so we have to use them for everything. Indeed, one reason why I end up using VB.Net for so many projects (against my ego, pride, and better judgement) is precisely because it is the least OO-esque of the "Big Three". For most of my projects, I simply can accomplish tasks in it faster because it is so procedural-like. J.Ja

alaniane
alaniane

However, I believe in leveraging more than one methodology. For some projects, OO programming is either overkill or complicates matters. I look at the project I am given and then I determine which parts best suits OO, proecedural, or functional development. The same with database applications; I believe in letting the database do what it's best at. I look at what program functionality I can write procs to accomplish and what functionality cannot be efficiently done on the database side. Why bring unnecessary data into your app when you can summarize it on the database end? The same goes with OO programming. Some functionality is still best accomplished procedurally. I have no qualms about using Cobol to accomplish batch processing.

jreddy
jreddy

OO really rubs people the wrong way somehow. I think too many people have only seen OO applied by some OO fanatic nut-job that thinks objects should know how to display themselves on a web page, and that the benefit of OO is reuse. I'll confess to being an OO enthusiast (maybe just short of bigot). But, I can tell you that I work on many projects that have much fluctuation, absolutely no waterfall design, and are of different sizes with developers of all skill levels. And I will tell you that because of all these things I demand OO development from my teams. I think most modern-day agile developers doing OO development will tell you that do it for the simple separation of concerns. If you tell me that the powers-that-be keep redefining what a User is then for the love of God wrap it up in a User Class so the rest of the team can easily keep track of what a user object is today. Furthermore, when they redefine it next time I know where all the changes are that will be affected by it...in the user class or related classes. For those who have somehow gone sour over OO and think it is overkill I am sorry for the missed opportunity to simplify your programming lives. If you were to ask me why I do OO programming I would answer the same way that authors Charles Richter, Arthur J. Riel, and other current OO authors would answer: to simplify things. I have to make it easier to understand, use, change and test my code. After over 15 years of programming I have not found a better way to do this then to use OO principals. OK, I could go on and on with this. Like any other development mehod, design, or approach you can go overboard and ruin a good thing. I can tell you that I often feel the need to slap OO develops on the back of their head when they get all inheritance or polymorphic happy!

Bad Boys Drive Audi
Bad Boys Drive Audi

You have no idea how in complete agreement we are regarding this. People forcing a pattern where it doesn't fit HAS made me scream as opposed to your "makes you want to scream". That's why I wrote "notice patterns" as opposed to force a pattern. Between implementing correct OOP and pattern use, my job has become easier. Not less work, mind you -- they seem to throw a lot more of requests/work in my team's direction than to peer groups outside my domain. I guess those are the spoils of success...

Tony Hopkinson
Tony Hopkinson

Look for the patterns your model exhibits, not the far too often make the model fit the pattern. Lets see I'll implement a factory class pattern under a communication patterns, throw in a few observers and I get this! Right WTF is it? Makes you want to scream.

wcannon
wcannon

Good point. Having worked most of my career where the software IS the product, or is a major contributor to the product, I must appologize for slighting other software development environments.

Bad Boys Drive Audi
Bad Boys Drive Audi

"They are going to tell you that I need a screen to input x and display report y. When you design the screen for input x then they will say oh we forgot you need to manipulate x by dividing it by w for this case and p for that case. When you have implemented that code, then they will remember that you need to multiply by w and divide by p squared when such and such condition occurs." I get that stuff all the time. In fact, I don't expect the business to give me hard requirements all the time -- I consider it my job as a "professional consultant" (I'm an employee but what do we really do?) to steer them in the right direction. Along the way, I notice patterns...patterns in their behavior, patterns in how I have to steer them, patterns in how requests or requirements come in, and patterns in the requirements themselves. I can't tell you how many programs I've written based on the Strategy pattern or how many are based on the Subscription pattern. The point is if you look at this from another angle, you might be able to reduce your stress and workload if the ever changing requirements conform to some sort of pattern. Check out Head First Design Patterns for a practical and very entertaining introduction to common patterns. You'll be glad you did.

alaniane
alaniane

number 1 should lead to short business duration; however, in actual practice a lot of businessses that have been around for decades are using the number 1 approach. Especially, small to medium size businesses are guilty of number 1. When your business is not software-oriented then you can successfully exist without having to be overly concerned about properly designing your custom apps. You may not be as efficient as you could be; however, a poorly designed app is not likely to put you out of business. That is one of the reasons why it is difficult to convince management to spend more time in designing their custom software.

wcannon
wcannon

There are two issues mentioned here: (1) spec's being thrown over the wall to programmers, and (2) having to have a stable interface for OO to work. (1) Spec's being thrown over the wall won't really work for any duration in any type of business, programming being only one of them. This is a recipe for disaster in all but the shortest-duration of businesses. However, those doing the throwing may need to be taught that there is a better way (e.g., by those on the receiving end). (2) Software CAN be designed to embrace changes. However, by their very nature, object-oriented programming fits best when the interface (functions/operators) is relatively stable and the number of classes(types) is the thing that grows/changes. Function-oriented programming, on the other hand, fits best when the number of types(classes) is relatively stable and the number of functions/operators on those types is dynamic. Therefore, when the spec is in a state of flux, what is most likely to change -- the functions/operators or the types/classes? OO is not always the best choice. To shoehorn function-oriented requirements into an OO language is a recipe for frustration.

alaniane
alaniane

reality and theory. Everything looks fine in theory, but is a pain in reality.

Tony Hopkinson
Tony Hopkinson

goes past it's sell by date. Inserting a new class in a hierarchy. Implementing Interface methods as do nothing stubs because reworking that would be too painful. Adding yet another function to a library because you don't want to risk breaking the similar one..... I don't want to do any of them :( Back in the good old days an interface was effectively a method signature and it was right git to change in a common method. In the brand new days of OO, an interface is effectively a class and it is a right git to change in a commonly used one. This is called progress.

Tony Hopkinson
Tony Hopkinson

There are rules, but if it can safely run the offending line with no side effects it will do it. One of things I used to hate about this feature with VB6, is you would pile away blurt code all over the place, get it working, and then when you built, discover 981 errors from the fag ends of previous incarnations of your idea. VS2005 is a more responsible fellow in this regard, not to mention .Net being easier to police.

Justin James
Justin James

VS 2005 had those features, even the "stop, change, and continue" deal, VERY useful! I think that may have been VB.Net only until 2008, but I am not 100% sure. J.Ja

Editor's Picks