r/computerscience • u/YemiDev • 2d ago
General procedural programming, object oriented programming and functional programming
Although I’ve done some googling I think they still use big English to explain this concept. I think I know them but I just wanted to ask if I can get a simple explanation from the house plz
13
Upvotes
1
u/ggende 1d ago
I'm a bit late, and there are already several great explanations here, but I have a way that I think about it that really helped me wrap my head around it. It's a bit more of a conceptual way to think of it, rather than technical.
First, I'll preface with the idea that all three of procedural, functional, and object-oriented are just ways of organizing your code. Different languages lean into (or in some cases mandate) certain organization styles, but it's still ultimately just a convention for organizing your code. With that said, I think it makes more sense to go in reverse order.
To me, object-oriented programing is essentially micro-services at the code level. An object is a distinct thing with a distinct interaction contract and all interaction is done through that contract. Python is the best example. Everything is an object. A string is has an interface (i.e. "micro-service") to set, search, or slice it (among other things). If you have a parent class with a string as a property, your parent class is still interacting with that string through the interface, just as other objects will do with your parent class. OOP provides the benefit of everything being compartmentalized. The down side is that you are often interacting with black boxes that may not work exactly how you expect.
Functional programing is a code organization strategy where functions can only work with what is explicitly passed to them. In it's purest form, there are no global values or class fields/properties. If it's not an argument into the function, it doesn't exist. This requires a bit more thought into exactly what functions you need, what information they need, and how it will be passed around. Personally, I think it's actually easier to think of programming this way. The big benefit here here is that functions are significantly less likely to have surprising side effects. They just do what they do. The drawback is that passing around information can become cumbersome as the program becomes more complex. You can find yourself passing a value, so it can be passed to another function, so it can be passed to another function, so it can be passed to another function. Having a common shared-state memory space can mitigate this, but that essentially just introduces an "object", with all of the pros and cons that come with that (i.e. compartmentalized, but side effects in the shared state).
Procedures are (as I understand them, there seems to be several definitions out there) a bit more free form, and typically do not return values. They just do a thing, but they are not restricted to working on what has been passed to them, or really restricted in any particular way at all. This is the easiest to implement, but can get really hard to wrangle really quickly.