Discussion – Is OOP for OCD?

by

[Repost from Jan 31 2007]

Recently, I’ve been playing around with compiling ActionScript 3.0 with strict mode turned off. This makes everything much more loose. Type checking is thrown out, classes can be dynamically altered – essentially, you sacrifice speed and rigourousness for flexibility and forgiveness. In other words, it’s compiled more like AS1 was compiled.
I’ve also been spending some spare time looking at Objective-C (the language used for Mac programming). Obj-C adds functionality to C which makes it sort of object oriented but in reality, it’s very loose. The book I’m reading seems to glorify the dynamic nature pointing out how nice and flexible it is to try to access something that might not exist within an object. Obj-C programmers tend to break the “is a” rule using inheritance to gain functionality rather than identity. Even though it all curdles my blood, it’s hard to deny that this is a system which allows you to very quickly (and fairly elegantly) create working applications.

So my question to you is this.
Is all of the effort that we as developers put into creating object oriented, well defined, interface driven, decoupled code worth the effort?
Is there a value in keeping things loose and dynamic?
Should we shun languages that make this impossible or difficult?

  • http://thefactoryfactory.com/wordpress joshua noble

    I like strictly typed languages and I especially like reading other peoples strictly typed code. I think having freedom is ok and there is a lot of speed to be gained from being able to do, well, dang near everything, but really, do you like debugging Javascript or C? People like typing because it makes their thought processes easier (?) and people like loose typing cuz it makes their coding easier (sometimes).

  • http://adeave2.com Abayomi Ade

    This is a very worthy post. Solid question, is the effort we put into a well defined interface with decoupled code worth it? well if its allows working applications quickly and elegantly then there is a payoff with cutting development times, however the languages that make this impossible and difficult are probably structured in their ways due to conventional/standard api. Its sorta a double edge sword I think.

  • http://losdesigns.com Mims Wright

    I personally really like OOP and highly structured coding practices for the same reasons as you mentioned. It’s loads easier to work with especially when working in a team or on larger projects. I’m hoping someone has a strong argument for why non-OOP is good.

  • http://blog.iconara.net Theo

    Strict typing and loose coupling are not condradictory. Loose coupling is something you get from good OO design, and you can achieve it in strictly typed languages just as well as in dynamically typed languages.

    Strict or dynamic typing is just a property of the compiler. In ActionScript (but not in all languages, C++ is different, but Objective-C is the same) types are not preserved, objects still have a type, but variables (if you can call them that at runtime) are not typed. In effect these two lines are identical once they have been compiled:

    var connection : NetConnection = new NetConnection(…);

    var connection = new NetConnection(…);

    However, at runtime, the object is still a NetConnection object, but that the variable “connection” has the type NetConnection is lost.

    Loose coupling is about designing your application so that you can change the implementation of one component without having to change another. This is achieved by good OO design and the use of design patterns. The choice of language is not important, although I can agree that some languages are better suited to good design than others.

  • http://losdesigns.com Mims Wright

    Good point Theo. I suppose I should list an example of what I meant when I was referring to non-decoupled code. In Obj-C there is a concept called a key path where you can create a string of properties you wish to access such as myData.creator.name.lastName . This is used in Cocoa’s binding feature and obviously could create issues if, for example, creator changed somehow. I agree that using code like this is a choice we make. I only bring it up because it’s mentioned in the book I’m reading (http://www.bignerdranch.com/products/cocoa1.shtml) as a good thing – or at least the author doesn’t condemn it.

    Also, I was under the impression that AS3 code is strictly typed at runtime. I’ll have to double check. Were you referring to that or AS2?

  • http://flashmonkey.servehttp.com/wordpress Ian

    The problem with loosely typed languages, is what might have been a compile or runtime error goes unnoticed. What might have taken a few hours to resolve is instead lost, hidden deep in the application, only to rear it’s ugly head at a later date – keeping you in the office all weekend scratching your head.

  • http://posercoder.com Poser

    Another thing to consider about a structured OO based application is how it fits within a development culture and your companies organizational structure.

    Capturing the structure of your application in something like UML even just at “critical” points can start to provide a great primer to a new person on a project. It also is just a good form of communication, it often becomes an easy way to solidify a design for future reference. Think of how critical UML is in design patterns and how great the ratio is of words to mental constructs when I say “that class is a singleton”.

    An appropriately sliced OO structure can also provide for a better experience with your application within a version control system. If you take a 10,000 line application and break it into an average of 20 classes compared to 60 your distribution of labor during a nasty merge can be better distributed. This becomes even more apparent on larger code bases where packages come into play and thus distribution of labor can happen at a package level and within a package while the architects observe from above watching commits and questioning when necessary.

    When you get some nicely decoupled OO structures you may also start to find that the fallout from a new bug is rather well defined and smaller in its footprint.

    A loosely typed language can be difficult to debug, but wrapping it in a nice decoupled interface with some decent support for inversion of control (dependency injection) type failures can become much easier to identify at run time. I find that you need a good debugger more in a dynamic language.

    In short for me, OO allows me to go on vacations more often than with some of the functional or procedural applications I have running around, because with some simple cultural rules the dependence on the “architect” to survive a bug or analysis for a new feature is reduced. But that is mostly due to the culture that surrounds my OO applications.

  • Erik

    I just love code hinting, something you get with strong typing. It saves me time if I do not have to open my other files to see how I called a certain property.

    Greetz Erik

  • http://www.spirituc.com/pt/grupo/contactos/ Luis Neng

    I think a strictly typed language is better for beginners because they’re able to learn much more about the language characteristics. It is also better for team working since everybody is following the correct way to code.

    For a single programmer, the loose type can give him some advantages in “Lines of code per day”, he will be able to get the job done faster with some hacking. I used to do this in AS2 on some web design and developments, taking advantages on the class inheritance to write less code. In AS3 strict mode, everything is different but the “copy & paste” is still working! :)