liskov-substitution-principle

enum WeatherType { case cloudy(coverage: Int) case sunny case windy } I just saw this in a Swift tutorial and I can't believe they allow you to do that. Now, whenever I switch on that enum, I gotta create a special case for cloudy ! You don't "gotta" do anything. If you don't care what the coverage is, don't ask what the coverage is. If you don't care if it's cloudy, don't ask if it's cloudy. There is nothing special about the way you write a switch for a case that has an associated value. Suppose we have this: let weather = WeatherType.cloudy(coverage:1) Then this is perfectly legal: switch

When we have an object hierarchy that is purely a inheritance of semantic and not of behaviors,then inevitably we need to write "instanceof" or "if/else" everywhere to do run time type checking. E.g. If I have a object hierarchy which has Class Function Class Average extends Function Class Sum extends Function Class Max extends Function If there is a method called calculate() in these classes, then we do not have problem, we can just take the advantage of polymorphism and this design satisfies the LSP. However what if we do not want to add this calculate() method to this hierarchy for some

I always see advices in this site of overriding getPreferredSize() instead of using setPreferredSize() as shown in these previous threads for example. Use of overriding getPreferredSize() instead of using setPreferredSize() for fixed size Components Should I avoid the use of set(Preferred|Maximum|Minimum)Size methods in Java Swing? Overriding setPreferredSize() and getPreferredSize() See this example: public class MyPanel extends JPanel{ private final Dimension dim = new Dimension(500,500); @Override public Dimension getPreferredSize(){ return new Dimension(dim); } public static void main

Liskov-substitution principle requires that subtypes must satisfy the contracts of super-types. In my understanding, this would entail that ReadOnlyCollection<T> violates Liskov. ICollection<T> 's contract exposes Add and Remove operations, but the read only subtype does not satisfy this contract. For example, IList<object> collection = new List<object>(); collection = new System.Collections.ObjectModel.ReadOnlyCollection<object>(collection); collection.Add(new object()); -- not supported exception There is clearly a need for immutable collections. Is there something broken about .NET's way of