I am a retired Systems Analyst. I spent most of my time designing and programming using 4js Genero BDL (a 4GL Language) and an Informix Dynamic Server SQL database. I wrote many smaller programs rather than one large program as it made the process more manageable. Each program had one purpose.
I have been trying to figure out Why or When I would need to use OOP. I have written a few small Python programs that do use classes and methods but I don’t feel that they simpler or gained anything by using methods as opposed to just plain old functions.
So, Why or When I would need to use OOP?
1 Like
Welcome, tolok.
The reason I use one or the other just comes down to whether the data I am representing makes most sense as an object or bits. That is, in the past I have written software to control robots, and, mentally, structuring the program in an OOP style makes the most sense. Other times, I have written software to calculate fibre optical parameters, and, mathematically, functional programming made the most sense.
So, that is what it boils down to, for me; if what I am representing makes more sense as an object, I find it easier to program through OOP principles/styles.
It is kind of like how there is nothing you cannot store in a relational database that you can in a non-relational database, but, sometimes, it is easier to work with one than the other purely in terms of structure.
Hope this helps
3 Likes
It depends of what are you trying to build, design and solve.
Python is an OOP language so everything on it is classes and objects, although you can still use it as a procedural language on the surface.
OOP is one of the more sensible ways to maintain state, especially where’s there’s a lot of localized state. Encapsulation helps to maintain both the local state and invariants that regulate that state. If you don’t have a lot of localized state changing over time, you may get bigger dividends with other methodologies like FP.
And by OOP, I don’t just mean object.method(args) syntax. Just func(data, args) where the function always acts to transform the data is still very much OO. But in a language like python that lacks static types and overloading, the former syntax is what you’ll need to get polymorphism, which is an important property for abstraction no matter what methodology you’re using.
2 Likes
I personally like to consider if the problem I’m solving would be helped by modeling it into Objects. So for example, if I’m building a game, it requires a lot of states and entities. Such a situation would be a good place to take an OOP approach so the code models the actual overall problem better.
However if I need to transform some data into another form, such “transformation logic” would be better modeled with a more mathematical/functional approach.
There are pros and cons to taking an OOP approach, so like most programming paradigms it isn’t a “be all end all”.
2 Likes
I guess I have never seen a very good example of OOP. My programs were designed to manage information stored in the SQL database. Some of the simplest ones would just allow find, add, change and delete. Some would have links to display other information based on the record on the screen. Others were reports. Input a bit of information and generate a report.
OOP is really good at simulation-type programs: not only do the domain objects model real-life objects that we have accumulated lifetimes of experience reasoning about, they also tend to maintain a lot of local state and exchange messages with each other. In fact the term “Object-Oriented” was first coined for Simula, a language designed for simulations (actually, it was coined for Smalltalk then retroactively given to Simula)
The OO paradigm is taking somewhat different directions these days compared to the OOP of 20 years ago: for example, it’s common for many TypeScript codebases to use only interfaces, literal objects, and standalone functions, never using the class statement or the new operator at all. Scala 3 is based on something called the “DOT Calculus”, which fuses together functional and OO concepts.
I think the more important distinction these days is not between OO and FP, it’s between dynamic/loose and static/strong typing. The more you have of the latter, the more your programs can be expressed declaratively in terms of types rather than collections of functions or methods. At that level, OO vs non becomes mostly (though still not entirely) a matter of syntactic style than actual semantics .
1 Like
This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.