5 ms·
I’m gonna buy the book but I prefer composition over OOP. I prefer to have an init that takes some params where those params are fully baked clients of whatever
by gigatexal 2y ago
I’m gonna buy the book but I prefer composition over OOP. I prefer to have an init that takes some params where those params are fully baked clients of whatever services I need and then the class just uses them as needed. I don’t see a lot of value in having a Python class that might have a few or more classes that it extends where all the functions from all the classes crowd up the classes namespace.
Class Foo.__init__(self, db, blob_storage, secrets_manager, …)
Instead of class Foo(DB, BlobStorer, SecretsMgr)
Etc
- yxhuvud 2y agoWhy on earth do you put composition and OOP as opposing techniques? Composition is just one more technique in the OOP toolbox and there is nothing in OOP that mandates an inheritance based architecture.
- crabmusket 2y agoMainstream OOP languages (looking at you Java) have failed to make composition as convenient as inheritance.
- flakes 2y agoThe common toolkits today (spring boot, google guice, etc) are much more focused on composition over inheritance, by injecting arguments and implementing pure interfaces rather than extending base classes. Older legacy Java frameworks and bad teachers are more at fault than the Java language itself IMO.
- crabmusket 2y agoI take your point, though having `extends` as a first-class language feature surely encouraged that culture and approach in older frameworks right?
- flakes 2y agoThere are some valid cases where extends really can help, and IMO the language would feel limited without it. Maybe if the language designers had their time back they could have taken an approach like Golang with nested structs and syntactic sugar for calling their attributes/methods. The main reason I see new devs opt for extends, is because that was 99% of the content in their Java 101 programming course, not because it exists in the language. Imagine how many more `friend`s we would have in cpp if that was crammed down everyone's throats? :)
- yxhuvud 2y agoHow is composition inconvenient?
- mdaniel 2y agoContrast the Java way class Delegated implements Base { final Base b; public Delegated(Base b) { this.b = b; } @Override public void printMessage() { b.printMessage(x); } @Override public void printMessageLine() { b.printMessageLine(x); } with the Kotlin way https://kotlinlang.org/docs/delegation.html#overriding-a-member-of-an-interface-implemented-by-delegation https://kotlinlang.org/docs/delegation.html#overriding-a-mem... OT1H, yes, sane people using IJ would just alt-Insert, choose delegate to, and move on with life. But those misguided folks using VS Code, vim, or a magnetized needle and a steady hand would for sure find delegating to a broader interface to be a huge PITA
- _old_dude_ 2y agoVery true, in Java, at least in the last 20 years, inheritance is de-facto deprecated, all new bits and bolts like enums, annotations, lambdas or records do not support inheritance. So you have to use composition.
- watwut 2y agoHow is composition in Java inconvenient?
- inopinatus 2y agoThese are complementary not contradictory ideas. One of the principal takeaways from the Ruby edition (and many of Sandi Metz’s conference talks) is undoubtedly a mindset of, and techniques for, writing compositional OO code.
- Toutouxc 2y agoThen you're going to be pleasantly surprised, because composition is actually a genuine OOP technique and Sandi Metz advocates for exactly this kind of sane OOP focused on encapsulation and objects making sense, instead of masturbating with class hierarchies.
- gigatexal 2y agoI used to work at a flask shop that did views with 3-5 or more inherited classes. Nobody could really follow how everything worked. It was insane. Anyways yeah give me composition and flat classes all day long.
- gigatexal 2y agoWhat’s funny is I did composition for a take home project when interviewing at a place and they said the approach was too complicated and failed me for it. They wanted multiple inheritance instead. Fair enough. Their codebase probably had a lot of it and my not showing it probably told them I didn’t understand it.
- bccdee 2y agoBut I've read the book, and her solution to the "bottles of beer" problem involves encoding all the logic into an elaborate class hierarchy! I'm not rabidly anti-OOP, but the point at which I turn against it is when the pursuit of "properly" modelling your domain with objects obscures the underlying logic. I feel like this book reaches that point. This is her stance on polymorphism: > As an OO practitioner, when you see a conditional, the hairs on your neck should stand up. Its very presence ought to offend your sensibilities. You should feel entitled to send messages to objects, and look for a way to write code that allows you to do so. The above pattern means that objects are missing, and suggests that subsequent refactorings are needed to reveal them. Absolutely not! You should not, as a rule, be replacing conditional statements with polymorphic dispatch. Polymorphism can be a useful tool for separating behaviour into modules, but that trade-off is only worthwhile when the original behaviour is too bloated to be legible as a unit. I don't see an awareness of that trade-off here. That's my problem.
- 2y ago
- vram22 2y ago>I’m gonna buy the book but I prefer composition over OOP. The GoF book (the design patterns book) says in a page right near the start, "Prefer composition over inheritance", in the middle of an otherwise blank page, presumably to emphasize the importance of that advice. As others have replied, composition is one technique you can use in OOP, not something that is the opposite of OOP. You can also use composition in non-OOP procedural languages like C, by having a struct within a struct. https://www.google.com/search?q=can+you+have+nested+structs+in+c https://www.google.com/search?q=can+you+have+nested+structs+...