SOLID Go Design
There&#x27;s something strange about application of the Liskov Substitution Principle in the article.<p>Original formulation of LSP was: subtypes should not break supertypes, i.e. caller expecting supertype should not be able to tell the difference when getting an instance of subtype. That was expressed in terms of an explicit subtype&#x2F;supertype relation, like inheritance in OOP. When there&#x27;s no such thing in the language, the LSP becomes (quote article):<p>&quot;Two types are substitutable if they exhibit behaviour such that the caller is unable to tell the difference.&quot;<p>This sounds almost like a tautology. I understand that it isn&#x27;t, since &quot;substitutable&quot; is &quot;you substitute class X for interface Y in your code&quot; and &quot;observably same behaviour&quot; is &quot;X behaves like all implementors of Y are expected to&quot;.<p>In practice, X doesn&#x27;t declare it implements Y. If I review a change to X I might miss that fact. If that change breaks behavior expected from Y, it&#x27;s bad.<p>I&#x27;m not sure if this scenario is a real problem, I have written like 100 lines in Go.