Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
I am reading about SOLID principles. In Ruby tutorials and code samples, I often see subclass extensions like:
class House
attr_reader :items
end
class Room < House
attr_reader :chair
end
p House.chair = 'baroque_style'# => NoMethodError
Of course the examples are useful to show how easily classes are manipulate in ruby, but isn't this a violation of the Liskov Substitution Principle?
No, LSP states that if S is a subtype of T, you should be able to use an S whenever a T is expected.
In your example, Room is a subtype of House, so we should be able to pass an instance of Room to anything expecting a House. What you then do is to pass a House into code expecting a Room (so you are using a T, where an S is expected).
T.method1.is_a? String and S.method1.is_a? FixNum)
T and S respond to, it's about the methods that instances of S and T respond to. The important thing about the LSP is the history rule. The fact that the subtyping relationship between function types is contravariant in the subtyping relationship of the argument types and covariant in the subtyping relationship of the return types was well-known long before that (and is kind-of obvious anyway). The novel contribution of the LSP is a) the formulation in terms of substitutability and b) the history rule, which makes …
Oct 27, 2015 at 20:31
Cat and Mammal are better examples than Room and House. Sub-classes should, in general, follow an "is-a" relation (so, neither a "has-a" or "exists-in").