FP vs OOP

I hope with the main documentation many of you understood some of the reasons why I structured the architecture or framework for Catbot in a certain way. And hopefully, you agree with some of the syntax decisions that were made, but many of you might still be like "well, why make all of this when OOP in C++ is sufficient enough to handle all of Catbot by itself?" You might be right and, to be very honest, I agree that OOP can work. However, I consider OOP to be the biggest pitfall for many programmers and declaring this architecture is my way to fight against the heavy usage of OOP. I have several issues with OOP as the only paradigm of choice. The biggest issue, I see, with many students that have never actually programmed outside of classes is that they only know the OOP paradigm and can not wrap their minds around completely opposite paradigms like Functional Programming. Now, it is true that languages like Java allow heavy usage of classes and OOP patterns,(You can say the only supported paradigm of the language is OOP) but the language's popularity is a clear signs of failure in my opinion, and the structure of the software for Java gets very messy the more classes we write, which is something I wanted to avoid as a programmer since that could cause documentation that is 4 times longer than this documentation and will have logic spread out all over the code base. When we learn patterns like mediator patterns, strategy patterns, and absolute factory patterns they all have their upside but most of them have downsides and none of them are a bullet proof solution that is the answer to all of the projects. I could not have agreed more when one of the Youtuber I referenced to create this architecture said the following: "OOP patterns are just a bandage for where OOP fails the most." I still believe having a fundamental knowledge of OOP is important to have in the back of our minds as it suggest good ways to think about software architecture,(Note that we still do use some OOP like simple factory, strategy, etc. but without classes of course) but using OOP as the ONLY solution is where I believe is the failure for all of the patterns. Thats why I like to put OOP aside when programming and just write code like you are coding from scratch and write simple and intuitive and completely procedural code. You might also realize all of the state management modules use functions and almost no classes and this is the reason.

This architecture could not have worked if it was not in Python, and I am very firm on this stance as Python supports OOP paradigm, but not completely. When we try to do full OOP in Python, a lot of us, traditional OOP users, will be like "well, how do you do private methods? How do you do interfaces?" And I do not have answers to all of those questions, but these things can conceptually be applied when we use this Catbot architecture. For example, if you want to make a private method, you can embed functions into the device classes directly and that is private because none of the script files have access to those class instances. The public methods are all of the methods declared outside of the device classes, so if you want private methods, thats a good way to think about it. You can also have inheritance of these methods by declaring methods for generic devices which can be used by all of the masked devices with one caveat being that you can not add more private methods. This allows us to reuse classes, and prohibiting additional private classes is to prohibit logic spread out into multiple files.

However funny enough, the architecture also punishes some uses of OOP within the class of python because if we tried to make any methods within the device classes, those methods are, again, "private," and we physically will not be able to call them in the script file. This means you will have to create a useless public method declared outside of the class that just calls the private method. This goes against the D.R.Y. principle and thus should never be done.

For programmers that is used to writing a lot of classes in Java code, this might be a tough syntax to work with, but think of this architecture as an exercise to use alternate paradigm and think differently than what you were taught in class. However, at the same time be thankful as I sort of brought the good side of OOP into python. If this syntax challenges you, then I am very happy because it means that my architecture is working the way it was intended: to open our minds and think differently.

• Hiroto Takeuchi