4 ms·
Damn, you really nailed it with that car example, because I can already see the sort of errors that might arise: * did not call putFeetInCar before adding driv
by d23 6y ago
Damn, you really nailed it with that car example, because I can already see the sort of errors that might arise:
* did not call putFeetInCar before adding driver
* did not call putShoesOnFeet before calling putFeetInCar
* did not call gripKeyInHand or set up HandKeyAllocator
* did not set up HandKeyAllocatorManager or use KeyDashboardMeldConnector to insert key into KeyHoleDoodadInterfaceXConnector
* did not do correct incantation of prayer to Cthulu to ensure AxelAlignmentProtocol is properly specified
- brundolf 6y agoMan, this really is the crux of it for me: when the focal point is a series of opaque state mutations, there are exponentially more ways to do those steps in the wrong order than the right order. And the contracts for those methods have absolutely zilch to say about what they assume has already happened or will happen after they're called. You just have to know (or hope somebody wrote it down in English). This is my biggest pain point/source of anxiety when working in an OOP codebase. And then guess what? Suddenly you're extremely concerned with the internal state of those objects. Because understanding it is essential if you want to have any hope of actually using them. And the great irony is that this completely undermines one of the main benefits of OOP: private state that the outside world doesn't have to care about.
- Toutouxc 6y ago> did not call putFeetInCar before adding driver > did not call putShoesOnFeet before calling putFeetInCar That's bad architecture, not an OOP flaw. These should've been private methods called and error-handled properly from driver.prepareForDriving, or even implemented as a DriverPreparedForDriving subtype. > did not set up HandKeyAllocatorManager or use KeyDashboardMeldConnector to insert key into KeyHoleDoodadInterfaceXConnector All these sound like bad OOP (or Java) to me, a HandKeyAllocatorManager is not a thing in the domain. I'd rather build my logic around objects like HandsContents, KeyKeyholeCompatibility or SeatedDriver.