Design patterns are interesting in that its focus is on dynamicness (if that's even a word) and allowing the code to morph during run-time.
Well, I don't know if I'd use the term "morph"; The code isn't actually changing. In most cases, there is simply another level of indirection that is used to determine who should/shouldn't receive a message. We'd probably be better off saying something like "decisions are delayed until runtime".
I understand what that means but the term 'interface' is overloaded.
WTH were you thinking! You overloaded 'interface' -- really?! JK... I couldn't resist. =)
Does this mean strictly to an interface like:
public class MyClass implements iMyInterface
Or is it loose pertaining to both interfaces and virtual classes? Just curious...
I'm not a huge fan of the religion known as software engineering, so my answer tends to always be "Do whatever produces the most elegant code -- period", which may or may not be such a good idea. I tend to do this quite a bit in Java: interface <-- abstract class <-- ... (if needed) <-- concrete class(es). However, I let the "most elegant code" rule dictate, so a less complicated program would probably not have the interface, while a more complicated or more general/larger program, might not only have the interface, but also have additional lower interfaces and abstract classes.
Quite a bit of OOP design (ie design patterns) assumes that you're using a language like C++, C# or Java where the message passing paradigm is much more "static" than in something like Smalltalk or LISP (and, to some degree, Obj-C). Of course, the people teaching this SE stuff try their best to be language agnostic and would argue that the design should be created without regard to the language, but let's be realistic, if your language doesn't support feature X, then you might not be able to implement pattern Y, or the implementation might be so confusing and ugly that you just say forget it (or you might not need to implement pattern Y if your language supports this pattern "invisibly").
I'm a bit rushed at the moment, but if we start getting into some patterns, I've always found the differences in implementation strategies to be somewhat interesting. Someone pick one or two of the patterns worth discussing*. We can move forward from there. *Except MVC, I'm soooo sick of that pattern!