Stack Exchange network consists of 183 Q&A communities including Stack Overflow, the largest, most trusted online community for developers to learn, share their knowledge, and build their careers.
Reason #4: iff is assumed for documentation. "The function returns True if foo is larger than bar" → everyone assumes it returns False in any other conditions.
@user949300 Think of how it would be without the builder traveling across the system. You'd be forced to have a class with a huge fan-out factor, and that is just necessary to build the Thing. (Of course, assuming your class doesn't concentrate all the knowledge, this is what we wanted to avoid in the first place.) Now, if this class has any other responsibility, you're creating a huge class, breaking S in SOLID. If that's the only responsibility, you're making yourself a ThingBuilder.
"How do you name a specific usage of a string if you don't know where it will eventually be displayed?" Wouldn't this be a sign of a flaw with the design, where it mixes logic (deciding where to show it) and presentation (actually showing it). It would be very weird for you to construct some text with regional data but treating it like any other internal data object that you can move around.
@Spoike Thanks for the response. Based on what you say, I can understand LSP as not extending classes on public properties/methods that other entities depend on. From an OOP design and responsibility assignment perspective, that makes sense. Still, I usually find the rule expressed in the other way around for the substitution test (e.g. stackoverflow.com/a/56904/147507). Which way is LSP correctly tested? (Note that while derived classes will implement the base classes, they may still not work, e.g. stackoverflow.com/a/4428800/147507)
