My name is Gil Zilberfld. We’ve discussed your post on our webcast “This week in testing”. We’ll be happy if you can comment, and if you like the discussion and content, let us know. And everyone else.

Thanks,

Gil Zilberfeld Typemock

Julian.

I don’t mean to rid the entire SOLID acronym.

I think SL still apply and are the primary sins I see committed in most ruby or python code I’ve looked at, however toss out “O” and “I” because I don’t think either make sense now, and for D we need to rethink what that means for these types of languages.

some good points but we’re in your examples disagreeing on definition issues mostly. Ruby may be different but in Python I’ve seen the term monkey patching used for class replacement.

So score card:

SRP: agree

OCP: disagree ( still a bit confused here since by definition everything is open for extension AND modification even at runtime no matter what you do or how you code)

LSP: we both agree still applies even moreso

ISP: we both agree

DIP: disagree

So I’ll just touch on where we disagree OCP I covered, IoC what I’m trying to point out here is that fundamentally ALL client code can modify all code and even globally replace calls to that other code. Are there times when you want to force (I should say encourage) clients to make a choice of implementation? absolutely and I think that still applies , but the benefits of flexibility and testability provided by IoC still apply whether the client calls new or not.

I do advocate another concept here as applies to dynamic languages only because I think there is something to be said for encouraging integration points explicit and how to go about doing that in a perscriptive fashion is needed.

End of the day the benefits of O and the D of SOLID I’d argue we get even if we try to prevent them.

great examples, overall. however, i don’t agree with your premise that we don’t need SOLID in dynamic languages.

i’m not sure i agree w/ your table of how dynamic languages do things where a static language would use SOLID. all of the SOLID principles still apply in object oriented, dynamic languages. they are just implemented in different ways. … my comments here are specific to Ruby, as it’s my only real exposure to dynamic/duck typing (other than javascript, but i never did any of this with js).

SRP is still SRP. you’re right that there’s no change, here.

OCP i still important. monkey patching can be a violation of OCP if it’s done poorly or for the wrong reasons. i’ve used OCP in my Albacore framework in a number of places and it has saved me hours of headaches, prevented ugly / leaky abstractions, and made the task in question easier to understand.

LSP is a major concern when monkey patching. LSP is not a “technical” principle, to begin with. it’s all about semantics and meaning. changing the meaning of an object or method through monkey patching is still an LSP violation.

ISP is still ISP, for sure. but technically everything is an object – all objects have an implicit interface.

DIP is still valid, as well. the difference is we’re not dealing with explicit interfaces like c# or java. the client object is still expecting to find a specific method signature on the server object. the difference is that the server object does not have an explicit interface to implement. the implicit interface must still conform to the expectations of the client code, though. in this way, the client code should still own the abstraction / interface that is being called. the client code should be the one that determines when the interface definition changes, still.

… also I don’t think your outputlib example is monkey patching. that’s more a case of a factory pattern and polymorphism, facilitating OCP/LSP. monkey patching is used to open the type (or class or instance or …) of an object and modify code in that object, at run time. you’re really just providing a different implementation of the same interface, in that example.

-derick