my opinion swings back wildly between this being a piece of crap busywork generator and Good Actually, i think there's some boundary to do with how much of a Thing the composed entity is
-
-
if you're trying to do traditional OOP it's "good, actually". if you're using a different paradigm it's only piece-wise good. separate discussion entirely as to when and where OOP is a good choice (spoiler: much less often than OOP is used in practice).
1 reply 0 retweets 2 likes -
tbh i have no idea whether i'm doing trad OOP or some freakish variant at this point but coming it at it from a real object-level POV it's hard to see what having to build the glue to call car.getWindshieldThickness() instead of just doing car.windshield.getThickness() buys me
2 replies 0 retweets 1 like -
Replying to @chaosprime @danlistensto and
but i know there are cases where i felt like that glue was definitely the best thing; apparently they're a little more esoteric because i can't produce one on demand) so i'm left feeling like it's the usual "overstate the applicability of a rule to try to get ppl to do it at all"
1 reply 0 retweets 1 like -
maybe you're misunderstanding it? this is Law of Demeter compliant implementationpic.twitter.com/XRVAZwlrA5
2 replies 0 retweets 1 like -
right, honestly when windshield has 30 properties the clutter of basic bitch getWindshieldThickness()es offends me
1 reply 0 retweets 2 likes -
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.
1 reply 0 retweets 1 like -
Replying to @danlistensto @chaosprime and
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.
1 reply 0 retweets 1 like -
Replying to @danlistensto @chaosprime and
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.
1 reply 0 retweets 1 like -
Replying to @danlistensto @chaosprime and
you'd only be violating Law of Demeter if the windshield wasn't an interface but you could fux with it anyway.
1 reply 0 retweets 1 like
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.
1 reply 0 retweets 2 likes -
i mean, i'm fine with the Suggestion of Demeter
1 reply 0 retweets 3 likes - 1 more reply
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.