1. 2
  1.  

  2. 10

    May I ask why you originally tagged this as formalmethods? I do a lot of work on FM advocacy and am always interested in hearing how outsiders conceive of it.

    Individual comments:

    The implementation of this principle is a lot harder, however. Meyer suggested to use inheritance to achieve this principle. However, this results in tight coupling, as we will discuss in the Interface Segregation Principle and the Dependency Inversion Principle. […] Therefore, Martin came up with a better approach: use polymorphism.

    It’s important to know the context here. Bertrand Meyer wrote OC for Eiffel, which has much stronger inheritance features than most modern languages. It handled multiple inheritance a lot better, too. Using interfaces was a way of adapting OC to less inheritance-first languages, not because Meyer’s suggestion is de facto tight coupling.

    Yeah. What she said. As you might have guessed, Liskov is a mathematician.

    Liskov is a programmer and a computer scientist. She wrote that paper for programming language theorists, where that kind of terminology is common. Her subtyping work is based on subtyping in general; Martin adapted it into the LSP (Liskov herself only heard of the principle later).

    I’m not the biggest fan of the SetWidth argument, because it has too many holes: “What if Square also implements SetWidth, and it changes both?” Then you have to add in explanations about testing etc. A model I like better is that compatible subtypes should be “droppable” into a base type such that for all functions on the type, drop(f(obj)) == f(drop(obj)). Then Square fails LSP with SetWidth more easily.


    I’m overall not a fan of SOLID in principle: it bothers me that so many people associate “the right way to do software” with one person’s Usenet post.

    1. 8

      As always with Principles, I find these good ideas in some situations, but bad if followed rigidly.

      I remember a job where I had to deal with a codebase that strictly followed the “always define interfaces for everything” principle. (It was in Java, which seems especially prone to interface-itis.) Learning and navigating was a mess because when I looked up a method, Eclipse took me to the interface, and then I had to find the implementation, or worse, figure out which of multiple implementations was probably being used at that call point. And of course there were twice as many classes and source files to navigate.

      I do use interfaces in my (C++) code where it makes sense, in specific prominent APIs that represent boundaries between subsystems and/or which might need multiple implementations. Bit I also keep in mind that virtual (polymorphic) methods are expensive.

      My replacement for this rule would be to use interfaces when the API seems high level and decoupled from a specific implementation. If you come to this realization after implementing it, refactor.

      In fact my biggest coding principle is Always Be Refactoring.

      Update: One style issue:

      This principle was first introduced by a woman, Barbara Liskov. She was eventually rewarded a Turing Award for her contributions to the design of programming languages and software methodology.

      I’m sure you didn’t mean it, but this comes off as patronizing or condescending, like you’re saying it’s rare and extraordinary for a woman to do CS or math. I’d remove the words “a woman”.

      1. 1

        I’m sure you didn’t mean it, but this comes off as patronizing or condescending, like you’re saying it’s rare and extraordinary for a woman to do CS or math. I’d remove the words “a woman”.

        I see what you mean, and therefore I have removed it. Thank you.

      2. 12

        We were STUPID. And so was our code. Thank god, we have SOLID.

        This tells me clearly and upfront that the article is just a piece of dogma regurgitation. No thank you.

        1. 1

          In that case: you are welcome for letting you know early. ;-)

        2. 1

          Safari is giving me a “Deceptive Website Warning” when I try to follow this link.