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
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.