Anything Wrong with procedural c++?
I have been starting to attempt to wrap my mind around high level design paradigms, and practices.
It's more natural for me at the moment to write what most people would consider procedural code; using c++ features like the STL, and objects where they are convenient.
I'm pretty happy with this approach. In my mind, this style makes the logical flow of my code very strait-forward and easy to follow. I use objects where it seams more convenient. I don't bother worrying about reuse unless it's something which I am realistically going to want to reuse.
I read lots of material dogging this style hard. But, I also read some material dogging pure OOP, and dogging pure procedural.
And I often read that unless your going pure OOP, it's not OOP, and your code is pure wannabe garbage. But what's wrong with using OOP principles in your code, only where you think it will give you the benefits of OOP, and not overcomplicating the rest.
Anyways, I don't have a lot of experience or expertise; So my opinion doesn't mean a whole lot.
I guess what I'm asking is:
-Is mixing procedural and OOP for morons?
-Why is there so much pressure to use strict OOP?
It's more natural for me at the moment to write what most people would consider procedural code; using c++ features like the STL, and objects where they are convenient.
I'm pretty happy with this approach. In my mind, this style makes the logical flow of my code very strait-forward and easy to follow. I use objects where it seams more convenient. I don't bother worrying about reuse unless it's something which I am realistically going to want to reuse.
I read lots of material dogging this style hard. But, I also read some material dogging pure OOP, and dogging pure procedural.
And I often read that unless your going pure OOP, it's not OOP, and your code is pure wannabe garbage. But what's wrong with using OOP principles in your code, only where you think it will give you the benefits of OOP, and not overcomplicating the rest.
Anyways, I don't have a lot of experience or expertise; So my opinion doesn't mean a whole lot.
I guess what I'm asking is:
-Is mixing procedural and OOP for morons?
-Why is there so much pressure to use strict OOP?
Last edited on
What you're doing seems fine to me for small to medium programs. I doubt this approach scales well in large applications, but if it works for you what others say becomes pretty much irrelevant.
OOP was fashionable in the 90s, but C++ went through a couple paradigm shifts since then, which changed its role in this language from central to equal among others, and changed the way OOP concepts are mapped to the language concepts.
Note how few classes in the standard library or in boost are even designed for inheritance or exhibit any sort of dynamic polymorphism.
Note how few classes in the standard library or in boost are even designed for inheritance or exhibit any sort of dynamic polymorphism.
| Note how few classes in the standard library or in boost are even designed for inheritance or exhibit any sort of dynamic polymorphism. |
I'd like to think that's because people realized OOP isn't about creating huge inheritance trees rather than OOP being abandoned. Also I suppose that they don't want include polymorphism overhead in the standard libraries by design.
| hanst99 wrote: |
|---|
I'd like to think that's because people realized OOP isn't about creating huge inheritance trees rather than OOP being abandoned. Also I suppose that they don't want include polymorphism overhead in the standard libraries by design. |
Yeah, if you look back at the C++ books written in the 90s you will see the same pattern when they mention OOP. They cram the same inheritance and composition examples down your throat. " A car HAS A engine.....A student IS A person....a person HAS A birthday." Amazed at how many books had similar examples and then proceeded to have examples and exercises that just have you pump out applications that were bases classes with derived classes and classes with classes in them just to drive home the point. I've never really used any of that though (except for game programming in certain occasions).
I pretty much completely agree with hanst.
The only issue with procedural is that it isn't flexible. So as the needs of the program change (or the scope of the program broadens), it becomes more and more work to maintain. You end up slapping in half-hearted patches to add new features and before long you have a tangled mess.
On the plus side, writing procedural code is much faster and easier than writing OOP code.
So it works out that procedural is generally better for quick programs and/or programs with a short life, and OOP is generally better for big investment/long term projects.
I can see why people would say that... there's a sort of truth to it, but it's a very loaded way to phrase the idea. IMO the defining characteristic of OOP is encapsulation. And if your classes are not properly encapsulated, then it really isn't OOP.
But that doesn't mean you can't have (or use) encapsulated classes in an otherwise procedural program. You said yourself you use strings/vectors/etc where appropriate... so then guess what... you're taking advantage of OOP. Those classes are encapsulated.
Those classes are also great examples of why OOP is so useful. When you learn to write classes that focus on one very specific thing, and don't reach outside that one thing... you'll find that they are much easier to use, using them is much less error prone, and you'll be able to use them more often.
Depends where the pressure is coming from. If it's some dude on a message board, he probably is just opinionated and/or dumb.
If it's coming from an employer, it's probably because they need things to be OOP so their codebase can be maintainable (lots of very big, very long-life programs in the professional world... maintainability is HUGE).
The only issue with procedural is that it isn't flexible. So as the needs of the program change (or the scope of the program broadens), it becomes more and more work to maintain. You end up slapping in half-hearted patches to add new features and before long you have a tangled mess.
On the plus side, writing procedural code is much faster and easier than writing OOP code.
So it works out that procedural is generally better for quick programs and/or programs with a short life, and OOP is generally better for big investment/long term projects.
| iseeplusplus wrote: |
|---|
| And I often read that unless your going pure OOP, it's not OOP, |
I can see why people would say that... there's a sort of truth to it, but it's a very loaded way to phrase the idea. IMO the defining characteristic of OOP is encapsulation. And if your classes are not properly encapsulated, then it really isn't OOP.
But that doesn't mean you can't have (or use) encapsulated classes in an otherwise procedural program. You said yourself you use strings/vectors/etc where appropriate... so then guess what... you're taking advantage of OOP. Those classes are encapsulated.
Those classes are also great examples of why OOP is so useful. When you learn to write classes that focus on one very specific thing, and don't reach outside that one thing... you'll find that they are much easier to use, using them is much less error prone, and you'll be able to use them more often.
| iseeplusplus wrote: |
|---|
| Why is there so much pressure to use strict OOP? |
Depends where the pressure is coming from. If it's some dude on a message board, he probably is just opinionated and/or dumb.
If it's coming from an employer, it's probably because they need things to be OOP so their codebase can be maintainable (lots of very big, very long-life programs in the professional world... maintainability is HUGE).
Last edited on
Well, the problem with finding good examples is that they somehow have to find something that a novice can easily imagine, while at the same time those examples tend to be very much removed from the reality of software engineering. With dread I expect the (mandatory) OOP course at my uni next year. But what do I know, maybe it'll be good.
Topic archived. No new replies allowed.