08-02-2018 08:25 AM - edited 08-02-2018 08:40 AM
@Ironman_ wrote:
Interfaces are implemented with Decorator pattern
it makes sense
I presume that's sarcastic because it doesn't make a lot of sense at all. Decorating can give some aspect of extended behaviour without inheritance but decorating is also composition. The decorator has the original object as a data member. It typically has to be strictly-typed for the class you're decorating and as such clearly doesn't replace interfaces. I mean, it's definitely a way forward but the statement "Interfaces are implemented with Decorator pattern" is just not correct.
08-02-2018 09:10 AM
Decorators are more a workaround for (lack of) multiple inheritance. Interfaces, multiple inheritance, traits, decorators are all solving the same problem in different ways (each with different pros and cons).
Don't forget about the malleable VI approach! It's a lot like an interface, except not dynamic.
In the example, you can invoke clone.lvclass:clone.vim on your vehicle object and your human object iff the implement a clone.vi method, that doesn't need to do anything but call clone.lvclass:clone.vi (not sure how clone would work), even if vehicle and human are not in the same hierarchy. But you can't put vehicles and humans in an array and then invoke clone on the elements. So it works when wiring static classes to the .vim, but no dynamic dispatching. When making a library of utilities for an application, this might just be enough (and certainly a huge step forwards).
For a real solution, we have to wait...