Procedural Programming (Not vs OOP)

Question

2.85/5 (3 votes)

See more:

Hi guys, I am a relatively new to programming as a whole and focus on C# as a language I would like to become efficient at and enjoy very much.

However there are some concerns that bother me and wanted to ask some views and advice on this topic. Whilst I understand the concept and advantage of object focused programming, I always find the structured programming methodology more appealing and logical.

My primary reason is;

I find the concept of OOP to hard to use in situations - whilst a Customer object makes perfect sense logically (in context), Sometimes objects do not.

For example - If I built an application that parsed HTML information for some reason or another, I would have difficulty in structuring this in an OO way.

Maybe because I am new to programming in general, logically it does not make sense sometimes, I don't know but in any situation; structured does.

Is structured programming even 'accepted' as a standard today?
Would it be wrong to program in a structured way even with an OOP focused language?

If possible have any of you guys been in a similar situation? and is there any links or advice anyone could give me in regard to this?

Thank you all!
Any advice is greatly appreciated as always.

EDITED - I had this listed a 'Structured' rather than Procedural - My Mistake.

Posted 9-Aug-13 12:58pm

SteveBaldwin21

Updated 9-Aug-13 13:22pm

v6

Add a Solution

5 solutions

Solution 4

The previous solutions are correct .. but Im going to try and walk through it practically.

There's nothing stopping you from doing this :-

C#

static void Main(string[] args)
{
    // Get A Connection To A Web Page OR Get HTML From A File

    // Get The HTML

    // Parse The HTML

    // Do Things With The HTML Parsed results

}

in your main, putting all the code you need there, and making it work - there's the hard part - debugging it, supporting it etc, could be a right nightmare !

So, maybe, you'd think 'I need to sit back from this and abstract out the functionality' ok ... the next re-write looks like :-

C#

static void Main(string[] args)
{
    // Get A Connection To A Web Page OR Get HTML From A File         (Object : HTMLConnection & Methods)

    // Create Some Kind Of HTML-Worker-Processing Object That :-
    // Gets The HTML (From a File or Web Page)                        (Method) 
    //      If Web Page May Accept HTML Connection As Parameter
    // Parses The HTML (Possibly using someone elses HTML Parser)     (Instanciate Parser And Call Method(s))
    // Does Something With The HTML Like Write It Do A File           (Method)


}

So, you are evolving from your 'strucutured model', to an 'object model'. There's nothing wrong in starting to attack a problem with what you know from a structural perspective, and successively refining it in terms of OO as you need to, and you'll find that in time, you'll start using less structured and more OO naturally

Posted 9-Aug-13 13:56pm

Garth J Lancaster

Comments

SteveBaldwin21 9-Aug-13 20:27pm

Thank you for your reply. Very informative with the practical approach.

Solution 1

Just a single note: although object oriented and structured paradigms are different, you can see OO as an extension of the structured one. OO gives you what's missing from the structured model (well, one view of what's missing). You still have all benefits of the later.
Let's take your html parser example, which is a really good example for a class: to make a parser, you need several functions and procedures, and you need some variables to pass information between these. And if you don't want to re-parse the structure all over, you need a structure to store the parsing results somehow. And might happen that you need to deal with many html files at once. In this case, you would need to duplicate all variables and take care not to confuse them. So why don't you encapsulate all the thing you need in a closed entity, hide all internal-only methods and variables, and expose only what you should deal with when you need html parsing. For a possible implementation of this concept, look here: Parsing HTML Tags in C#[^].
But you better google a little bit and read some of the many articles written about the comparison of these two paradigms.

Posted 9-Aug-13 13:24pm

Zoltán Zörgő

Solution 2

That's why you must master both. OOP is built atop procedural. Learn the fundamentals first, then add OOP as necessary.

Posted 9-Aug-13 13:26pm

PIEBALDconsult

Solution 5

This post really lacks subject. Saying "I would have difficulty..." is the statement about yourself, it does conduct any idea which we could productively discuss here.
Also, you should understand that conception is not a subject of standardization, by quite good reasons.

And finally, it has nothing to do with the fact that modeling some behavior of real life with any programming concept is inherently difficult. It cannot be used as an argument against the concept. The difficulties of Object-oriented programming is well known, but the cannot limit our possibilities compared to procedural in principle, just because one is a subset of another. Trying to claim that procedural programming is somehow better than object oriented is exactly the same as claiming that real numbers are "better" then complex numbers. In reality, it could only indicate that the person claiming such things is the one who attended study of real numbers at school, but by the time of introduction of the complex number started to miss classes and went for dating. :-)

I would suggest to close this discussion, unless you can provide a sound description of some problem which can be logically analyzed.

—SA

Posted 9-Aug-13 14:14pm

Sergey Alexandrovich Kryukov

Comments

SteveBaldwin21 9-Aug-13 20:25pm

I have had a few replies with great answers that will help me greatly. I have not stated that anyone is trying to claim a programming paradigm is superior to another, actually the opposite. I was not fully aware of the logical approach of the structured to object which I will begin to incorporate. Again naivety from a newbie showing :(.

Thank you.

Sergey Alexandrovich Kryukov 9-Aug-13 21:47pm

You are welcome.
—SA

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Dennis C. Dietrich · Accepted Answer · 2013-08-09T13:53:00

Very good question! If you are relatively new to programming I'd say you are going through pretty common phases as you learn more. It is no surprise that procedural programming[^] appeals to you since it is easy to learn and relatively easy to apply. But maybe not as easy as you might think. Well-written procedural code has a tendency of incorporating aspects of object oriented programming but without the compiler helping you. You'll find plenty of examples in Win32 and POSIX where all operations on an object (in this context it means something like a window, a file or a process) require the use of a handle or structure, often as the first argument. This argument essential serves the same purpose as the this pointer in OOP. The big difference though is that for example in Win32 instead of a Window class that deals just with windows I have a user32.dll library that deals with windows among many other things. Also, I have these "free floating" handles that I need to keep track of rather than strongly typed object references.

What I'm trying to say is, once you study large real-world systems, and eventual build them yourself, you'll find that OOP done right can make a system easier to understand and maintain than a procedural/modular solution. Of course OOP is no silver bullet either (I'm a huge fan of the-right-tool-for-the-job) but having a good understand of it is a must these days. As for writing procedural code in languages such as C# or C++, well, that's certainly something you can do. However, you wouldn't take advantage of the capabilities of those languages and you would end up with a huge disconnect between your own code base and the standard libraries. Personally, I would certainly discourage people from attempting this. While C# and C++ are multi-paradigm programming languages they arguably are OOP languages first.

That said, I would encourage you to keep expanding you knowledge of OOP. It takes a long time to master it. I regularly see people who should know better create classes called Util or Helper because they can't figure out where a particular method really belongs. It certainly took me several years to get any good at it and I would still not claim that I've mastered it. They might be a bit confusing at the moment, but start reading books about OOP, design patterns in particular (books about OOP languages usually put emphasis on the language itself), e.g. Design Patterns: Elements of Reusable Object-Oriented Software[^] or Head First Design Patterns[^].