For quite some time I've been wondering if procedural programming has any advantages over OOP or if it's just personal preference. In which situations should I prefer the procedural style if there're any?
Edit: Deleted the poor example.
Is there any reason to prefer procedural programming over OOP
Seems like a bad example. I wouldn't use either style, if all you're doing is assigning 5 to an integer.
Author
Sorry for the poor example. What I wanted to represent is that I have some data and a set of functions which operate on them.
ALL programming consists of functions that operate on data, though.
I've been programming for so long that the distinctions between programming styles no longer mean anything to me. They're just different representations of the same underlying processes. It's just a matter of how conveniently the language lets you represent what you want to do. The specific thing that the program needs to do is what I'm interested in - it lets me decide how I want to implement it. This is why I didn't like your example; it doesn't do anything, and there's no context for why you might want to encapsulate that integer or not, so there's no need to pick a particular solution.
You should use whatever style you prefer, based on your knowledge of the problem you want to solve and the possible options the language and APIs allow you to pick from.
I've been programming for so long that the distinctions between programming styles no longer mean anything to me. They're just different representations of the same underlying processes. It's just a matter of how conveniently the language lets you represent what you want to do. The specific thing that the program needs to do is what I'm interested in - it lets me decide how I want to implement it. This is why I didn't like your example; it doesn't do anything, and there's no context for why you might want to encapsulate that integer or not, so there's no need to pick a particular solution.
You should use whatever style you prefer, based on your knowledge of the problem you want to solve and the possible options the language and APIs allow you to pick from.
In general, I would say no.
Both procedural and oo programming have strong points and weak points, without much overlap in my experience. Throwing away either blindly in favor of the other is doing yourself a huge dis-favor.
The tricky part however is to know when to use procedural programming, and when to use oo programming.
I think we don't even know or agree on how to write procedural code or oo code on its own, let alone we understand when to use procedural and when to use oo, and how to combine them.
oop is based on the idea that you have data and operations on them. This seems to me the most clear-cut oo paradigm.
Procedural programming is based on the idea that you have data, and you have functions (input and output). Functions take some data, and produce other data,
like y = f(x) in math.
These are both extreme cases, in oo, a function 'belongs' to one data. In procedural programming, functions exist on their own.
A good example is "main". You get a "do-it" call from the OS, but there is no object attached to that call.
The trouble arises when you have 'something-in-between' cases. A nice example is equality, where does equals(a, b) belong? oo languages firmly put it in the class of the first argument, but that seems a bit arbitrary, since both arguments have equal importance.
or a "f(int, bool, real) -> string" function?
The answer is not always clear. It takes experience to make good decisions. Code things, and if it doesn't look or feel right, try to code it again in another way, giving you material to compare with each other.
In time, you'll improve your vision of what works when and you'll make fewer errors here (hopefully :) ).
Both procedural and oo programming have strong points and weak points, without much overlap in my experience. Throwing away either blindly in favor of the other is doing yourself a huge dis-favor.
The tricky part however is to know when to use procedural programming, and when to use oo programming.
I think we don't even know or agree on how to write procedural code or oo code on its own, let alone we understand when to use procedural and when to use oo, and how to combine them.
oop is based on the idea that you have data and operations on them. This seems to me the most clear-cut oo paradigm.
Procedural programming is based on the idea that you have data, and you have functions (input and output). Functions take some data, and produce other data,
like y = f(x) in math.
These are both extreme cases, in oo, a function 'belongs' to one data. In procedural programming, functions exist on their own.
A good example is "main". You get a "do-it" call from the OS, but there is no object attached to that call.
The trouble arises when you have 'something-in-between' cases. A nice example is equality, where does equals(a, b) belong? oo languages firmly put it in the class of the first argument, but that seems a bit arbitrary, since both arguments have equal importance.
or a "f(int, bool, real) -> string" function?
The answer is not always clear. It takes experience to make good decisions. Code things, and if it doesn't look or feel right, try to code it again in another way, giving you material to compare with each other.
In time, you'll improve your vision of what works when and you'll make fewer errors here (hopefully :) ).
Your examples aren't really procedural vs OOP. Also your first example does dynamic memory allocation while your second doesn't and honestly looks weird to me. It's hard to say something sensible about the pros and cons with short snippets of code. Here's Brian Will's channel where he rewrites reasonably sized programs from OOP to a procedural style. I'm not aware of anyone who does the opposite so it's one sided, but you can find some takeaways in there.
I'm actually running an experiment myself where I take on a more C style approach to programming and I have to say I'm very much liking it so far. I made a journal entry about it a while ago. One of the biggest advantages that I've personally noticed is that procedural code is much easier to read, but I'll get back on that once I'm further ahead in my journey.
I'm constantly moving away from OOP over the years. The idea of inheritance never made much sense to me - it just complicates things and forces you to make decissions about software design. To me that's just blah blah and i prefer to spend this time on solving real problems.
So i ended up using C with classes style, but i moved away from that too, mainly because of this:
Class member functions hide some of the data they use because you don't know what member variables they access without looking at the implementation.
This way it's hard to see data complexity, which is important to optimizing / refactoring.
Often i ended up making member functions static, forcing me to add all data to the function parameters - just to see how many there are (ALWAYS more than you would expect).
Next i realized that static member functions can be used from anywhere, how practical.
So why did i still using classes?
My answer was simply: To group related functions together by 'topic', so i cand find them somehow.
But there is something better to do this: Namespaces.
With namespaces it's possible to group stuff in hirarchies without any restrictions or problems known from inheritance.
Today i create a classes very rarely, using them only as an interface to a large system which is implemented mostly procedural under the hood.
But i still use a lot of small structs with member functions for trivial functionality like indexing arrays or un/packing.
I am the same as JoeJ, I now prefer procedural and also functional (Not the same thing), I feel I get more reuse and easier composition
In the end it does not matter if you use OO, procedural or functional, a good design is a good design. So use whatever works for you, or better still use the one that best fits your needs :)
I'm constantly moving away from OOP over the years. The idea of inheritance never made much sense to me
Inheritance is not an OO concept. Inheritance is a facet of type systems.
The original OO languages did not have these type systems. Modern OO languages also have wildly different type systems. Don't confuse OO with all of the other specifics of C++ or Java.
OO solves a particular set of problems exceedingly well. It does not solve all problems very well. A non-trivial software stack likely has very good uses of OO-style interface, functional computation, procedural blocks of code, declarative specification, and so on.
OO is about interfaces and communication. That's it. It's about composition. All of the other facts of good OO - like encapsulation - are just there to better facilitate composition. When you're working on "pluggable" code, you're going to be hard-pressed to find a better paradigm than OO (though you can find an awful lot of variants of OO that all address the issue, of course). You can use OO interfaces beneath declarative specifications, you can implement OO interfaces with functional computations, and you can both consume and provide OO interfaces via procedural programming.
It's just a tool. Anyone who says (not that you are) that they avoid OO is every last bit as misguided as those who say that they only use OO.
Answering the OP: the advantages of procedural programming are that it's clearer and simpler when you're not dealing with composition. Building objects and interfaces and encapsulating everything when you instead could just write a 10 line function is silly. Use OO when you need it. Don't use it when you don't. Like any other tool. Trying to write highly composable procedural interfaces - while possible - is difficult and the results are often less than stellar.
An example is the Linux kernel. It's written in C, not an "OO language," and is mostly procedural and data-oriented. However, along things like driver interfaces, the kernel developers have devised an OO mechanism, because drivers need to be composable and replaceable; you can load and unload USB drivers, interface a USB controller with a USB device, implement a USB controller over a CPU bus driver, and so on. If you just have a collection of functions and computation-specific structures, that kind of modularity would be difficult to impossible.
For quite some time I've been wondering if procedural programming has any advantages over OOP or if it's just personal preference. For example:
Your example isn't actually procedural programming at all. Instead it's an attempt to mimic the look of a C++ class in C-style code, but without any of the benefits that actually using a C++ class brings. This isn't actually something you would do; procedural programming is a very different paradigm.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
