I generally prefer IEnumerable<T> as well. The main thing is to ask yourself what actual (even minimum) functionality is being returned from the method (or passed to it, in the case of a method argument). If all you need to do is enumerate over a result set, then IEnumerable<T> does exactly that. No more, no … Read more
Subclasses overriding methods in the base class are totally allowed by the Liskov Substituion Principle. This might be simplifying it too much, but I remember it as “a subclass should require nothing more and promise nothing less” If a client is using a superclass ABC with a method something(int i), then the client should be … Read more
Subclasses overriding methods in the base class are totally allowed by the Liskov Substituion Principle. This might be simplifying it too much, but I remember it as “a subclass should require nothing more and promise nothing less” If a client is using a superclass ABC with a method something(int i), then the client should be … Read more
The most effective way to break applications is to create GOD classes. Those are classes that keep track of a lot of information and have several responsibilities. One code change will most likely affect other parts of the class and therefore indirectly all other classes that use it. That in turn leads to an even … Read more
why do you need an additional Pipeline class ? I think you can remove the middle man. this will make your api simpler, for example: Step<Integer, String> source = Step.of(Object::toString); Step<Integer, Integer> toHex = source.pipe(it -> Integer.parseInt(it, 16)); toHex.execute(11/*0x11*/);// return 17; you can implement your pipeline pattern simply in java-8 as below : interface Step<I, … Read more
It means that you should put new code in new classes/modules. Existing code should be modified only for bug fixing. New classes can reuse existing code via inheritance. Open/closed principle is intended to mitigate risk when introducing new functionality. Since you don’t modify existing code you can be assured that it wouldn’t be broken. It … Read more
According to the very popular WWDC 2015 talk Protocol Oriented Programming in Swift (video, transcript), Swift provides a number of features that make structs better than classes in many circumstances. Structs are preferable if they are relatively small and copiable because copying is way safer than having multiple references to the same instance as happens … Read more
A great example illustrating LSP (given by Uncle Bob in a podcast I heard recently) was how sometimes something that sounds right in natural language doesn’t quite work in code. In mathematics, a Square is a Rectangle. Indeed it is a specialization of a rectangle. The “is a” makes you want to model this with … Read more