Exactly,

The point that Kevin does not realise or does not understand is that design patterns described by the Gang of Four (GOF) were essentially build on the the restrictions of C/C++ and actually most static typed languages.

The whole idea(s) :) about design patterns was born out of the complexities of the compiler needing to know the type upon compilation and the lack of compile and execution of code in runtime. Of course many of them still have value in dynamic languages but they are (much) easier to implement (or somtimes invisible as they are directly supported by the language).

The factory is the most obvious as even as the object is created the compiler still has to know its definition or you're left with reflection (which is a kludge anyways) to actually do something with it. In dynamic languages there is no such restriction. Of course there are ways of using interfaces etc.. but it seems to defeat the purpose.



>># of lines of code is, at best, a specious argument. A seasoned developer who has previously solved other problems may wind up leveraging previously-written code - the resulting # of lines might be longer...so what? That doesn't mean it's "less easy"
>
>OK, then let us describe it in terms of what needs to be done and how it gets done. To apply a factory pattern, so that it can be used for
>
>loObj=oFactory.create("mytoken")
>
>there needs to be a factory.dbf (or other table), and the code in the factory class needs to
>
>- get the table (make sure it is open etc),
>
>- find the record with "mytoken" in the name field
>
>- .newobject(classfield, classlibfield) with possible complication if parameters are to be passed to object's init
>
>- return the object, or return .null. if anything is screwed up.
>
>Now how do you do that in a static language?