If you are going to use OOP, study an OOP language

This is something that tends to get my goat a little in some instances, so I apologise if I get a tad ranty.

We had a recent discussion on cfaussie about the this scope in CFCs, and whether or not it was an appropriate place to store data. Regardless of what the outcome of that conversation (and we all have varying opinions on the topic), there was one thing that became very prevelent to me:

There seems to be a bunch of people out there trying to write OOP code, without a full understanding of OOP concepts.

Unfortunatley I think that this is one of the pitfalls of CF – because it is so easy to write code, people can often think that they can just 'work it out on the fly' and they will be just fine.

Sometimes this is true – and sometimes it isn't. I know quite a few proficient coders that have come to many of OO's basic concepts through trial and error, but I don't think it is the most efficient way of doing things.

The simple fact of the matter is – OO concepts have been around for many years, so why would you try and guess them when you can find them out by studying a OOP language?

If you want to do OOP Programming with ColdFusion, go and study an OOP Language, and bring the theory of it back to ColdFusion.

I cannot possibly encourage this enough. Doesn't matter if it's Java, C++, Eiffel, SmallTalk, whatever. What you are looking for is the concepts and theories.

Basic software design concepts and terms such as:

  • Coupling
  • Cohesion
  • Encapsulation
  • Inheritence
  • Polymorphism

I feel should be understood before really useful OOP Coldfusion code can be developed.

By undertaking some Object Oriented training of some kind, I can assure you that many pieces of software design will make so much more sense to you, and will become a far greater ColdFusion coder because of it.

I just want to make clear here as well – I am NOT saying that if you don't understand these terms or concepts, you are a bad coder, or that you write bad software. Far from it. People have different backgrounds, and different skills and come at things in different ways. So I apologise if I have offended anyone.

I just want to make sure that all of us that talk about software (and web development is software development) use the language, terms and vocabulary that have been around for many years.

 

Leave a Comment

Comments

  • Tim Lucas | June 30, 2004

    I agree with you Mark.

    There is a lot of information and people to learn from but you must speak the lingo before you can start. It’s like trying to participate in the finance world without understanding the acronyms used in the finance section of the newspaper.

    If you say that you are a good software developer without knowing the concept of cohesion, it is like somebody telling you they are a professional stock broker but not knowing what a dividend is.

    Personally, my programming skills have developed very little whilst using CF. Recent journeys which have taught me the most are Objective-C (+Cocoa) and the Java web app frameworks.

    Real mastery and knowledge comes when you’re applying knowledge across domains, as this shows you understand the underlying concepts, regardless of the technology being used.

    If you only know CF then I second Mark — learn other languages and the techniques being used by that language’s professionals.

    and p.s. Mark — you forgot Abstraction =)

  • Sean Corfield | June 30, 2004

    I concur – but then I’ve always encouraged folks to become multi-lingual. Learn languages that are radically different to your primary language(s) so that you get a new perspective on life. Learn Java because it’s so widely useful. Learn Prolog and Smalltalk and Haskell (as examples of unusual languages).

  • Tom Minderson | May 10, 2006

    Some of us would like more evidence that OOP is really better and not just a personal preference. Most of the decent examples are from systems software, not the business domain. I think interfaces tend to be more stable in systems software and that is why it works well there. But business systems tend to need a lot of sharing between entities, objects, or whatever you call them and change a lot. Fat, bloated interfaces simply create a bunch of red tape and rework. Further, I find Set Theory better than inheritance and polymorphism for managing classifications/taxonomies and variations on a theme. OOP ignores the lessons of set theory, so I lean toward relational-centric designs instead. Set theory is simply a better underpinning and I predict will someday replace or transform OOP.

  • Tim Lucas | May 10, 2006

    Tom: Well Mark did say "I am NOT saying that if you don’t understand these terms or concepts, you are a bad coder, or that you write bad software. Far from it. People have different backgrounds, and different skills and come at things in different ways."

    I’d love to hear more about your thoughts on set theory, maybe even an intro for those not having looked into it (since college at least). Possible blog post for you Tom?

  • Tom Minderson | December 25, 2007

    Tim, for an example of how to use "feature sets", google: "Payroll Example – OOP vs P/R". It compares Robert Martin’s OOP payroll example to a table-oriented version.

  • Sean Corfield | December 25, 2007

    Tom, all those search results seem to lead to B Jacob’s "Tablizer" blog and, frankly, the guy’s a bit of a fruit loop in my opinion. He’s famous on the ‘net for one thing and one thing only: waging a one-man campaign against OOP. Wherever he pops up, he’s bashing OOP and pushing tables. I wouldn’t pay much attention to him.

    Now, if a whole bunch of independent people were really saying the same – and promoting his views everywhere – I might be more inclined to take him seriously.

  • Tom Minderson | April 21, 2009

    You seem to being using popularity as your measurement technique. I’m just asking you to study the two payroll example versions for the code design itself, not worrying about the authors or their reputation. Good code written by Hitler is still good code.

  • Sean Corfield | April 21, 2009

    Ah, Godwin’s Law in action…

    http://en.wikipedia.org/wiki/Godwin's_law

    FWIW, yes, I read the examples. The Tablizer version has no business logic and does little more than read the DB and print it with a few calculations. Adding any functionality that involves business logic is going to be much harder than with the Fowler solution.

    The problem is that the solution as presented is far too simplistic for the benefits of OO to be seen.

    I’m working with a client right now, taking a procedural Fusebox application and refactoring it into a more OO approach and the client is already finding it much easier to follow the code and much easier to maintain.

  • Tom Minderson | May 9, 2009

    Re: "The Tablizer version has no business logic and does little more than read the DB and print it with a few calculations." – I don’t think you understand the purpose of the design: it’s a payroll framework, not just a one-shot generator. It can *integrate* biz calculations from different sources (and different paradigms). As far as "FuseBox" (FB), I agree FB can be very annoying. You are beating up a straw-man, essentially. A lot of things improve upon FB, not just OOP. FP was born mostly because ColdFusion lacked real user-defined functions for a good while.