I like to state the single responsibility principle this way: “Every thing you write — every module, class, interface, or method, should have one job. It should do the whole job and only that job. Notice that some of these things you write are big (modules), some are small (methods), some are in between (classes), … Read more
Most uses of full scale Multiple inheritance are for mixins. As an example: class DraggableWindow : Window, Draggable { } class SkinnableWindow : Window, Skinnable { } class DraggableSkinnableWindow : Window, Draggable, Skinnable { } etc… In most cases, it’s best to use multiple inheritance to do strictly interface inheritance. class DraggableWindow : Window, IDraggable … Read more
Its not the same problem. In the original problem, the overriden method can be called from A. In your problem this can’t be the case because it does not exist. In the diamond problem, the clash happens if class A calls the method Foo. Normally this is no problem. But in class D you can … Read more
No, I don’t think so at all. It is worse practice to have a class full of instance methods which don’t actually depend on a particular instance. Making them static tells the user exactly how they are intended to be used. Additionally, you avoid unnecessary instantiations this way. EDIT: As an afterthought, in general I … Read more
A mixin is typically used with multiple inheritance. So, in that sense, there’s “no difference”. The detail is that a mixin is rarely useful as a standalone object. For example, say you have a mixin named “ColorAndDimension”, which adds a color property and width and height. Now, you could add ColorAndDimension to a, say, Shape … Read more
The real difference is not ownership (composition versus aggregation), but rather type-information. A Decorator is always passed its delegatee. A Proxy might create it himself, or he might have it injected. But a Proxy always knows the (more) specific type of the delegatee. In other words, the Proxy and its delegatee will have the same … Read more
Changes to a value parameter are not visible to the caller (also called “pass by value”). Changes to a reference parameter are visible to the caller (“pass by reference”). C++ example: void by_value(int n) { n = 42; } void by_ref(int& n) { n = 42; } void also_value(int const& n); // Even though a … Read more
Use an interface if you want to define a contract. I.e. X must take Y and return Z. It doesn’t care how the code is doing that. A class can implement multiple interfaces. Use an abstract class if you want to define default behaviour in non-abstract methods so that the endusers can reuse it without … Read more
When it comes to DI, there’s a lot of conflicting use of terminology out there. The term Poor Man’s DI is no exception. To some people, it means one thing and to others it means something different. One of the things I wanted to do with the book was to supply a consistent pattern language … Read more
instanceof simply breaks the Open/Close principle. and/or Liskov substitution principle If we are not enough abstract because of instanceof usage, each time a new subclass makes an entrance, the main code gathering the logic of the application might be updated. This is clearly not what we want, since it could potentially break the existing code … Read more