OO vs Procedural?

[Paul Hoffman]

I am new to object-oriented development. I understand the differences between OO and Procedural programming. Are there still procedural languages being used? If so, why?

[Ernest Friedman-Hill]

Hi Paul,

Welcome to JavaRanch!

Yes. "C" is one big example. C's main advantage is that's it's very "close to the machine". Experienced C programmers know exactly what machine instructions each line of C code will generate. This makes it very good for programming operating systems (the Linux kernel, for example, is written in C, as are all the other UNIX kernels I'm aware of), device drivers, and small or slow devices (all kinds of embedded systems).

There are also many non-object-oriented scripting languages in use, or scripting languages that have "object extensions" that often go unused: Perl, PHP, and various UNIX shells. All of these let you quickly and efficiently write small programs to get some job done with a minimum of fuss.

[Paul Hoffman]

Thanks, Ernest! You're explanation of where a procedural language such as C still warrants a lot of use was excellent. Now...C++...I'm assuming that's a derivitive of C? But it's object-oriented, correct?

[Mark Spritzler]

Also, there are still a lot of VB 6.0 shops out there. Now VB 6.0 is Object Based, but not Object Oriented, and still considered procedural.

Mark

[Ernest Friedman-Hill]

Originally posted by Paul Hoffman:
Now...C++...I'm assuming that's a derivitive of C? But it's object-oriented, correct?

Yes, it's C with many extensions. Originally it was called "C with Classes", and it was just intended as an "object-oriented C". These days, it has a lot more than just objects added, and it's referred to as a "multi-paradigm language." You can write procedural code, or O-O code, or "generic" code, or "metaprogramming" code... it's very flexible.

Java's syntax is, in many ways, a simplified C++. Java's concepts, on the other hand, come more from languages like Smalltalk and the Common Lisp Object System (CLOS).

[Jaime M. Tovar]

There are a lot of procedural languages in use, and i think they are still in use because there are tasks that are easier to approach when you use a procedural languaje. In fact I don�t think oo programming is better than procedural programming, I think of them as different tools for different task.

[Paul Hoffman]

Jim, thanks for the reply. You talk about tasks that are easier to approach in procedural. Could you give me a brief example?

[Ilja Preuss]

Originally posted by Jim Tovar:
There are a lot of procedural languages in use, and i think they are still in use because there are tasks that are easier to approach when you use a procedural languaje.

Mhh, but you can easily write procedural code in an OO language. In fact, an OO language is a procedural language plus additional options for managing code dependencies (most importantly polymorphism), isn't it?

[Jesus Angeles]

COBOL MVS is still used in mainframes.

[Gerardo Tasistro]

Ilja in Java you can't strictly write procedural code. No method can exist outside a class {} declaration. Sure methods look like functions, but that does make it procedural.

[Henry Wong]

Being a consultant, it is amazing how much "procedural" Java programs I have seen in my lifetime...

Just because a language is object oriented, doesn't mean the program that uses it, is. Any language, including Java, can be abused.

Henry

[Stan James]

There is probably as much COBOL in the world as anything else and plenty of procedural scripting code as well. Those are far from dead languages. Good procedural designs value data hiding, low coupling, high cohesion and many of the same things that make good OO designs.

[Ilja Preuss]

Originally posted by Gerardo Tasistro:
Ilja in Java you can't strictly write procedural code. No method can exist outside a class {} declaration. Sure methods look like functions, but that does make it procedural.

Of course you can - use only public static methods and fields, for example. Then classes are not more than namespaces - you have namespaces in other procedural languages, too.

[Ilja Preuss]

Originally posted by Stan James:
Good procedural designs value data hiding, low coupling, high cohesion and many of the same things that make good OO designs.

Well yes - that's of course how OO came into being: by developers valueing code management tools and therefore adding some additional tools to procedural languages.

[Gerardo Tasistro]

Originally posted by Ilja Preuss:


Of course you can - use only public static methods and fields, for example. Then classes are not more than namespaces - you have namespaces in other procedural languages, too.

They're still classes and surely more than just namespaces.

[Ernest Friedman-Hill]

Originally posted by Gerardo Tasistro:

They're still classes and surely more than just namespaces.

And if I crack an egg into a bowl, pour a cup of flour on it, and a cup of sugar, and some baking powder, and some milk, and put the bowl in the microwave for 20 minutes on "HI", that's still a cake, right?

[Stan James]

Stan: Good procedural designs value data hiding, low coupling, high cohesion and many of the same things that make good OO designs.

Ilja: Well yes - that's of course how OO came into being: by developers valueing code management tools and therefore adding some additional tools to procedural languages.

Sorry, I got rushed away before getting to why I even mentioned that ... To the original post, I don't think we are compelled to start using OO languages and stop using procedural ones. It is quite possible to write perfectly good software in procedural languages. I personally find OO languages improve my chances of achieving my own goals in software and I think a lot of others do, too. But I have no problem dropping into to COBOL or REXX or whatever best fits the task at hand. I just downloaded Turbo Pascal 1.1 from the Borland software museum and found I have forgotten the WordStar editor commands, so I can't go that far back without some practice.

Even more to the original post "why" question, when do I choose non OO languages? Mostly when I have to right now. My text editor uses REXX for a macro language, we are permitted only COBOL on our mainframes. I use REXX instead of BATCH because it is so easy to invoke OS commands and other programs.
[ November 05, 2005: Message edited by: Stan James ]

[Jaime M. Tovar]

An example of procedural language like said before is any script, like a grep, you have a grep function written in your os, i will not create an object to call a grep funcion, i will run a script that calls the grep function.

Other example to me will be a stored procedure in a relational database.

[Gerardo Tasistro]

Originally posted by Ernest Friedman-Hill:


And if I crack an egg into a bowl, pour a cup of flour on it, and a cup of sugar, and some baking powder, and some milk, and put the bowl in the microwave for 20 minutes on "HI", that's still a cake, right?

Sorry I don't get your point.

[Henry Wong]

Originally posted by Gerardo Tasistro:

Sorry I don't get your point.

Ernest's point is that there is a huge difference in following the letter versus the spirit. While you can argue that it is object oriented because it is using an object orient language, you are not get any of the advantages of using an object orient language.

I generally don't like food analogies, because I either get hungery or disgusted. I don't know which case, that microwaving a cake, falls into...

Henry

[Ilja Preuss]

Originally posted by Gerardo Tasistro:


They're still classes and surely more than just namespaces.

Are they? In which way are they more?

[Gerardo Tasistro]

Originally posted by Ilja Preuss:


Are they? In which way are they more?

Well first of all you can't do away with that "namespace" tag. You can create as many static methods as you want and make them look like "procedures and functions", but they'll always be parts of a class.

Your "nametag" will automatically have a lot of "procedures" that you never defined, wrote or declared.

Your "nametag" comes with a mirror you can never do without. Called reflection.

You can make your properties look as "local variables" all you want, but they'll be accessible by this.%property name%

So you can make it look like a procedural language, but it is forever an OO and you can't escape OO rules with it.

[Ernest Friedman-Hill]

Yes, you're absolutely right. Every program written in Java is by definition 100% object-oriented. How could I have missed this!

So if I go dig up some of the FORTRAN code I wrote in college, and translate it line-for-line into a set of static methods in a single Java class, and make all the global variables into static members of that class, then it will magically, by the grace of Jim Gosling, become object-oriented code. I better go get started!

[Tony Morris]

How many times do we have to derive the conclusion that OO is ill-defined, and until that axiom is indeed defined (formally, not loosely as has been done in the past), that the notion of whether not Language X is OO is too ill-defined?

I don't think it's that tricky to determine.
The sky is blue (inference) because I observe it to be blue (axiom).
Java is/isn't OO (inference) because I observe it to be OO (axiom).

[Gerardo Tasistro]

Originally posted by Ernest Friedman-Hill:

So if I go dig up some of the FORTRAN code I wrote in college, and translate it line-for-line into a set of static methods in a single Java class, and make all the global variables into static members of that class, then it will magically, by the grace of Jim Gosling, become object-oriented code. I better go get started!

Call me up when you get to the point in which you have to compare two strings.

[Jeff Albertson]

Originally posted by Gerardo Tasistro:

Call me up when you get to the point in which you have to compare two strings.

It's about time javaranch added this to the stable of standard graemlins:

[Joel McNary]

Originally posted by Gerardo Tasistro:

Call me up when you get to the point in which you have to compare two strings.

Comparing two strings is procedual. Granted, in Java the mechanism used to acheive this is through objects; but the thought process that indicates that two strings must be compared is procedural.

At their very basics, all programming languages must have procedural code. You can call them functions or methods or subroutines or whatever. But if you don't have procedures, then the computer can't do anything. If you're program is built from these blocks, then it doesn't matter what language it is in, it is procedual.

10 GOSUB 100
20 GOTO 10
100 PRINT "HELLO, WORLD!"
110 RETURN

is no different conceptually than

public class HelloWorldPrinter{
    public static void main(String[] argv){
        while(true){
            HelloWorldPrinter.printHelloWorld();
        }
    }
    public static void printHelloWorld(){
        System.out.println("HELLO, WORLD!");
        return;
    }
}

What Object-Oriented programming introduces is the ability to introduce flexibility to these procedures. Object-Oriented Programming is all about Polymorphism, Encapsulation, and Inheritance. Without these things, you have procedural code written in an Object-Oriented language.

public interface WordPrinter{
    public printMessage();
}
 
public abstract class BasicWordPrinter implements WordPrinter{
    protected String message;
 
    public String getMessage(){
        return message;
    }
 
    public void setMessage(String aMessage){
        this.message = aMessage;
        return;
    }   
 
    protected void printMessage(){
       System.out.println(this.getMessage());
    }
}
 
public class HelloWorldPrinter extends BasicWordPrinter{
    public HelloWorldPrinter(){
        this.setMessage("HELLO, WORLD!");
    }
}
 
public class GoodByeWorldPrinter extends BasicWordPrinter{
    public GoodByeWorldPrinter(){
        this.setMessage("GOODBYE, WORLD!");
    }
}
 
public class WordPrinterFactory{
    private static WordPrinterFactory instance = new WordPrinterFactory();
 
    private WordPrinterFactory(){
        super();
    }
    
    public static WordPrinterFactory getInstance(){
        return instance;
    }
 
    public WordPrinter getPrinter(){
       //Some logic here.  We'll go on System time
       long time = System.currentTimeMillis()/1000;
       if(time%2 == 0){
           return new HelloWorldPrinter();
       }
       else{
           return new GoodByeWorldPrinter();
       }
    }
}
 
public class Main(){
     public static void main(String[] argv){
          while(true){
             WordPrinterFactory.getInstance().getPrinter().printMessage();
          }
     }
}

Here's an Object-Oriented solution. Note that there's still procedural parts: The main method, the logic that determines which WordPrinter to get, and the printMessage method in the BasicWordPrinter.

Hope that this clears up the confusion.
[ November 07, 2005: Message edited by: Joel McNary ]

[Ilja Preuss]

Originally posted by Gerardo Tasistro:
Well first of all you can't do away with that "namespace" tag. You can create as many static methods as you want and make them look like "procedures and functions", but they'll always be parts of a class.

But there are namespaces in many procedural languages, so this can hardly be something that makes a program OO.

Your "nametag" will automatically have a lot of "procedures" that you never defined, wrote or declared.

I guess you mean the methods inherited from java.lang.Object. That's true, but it's easy to ignore those.

java.lang.Math, for example, is a fully procedural class to me - there is nothing OO about its code at all.

Your "nametag" comes with a mirror you can never do without. Called reflection.

I never thought of reflection as an OO property. I still don't do.

You can make your properties look as "local variables" all you want, but they'll be accessible by this.%property name%

You don't have to use properties at all.

So you can make it look like a procedural language, but it is forever an OO and you can't escape OO rules with it.

You must be using a different definition for when code "is OO" than I do. And I easily can write code that doesn't conform to any of the OO principles and therefore doesn't make use the advantages an OO language gives.

[Gerardo Tasistro]

public class HelloWorldPrinter{
    public static void main(String[] argv){
        while(true){
            HelloWorldPrinter.printHelloWorld();
        }
    }
    public static void printHelloWorld(){
        System.out.println("HELLO, WORLD!");
        return;
    }
}

Just show me a way to do your code sample without the word class anywhere. In such a way I can't change your System.out.println line for this:

System.out.println("HELLO WORLD "+HelloWorld.class.getName());

and I'll buy the procedural Java line. If this were C++ or php I'd agree with you, but Java just doesn't allow you to be without encapsulation and inheretance. You can call encapsulation "namespace", but it is still encapsulation.

[Ernest Friedman-Hill]

Originally posted by Gerardo Tasistro:
You can call encapsulation "namespace", but it is still encapsulation.

How about if I make all my variables public? Do you still call it encapsulation?

[Joel McNary]

I think that the fundamental problem here is different definitions of what Object-Oriented is. How do you define object-oriented? Here's my definition:

An Object-Oriented program is a program that takes advantage of polymorphism, inheritance, and encapsulation. An Object Oriented Language is a language that provides the mechanisms for polymorphism, inheritance, and encapsulation.

The mechanics of Java is object-based. However, just because you use objects does not mean that you orient your programming paradigm around them.

I could create a language that defines classes as structures with methods. This would provide basic encapsulation. In fact, in my language you cannot define methods outside of classes. My language also allows for Reflection. But my language does not allow for inheritance and, subsequently, polymorphism. Thus, you can't do Object-oriented things with it. You could use my language to do the procedural version of the HelloWorld program, but not the Object-Oriented one.

The point is that, while Java encourages Object-Oriented programming in its syntax (not allowing methods outside of classes), whether your program (not the language) is object-oriented depends on how you use the language.

[Gerardo Tasistro]

Originally posted by Ernest Friedman-Hill:


How about if I make all my variables public? Do you still call it encapsulation?

Of course I would. If you read the link regarding encapsulation you'll see it says "Encapsulation is the ability of an object to place a boundary around its properties (ie. data) and methods (ie. operations)." The making of one variable public doesn't take encapsulation away. The simple proof is you can still define others as private (as close as one line below).

[Joel McNary]

Originally posted by Gerardo Tasistro:

The simple proof is you can still define others as private (as close as one line below).

Ah -- but then they're not all coderanch, now are they? Ernest stipulated that all of his variables were coderanch.

The point that I think we're all trying to make is that it's not what you can do with a language, it's what you choose to do. The class still has the ability to place boundaries, but you have chosen to ignore that capability. The language inherantly discourages it, but you can choose to ignore all of the nifty OO features Java provides and write a program in a procedural manner.
[ November 07, 2005: Message edited by: Joel McNary ]

[Tony Morris]

Since, as predicted, everyone is throwing around *their* definition of OO, I thoguht I'd pop my two cents worth in. Encapsulation is the single most widely misunderstood concept in the entirety of software engineering ever. I find nothing else to be so misunderstood. I believe that the concept itself is worthy of a book, or even a series of books to fully provide a justfied meaning. Without writing the aforementioned book, I will pose a question or two as others have.

When you write a contract (interface) that for example, returns an array (or a java.util.List), and you intend for clients of that method to "iterate" that structure, why is that client also able to do such things as:
- randomly access elements of that structure
- modify that structure through any one of its contractual operations that are exposed
- obtain the length of the structure
- <need I go on?>
All you (the client) wanted to do is iterate, and yet here you have all of this "excessive contract" exposed to you unnecessarily. "Excessive contract" is akin to "Excessive requirement". You (the API) have exceeded your requirement (to your client) to provide a way to iterate some structure. "Exceeding requirement" is a form of "violating requirement". So I pose the question, have you ever been in a context that *requires* you to expose *all* of the contract, of for example, java.util.List or an array? I'll bet not. Such a context simply does not exist (or more correctly, I can't imagine it - can you?). Therefore, returning an array or a java.util.List is itself a "violation of requirement" and "violates encapsulation" by exposing excessive contract.

Therefore, the following interface is implicitly defective (as per requirements analysis):

interface I
{
    byte[] getBytes();
}

I realise I've left out chapter 1 through to chapter 999, providing only the simpler, fundamental steps from the introduction to The End. I also just realised I'm in the beginner forum, so I better run now

[Gerardo Tasistro]

Originally posted by Joel McNary:


Ah -- but then they're not all coderanch, now are they? Ernest stipulated that all of his variables were coderanch.

Yes, he also questioned if that was encapsulation. And it is. Encapsulation doesn't go away just because you define all variables as coderanch. Just like file access control doesn't go away because you as a user have read/write/execute privileges.

Encapsulation aside you still have to deal with all the tools and utils. Those will be written in an OO manner. So you can't just printf() like C. A language you can mix OO and procedural is php as OO is loosely implemented there. PERL is also an example, but Java is not a good case.

Like you say you can "force" Java all you want, but sooner or later (and surely sooner than later) OO will prevail and your Java app will be OOed. Even the simple HelloWorld app required OO. System.out.println. You won't be able to fopen anything. And readln won't be easy to find.

Finally when you get beyond the command line you'll bump into more and more OO as you hit Swing et al. I believe that writing Java is impossible without and understanding of OO programming.

[Ken Blair]

We use COBOL extensively here. In fact, our flagship product is still a 100% COBOL application. The reason is quite simple, the first iterations of it were written 30 years ago and there's no compelling reason to rewrite 30 years of development, especially when it works so well and is used in a dozen other applications.

[Joel McNary]

I'm just going to say that just because you use objects does not mean that your program is oriented around them.

I contend that Object-Orientedness is a semantic, not syntatic, attribute. Reference the BASIC and simple Java HelloWorld apps. Semantically they are identical. Syntatically, one uses Objects and one does not.

[Scott Selikoff]

Originally posted by Ernest Friedman-Hill:


And if I crack an egg into a bowl, pour a cup of flour on it, and a cup of sugar, and some baking powder, and some milk, and put the bowl in the microwave for 20 minutes on "HI", that's still a cake, right?

Actually that words for a bread maker. Must remember to get on to inventing a cake making machine...

[Scott Selikoff]

Originally posted by Joel McNary:
I'm just going to say that just because you use objects does not mean that your program is oriented around them.

I contend that Object-Orientedness is a semantic, not syntatic, attribute. Reference the BASIC and simple Java HelloWorld apps. Semantically they are identical. Syntatically, one uses Objects and one does not.

I'm going to have to agree with Joel, ALL programming languages are conceptual whether that concept be OO or procedural, but all computers are procedural. A register on a CPU has no idea its part of an object, its just an abstraction, such as a virtual memory. The memory doesn't exist in some imaginary space even though we pretend it does, ultimately it is defined in some piece of hardware.

It's like asking a computer to store 1/3. A computer cannot store this number perfectly although it can simulate storing this number perfectly. Any attempt to use the number in a calculation will result in truncation and there's no such thing as a computer with infinite memory. The computer, can simulate 1/3 by storing extra information about this number (such as storing 1 div 3) so that during adding/subtracting the computer fills in missing data such as (1/3)*3 = 10. These extra attribute isn't really part of the number though, its just an abstraction. The number itself can never be stored properly.

[Stan James]

The guys who made Simula, the precursor to SmallTalk and all else that is OO, said the only thing they thought they did different was move data from the stack onto the heap. This allowed a unit of code to hold its own data rather than always having it passed in through arguments. Another good step is to hide the data so the code exposes only behavior. Any time you get data from one object, manipulate it and put it in another object your "procedural" alarm should sound. Everyone has to weigh their own values of OO goodness, expediency, cost effectiveness, risk aversion, etc and decide whether to refactor or ignore the alarm.