Pitfalls of OOP and when to do functional

[julianschoep]

Nice writeup! I think there are some very nice principles explained and the AI field really should figure out its design patterns more. Great initiative!

I have a some suggested additions:

• Hiding complexity: abstraction through OOP has the trap that complexity gets hidden from the reader. This can make code very hard to read or understand unless managed well. This can also be a trap for functional though.
• Stateless programming: OOP encourages statefull software design which has strong disadvantages, especially around testing, maintainability and complexity. Functional combined with stateless can be incredibly liberating once you get used to it.
• Composition over inheritance: I think the drawbacks of inheritance are worth to mention and alternatives proposed.
• Data classes: data classes are a powerful python tool where you can get some benefits from OOP but statelessness from functional if applied well.
• Function scope and reuse, function naming, variable naming

Overall I'd suggest to highlight more the pros and cons of using classes vs using functions, and give readers a deeper understanding when to apply which.
In my personal opinion, the ML field tends to be too OOP oriented. Many engineers use classes for everything while it's not always the best way. Because of the stateful nature of classes and the tendency to hide complexity, I actually try to avoid using classes as much as I can.

Very curious about your thoughts on this!

[opcode81]

Hi,

we are glad you like the content. Thank you for your suggestions!

Our aim is to keep the scope of this material as narrow as possible, focussing chiefly on topics that are of great relevance to the machine learning field in particular and which are not specifically covered in detail elsewhere.

As you correctly observed, we are obviously strong advocates of OOP. We believe that the benefits of OOP strongly outweigh the downsides. We do, however, concede that OOP is not easy to master. A lot of the perceived downsides of OOP, which you mentioned, often appear as a result of a sub-optimal use of OOP concepts; when applied correctly, OOP results in elegant, highly maintainable code that is easy to comprehend. If you can achieve the same goals without using OOP, then that's perfectly fine, but we would argue that, especially in Python, it would, at the very least, not be straightforward to do so.
If you have examples where a purely functional approach is clearly preferable to an object-oriented approach, we would be interested in learning more about them, as they could prove to be valuable additions to the content of this repository.

• Composition over inheritance: This is indeed a relevant point, and we have added a corresponding issue Anti-pattern: Using inheritance instead of composition #12.
  If you would like to contribute to its resolution, please let us know.

• Hiding complexity: The fact that complexity can be hidden from the user is a feature rather than a "trap". A class should present to the user a simple interface which is clearly described and ideally small. If the SOLID principles are followed (especially "single responsibility"), this should not result in code that is hard to read at all. Encapsulation makes clear that the functions contained in an object serve a common purpose and private/public declarations separate the interface from internals.

• Stateless programming: The fact that OOP enables the encapsulation of attributes and methods is an advantage, not a disadvantage. Note that the use of attributes does not necessarily make the code stateful, as attributes can also simply store static configuration of an algorithm. The choice to mutate attributes should always be a conscious one, and mutation should be applied only when the mutation is indeed a "natural" translation of a real-world concept to the implementation in code. The fact that you have the option to use mutation does not in itself encourage bad design; having options is a good thing, but we have to know when to use them and when not to use them.
  Note that we have already written a piece on functional vs object-oriented solutions, which elaborates on many important points to consider: see anti-pattern higher-order functions
  If you indeed try to avoid classes as much as possible, what do you think of our refactoring journey, where our approach is very strongly OOP-focussed?

• Data classes: They should be a staple in anyone's toolbox, but they should only be used in place of a regular class in cases where the class serves primarily as a container for data.

• Function scope and reuse, function naming, variable naming: To keep the scope of the content as focussed (on ML-specific topics) as possible, we decided to not include such topics for now.

Dominik & Kristof