Question

What OOP principles, if any, don’t apply or apply differently in a dynamically typed environment as opposed to a statically-typed environment (for example Ruby vs C#)? This is not a call for a Static vs Dynamic debate, but rather I’d like to see whether there are accepted principles on either side of that divide that apply to one and not the other, or apply differently. Phrases like “prefer composition to inheritance” are well known in the statically-typed OOP literature. Are they just as applicable on the dynamic side?

For instance, in a dynamically typed environment, it would seem that the granularity of coupling goes no further than the level of the method. In other words, any given function call only couples the caller to that particular interface, which any class could possibly satisfy — or to put it another way, anything that quacks like that particular duck.

In Java, on the other hand, the granularity of coupling can go as high as the package. Not only does a particular method call establish a contract with another class/interface, but also couples it into that classes/interface’s package/jar/assembly.

Do differences like this give rise to different principles and patterns? If so have these differences been articulated? There’s a section in the Ruby Pickaxe book that goes in this direction a bit (Duck Typing/Classes Aren’t Types), but I’m wondering if there’s anything else. I’m aware of Design Patterns in Ruby but haven’t read it.

EDIT — It has been argued that Liskov doesn’t apply the same in a dynamic environment as it does in a static environment, but I can’t help thinking that it does. On the one hand there is no high-level contract with an entire class. But don’t all calls to any given class constitute an implicit contract that needs to be satisfied by child classes the way Liskov prescribes? Consider the following. The calls in “do some bar stuff” create a contract that needs to be attended to by child classes. Isn’t this a case of “treating a specialized object as if it were a base class?”:

class Bartender
    def initialize(bar)
       @bar = bar
    end

    def do_some_bar_stuff
        @bar.open
        @bar.tend
        @bar.close
    end
end

class Bar
    def open
        # open the doors, turn on the lights
    end
    def tend
        # tend the bar
    end
    def close
        #clean the bathrooms
    end
end

class BoringSportsBar < Bar
    def open
        # turn on Golden Tee, fire up the plasma screen
    end

    def tend
        # serve lots of Bud Light
    end
end

class NotQuiteAsBoringSportsBar < BoringSportsBar
    def open
        # turn on vintage arcade games
    end
end

class SnootyBeerSnobBar < Bar
    def open
        # replace empty kegs of expensive Belgians
    end

    def tend
        # serve lots of obscure ales, porters and IPAs from 124 different taps
    end
end

# monday night
bartender = Bartender.new(BoringSportsBar.new)
bartender.do_some_bar_stuff

# wednesday night
bartender = Bartender.new(SnootyBeerSnobBar.new)
bartender.do_some_bar_stuff

# friday night
bartender = Bartender.new(NotQuiteAsBoringSportsBar.new)
bartender.do_some_bar_stuff

Answer 1

The essential difference you are touching on I think are:

• languages group 1. the actual methods that are invoked when eg object.method1, object.method2, object.method3 are called can change during object’s lifetime.

• languages group 2. the actual methods that are invoked when eg object.method1, object.method2, object.method3 are called cannot change during object’s lifetime.

Languages in group 1 tend to have dynamic typing and to not support compile-time checked interfaces and languages in group 2 tend to have static typing and to support compile-time chcked interfaces.

I would say that all OO principles apply to both, but

• some extra (explicit) coding to implement (run-time instead of compile-time) checks may be required in group 1 to assert that new objects are created with all appropriate methods plumbed in to meet an interface contract as there is no compile-time interface-agreement checking, (if you want to make group 1 code more like group 2)

• some extra coding may be required in group 2 to model changes of the actual method invoked for a method call by using extra state flags to call submethods, or to wrap up the method or a set of methods in a reference to one of several objects attached to the main object, where each of the several objects has different method implementations, (if you want to make group 2 code more like group 1 code)

• the very restrictions on design in group 2 languages make them better for larger projects where ease of communication (as opposed to comprehension) becomes more important

• the lack of restrictions on design in group 1 languages makes then better for smaller projects, where the programmer can more easily check whether the various design plumbing constraints are met at a glance simply because the code is smaller

• making code from one group of languages like the other is interesting and well worth studying but the point of the language differences is really to do with how well they help different sizes of teams ( – I believe! 🙂 )

• there are various other differences

• more or less leg-work may be required to implement an OO design in one language or another depending on the exact principles involved.

---

EDIT

So to answer your original question, I examined

http://c2.com/cgi/wiki?PrinciplesOfObjectOrientedDesign

AND

http://www.dofactory.com/patterns/Patterns.aspx

In practice the OO principles are not followed for various good reasons (and of course some bad) in a system. Good reasons included where performance concerns outweigh pure design quality concerns, wherever cultural benefits of alternate structure/naming outweigh pure design quality concerns and where the cost of the extra work of implementing a function not in the standard way for a particular language outweighs the benefits of a pure design.

Coarser-grained patterns like Abstract Factory, Builder, Factory Method, Prototype, Adapter, Strategy, Chain of Command, Bridge, Proxy, Observer, Visitor and even MVC/MMVM tend to get used less in small systems because the amount of communication about the code is less, so the benefit of creating such structures is not as great.

Finer-grained patterns like State, Command, Factory Method, Composite, Decorator, Facade, Flyweight, Memento, Template method are perhaps more common in group 1 code, but often several design patterns apply not to an object as such but to different parts of an object whereas in group 2 code patterns tend to be present on a one pattern per object basis.

IMHO it makes a lot of sense in most group 1 languages to think of all global data and functions as a kind of singleton “Application” object. I know we’re getting to blurring the lines between Procedural and OO programming, but this kind of code definitely quacks like an “Application” object in a lot of cases! 🙂

Some very fine-grained design patterns like Iterator tend to be built into group 1 languages.