Encapsulation – the pitfalls of Object-Oriented Programming - Andrzej Jóźwiak - TomTom DevDay 2023
0 likes49 views
The document critiques encapsulation and object-oriented programming (OOP), particularly highlighting issues with inheritance, state management, and shared references between objects. It suggests that the complexities of OOP can lead to confusion and suggests design strategies such as minimizing state and preferring immutability. Ultimately, it encourages a thoughtful approach to structuring code to avoid common pitfalls.
Encapsulation – the pitfalls of Object-Oriented Programming - Andrzej Jóźwiak - TomTom DevDay 2023
- 1. Encapsulation – the pitfalls of Object-Oriented Programming Andrzej Jóźwiak
- 2. Or am I just exaggerating? The root of all evil?
- 3. Or am I just completely mad? But why?
- 4. We mostly write CRUD applications in all honesty! Performance
- 5. Is there anyone who still defends it? Still, it almost touches the problems with OOP Inheritance
- 6. What is the similarity between Age of Empires 2 and Minecraft's armor stand? Age of Minecraft?
- 7. Or you can just call it hierarchy if you like Taxonomy
- 8. By combining state and functions, but why? Abstraction
- 10. Just some state and behaviours? What is an object? Object State Behaviour State State Behaviour Behaviour
- 11. Private information hidden behind a public interface What is an object? Object Message Message Message Message
- 12. Message passing, or is it? How do we pass the messages? Most importantly what do we pass? What is an object? Object Object Object Object Object Object Object
- 13. Or is it a bad practice? Should messages pass references? class Foo(val value: Int) { fun doSomething(bar: Bar) { //... } } class Bar(val value: String) { fun doElse(baz: Baz) { //... } } class Baz(val value: String) { fun doDifferent(foo: Foo) { //... } } val foo = Foo(value = 2023) val bar = Bar(value = "DevDay") val baz = Baz(value = "TomTom") foo.doSomething(bar) //if we pass the references bar.doElse(baz) //and they become the internal //state baz.doDifferent(foo) //then who owns them?
- 14. Object should be solely responsible for its internal state? Should objects share references? class Foo( val bar: Bar, val baz: Baz, ) class Bar(val value: String) class Baz(val value: String) val bar = Bar(value = "DevDay") val baz = Baz(value = "TomTom") val foo = Foo(bar, baz) val qux = Qux(bar, baz) //both Bar and Baz instances are part of the internal //state of Foo and Qux, so which one of these two //has full responsibility of its encapsulated state? class Qux( val bar: Bar, val baz: Baz, )
- 15. But with some extra steps! Isn't this just shared state? Bar Baz Foo Qux If Baz and Bar are part of Foo's internal state... If Baz and Bar are part of Qux's internal state... Does it mean that Qux can affect Foo's state? Does it mean that Foo can affect Qux's state?
- 16. Then objects should not be shared and have only a single parent? If encapsulation is about hiding... A B D F G C E A B C D E F G Let's change a free form graph to a tree!
- 17. Then what should we do if we need to communication between objects? If everything only has a single parent... A B C D E F G A B C D E F G
- 18. Are we doomed? Imagine that static does not exist... A B C D E F G A B C D E F G
- 19. If you squint your eyes isn't this the same as with any taxonomy? Maybe we need to change something... A B C D E F G A B D E F H G C New Object Maybe soon will not be needed? New root object How many times we will have to do it?
- 20. Better safe than sorry... Spaghetti code leads to injuries!
- 21. Yes, yes it can! Can encapsulation be premature?
- 22. Imposing structure is worse than no structure at all! Think about data and processing separately! Class hierarchy Single responsibility Composition graph Objects data flow Object transformation Temporal dependencies Design patterns Behaviors Module relationship
- 23. Nothing special just a simple association Let's play a game State State State State State State State Behavior Behavior Behavior Behavior Behavior Behavior Behavior Behavior What to do with leftovers?
- 24. IThinkIWillNeedItController JustForThatOneThingHelper IDoNotKnowWhereToPutItManager Let's put them in a Manager, Controller, Helper or a Do-er! What to do with leftovers? State State Behavior Behavior Behavior
- 25. Should Message send itself? Should Message receive itself? The OO dilemma
- 26. About the preaching I was not totally honest...
- 27. 1. Write methods when the association with the data type is certain. It is easy to get it wrong! 2. Minimize state instead of only segregating it. 3. Prefer immutability for the shared state. 4. When all hope is lost parametrize the behavior. 5. Polymorphism is not limited to only classes! 6. Prefer pure functions, if not constrained by the efficiency. 7. Encapsulate on module/namespace level. 8. It is ok to sometimes repeat or have redundant pieces. Long functions are not wrong. 9. Limit surface layer. It is much easier to comprehend only a few functions comparing to thousands of small ones. So how should we design our code?
- 28. Thank you for sticking till the end! Any questions?