numinous vs olympic abstractionshttps://twitter.com/LTF_01/status/1004061149812404224 …
-
-
well, look, we're talking about traditional by-the-book OOP so at some level you have an interface defined for both Car and Windshield so you are by no means required to have getters for all 30 properties, only the ones your interface defines.
-
building on that though, if windshield is a public member attribute then you don't have to go through with all the boilerplate of pushing up one layer of encapsulation. presumably you want to do that because the example I showed has a IoC/dependency injection thing going on.
-
it might not though. you get just set or reset the windshield after object construction. that's not wrong, per se, it just means that in your design spec the windshield component is an interface.
-
you'd only be violating Law of Demeter if the windshield wasn't an interface but you could fux with it anyway.
-
i've never seen the LoD read that way and it's hard for me to see how it could be, it seems to be very definitely saying that if X composes Y and your point of contact is with X you should only be calling methods on X not retrieving Y and calling methods on it
-
exactly. LoD in its most orthodox form pushes for single point of contact, uniform interfaces. in practice that almost never happens.
-
i mean, i'm fine with the Suggestion of Demeter
-
that's what the dutchman decided on and I think it was correct
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.