Fog Creek Software
Discussion Board

Object Oriented VS Structured Oriented Programming

When you start a project what criterias
will define if you will use a classical (Structured Programing) approach to Sofware Development
or Object Oriented.

Sunday, November 9, 2003

Well, I dont get to choose much these days, but Id say that data centric applications are better off in OO while process-centric or highly interactive programs (like games) are better done in a procedural/structured language.

Eric DeBois
Sunday, November 9, 2003

Depends on the language.  With some, I use oop when I want to define my own types.  Others might push you to use it.  The interface to many decent guis are oop.  And some languages don't make it such a tradeoff with other styles.

Personally:  When I used pure java, everything seemed to be oop and stateless functions.  With python, I keep using oop faster than I expect.  (Because python uses oop to abstract both syntax and data.  And it tends to want a single "right" solution.)  With lisp, I never needed it yet; I really get to defer the choice until much later, and I don't yet write large enough lisp programs that the chance of wanting oop is significant.  In fact, today with my little database app, I just went down in data abstraction from structs to simple lists, because I have full syntax control that isn't affected by how I treat data.

There's also oop's ability to restrict others' freedom to hurt you.
It's easy to see that answers to this question are too often framed as objective, when it can really depend on what your coworkers need.

Here's an Alan Perlis epigram: "Functions delay binding; data structures induce binding. Moral: Structure data late in the programming process."

Tayssir John Gabbour
Sunday, November 9, 2003


Those are interesting links and they bring to mind something I'd like to say:

C++ has its uses, but C++ is not an object-oriented programming language.

Anyone with me on this? This argument is separate from an argument as to whether OOL are useful or better or whatever. As examples of more object oriented programming languages, I'd give as examples:

Java, because a executable object can exist in its own separate file that can be linked in at run time to other objects communicating with it and genuinely does not need to let others know about its internal representation... but it does need to let others know about what messages it accepts, which prevents it from being a full blown OOL.

Objective C, because it does not need to let other objects know what messages it accepts.

Pure Data, this is the only totally and completely object oriented programming language I know of. Programming in it FEELS like object oriented programming.

ViewLogic -- an object oriented hardware description language.

The way I see it, object oriented programs can be programmed by creating a visual schematic showing the interconnection of discrete, fully encapsulated objects. When the language supports this, it's object oriented.

X. J. Scott
Sunday, November 9, 2003

C++ _can be_ an object oriented language.  I'm no guru at it, but I don't see why code couldn't be generated from schematics.  If it's OOP purity you're after, then you restrict yourself to the subset of C++ that is pure OOP.

It can also be a procedural language, or an object-based language, or a generics language, or any mix of the above.  That was Bjarne Stroustrup's point.

[Sorry if that sounds pedantic, but I'm reading _The Design and Evolution of C++_ right now, and Bjarne is just so much more... level headed about programming than most I've read in books and on message boards.]

Justin Johnson
Sunday, November 9, 2003

X. J.:

Your position on C++ doesn't look too strong to me from here. You seem to be implying that C++ is not OO because it can be used in non-OO fashions.

I also don't follow your logic on Java: Because of linker features it's more OO than C++?

And you argue for Pure Data on feel?

Maybe I'm missing part of the definition of OO, but I always thought that the techniques could be used in any language (though casting structs in C to do it is ugly and error-prone).

How are you defining OO? I don't think I've ever had it defined to me in terms of much more than inheritance and encapsulation.

Mike Swieton
Sunday, November 9, 2003

My bad, I just read that first article ;)

Given that specific definition of C++ I could  agree with you on C++ is not naturally a OO language, though I suspect a framework to allow all of the specified features could be built.

The only question is whether or not you want to include some of those things in an OO language.

Here's a question: Why is it that the pure OO languages are vastly less popular than C/C++/Java? Ones with, apparently, broken object models. I won't say that Lisp, for example, is unused, but it is vastly less used than C++ and Java today. Thoughts?

Mike Swieton
Sunday, November 9, 2003

My guesses:

First, C++ is widely used because Stroustrup (correctly) assumed that being a follow-on language to C would lower the transition costs, so that C++ would be playing to an already large installed base.  Java, to some extent, played the same trick with C++.

Second, being unusefully dogmatic about theory is rarely a practical advantage, since theoretical correctness usually offers only long-term gains.  C++ and Java both broke with correctness where it was useful--C++ in not breaking C programs, Java in, for example, allowing primitive, non-object data types.

Justin Johnson
Sunday, November 9, 2003

I think what I said didn't quite come across as I was hoping. That's why I said, "This argument is separate from an argument as to whether OOL are useful or better or whatever."

I think you guys do agree with me that C++ is not an object oriented programming language, so I'm happy with that.

To deal with the stuff I didn't want to discuss in this thread, I use C++ quite a bit and do use certain object oriented programming idioms in it, though I don't think that it's designed to support OOP well. I also program in a OO style when appropriate in assembly and C, and I think both of those languages are fine for that. In fact, I think it's easier to maintain OO idioms in a big project in C than in C++, but that's just me. I didn't want to drag in any of this though -- I am only interested here if anyone has a similar perspective that C++ is not a object oriented programming language. Arguments about which idom or language is most productive or best I'm not interested in here -- those have been done to death and I doubt there's any new territory to be covered there.

Regarding 'feel', I mean to convey that in the sense that a hammer, as a tool, feels better for driving nails than a wrench does, even though a wrench can certainly be forced to do the work if needed . OOP in C++ is much more of a struggle to architect in a OO manner than certain other languages, in the same way that it is a struggle to architect in a OO manner in assembly. Java's a little better but pd, or any other run time system in which each object is a separate component or library. I think this is one of the things that makes the OO thing really work -- when each object is a separate component that can only be accessed through a well defined messaging protocol, then that's encapsulated. Macros and grammar systems that allow a abstract notion of encapsulation don't go far enough because they break down the abstraction. With separate components, there is no abstraction, the objects really are genuitely, physically encapsulated.

X. J. Scott
Sunday, November 9, 2003

Oh and I have no interest in arguments of purism or theory. I find that object orientation is useful from a practical standpoint, and I also find that procedural idioms are very useful from a practical standpoint. Again, these are different issues from the ones I intended to bring up. Sorry for the confusion.

X. J. Scott
Sunday, November 9, 2003

"I think you guys do agree with me that C++ is not an object oriented programming language, so I'm happy with that."

Well, no, I'm explicitly disagreeing with you.  It seems that you're saying that C++ is a poor OOP language because it doesn't restrict you to pure OOP.  What I'm saying is that you can usefully program in pure OOP in C++, and it's no more difficult than programming C++ procedurally, generically, object-based, or any combination.  Pure OOP programming in Java or another fundametally OOP language may be 'easier', but that's because they're higher level, not because of some flaw in C++.  C++ can be, at the programmer's discretion, as pure OOP as desired with no penalty (regarding other C++ programming styles).

Stroustrup thinks that's an advantage of C++; you seem to feel it's not.  Have I mischaracterized your argument?

Justin Johnson
Sunday, November 9, 2003

To put it another way, I've done pure OOP in C++, and I didn't feel like I was fighting the language, as I would if I were attempting the same thing in C.

Justin Johnson
Sunday, November 9, 2003

Yeah, I'm not really getting across what I intend to say.

I've read Stroustrop extensively, including his newest book, and the points you're making are known to me. I think you might be projecting an image of the beliefs of  object purists or theorists or such onto me. I'm not talking theory but practice and implementation. C++, in implementation, does not provide support for encapsulation, for example. Maybe we could throw out 'OO' and replace it with 'encapsulation' or something and put the schematic idea (which is another element of my idea here) to the side for the time being.

But I guess it's not really coming across what I wanted to express so sorry I'm not able to communicate it. Was more looking to see if others had noticed the same thing rather than to get into a merits of OO or merits of this and that language flamewar. Really, this isn't about language X vs Y, but more an observation of properties of some languages, or something. The observation comes from years of experience with various languages and is an issue of practice and implementation and not so much theory. But trying to describe it I guess forces the use of words, which drags in associations with various theories and confuses the issue to much. So I'll just drop it unless there's anyone with experience in the various languages, particularly the schematic oriented ones, or ones in which objects are actual discrete, encapsulated components. Probably the words I am using are not the right ones, probably they are calling to mind the wrong associations. Sorry for that.

X. J. Scott
Sunday, November 9, 2003

> But I guess it's not really coming across what I wanted
> to express so sorry I'm not able to communicate it.

IMHO I think one reason for the communication breakdown relates to your definition of what is an OO language. As stated earlier you define an OO language is:

  The way I see it, object oriented programs can be
  programmed by creating a visual schematic showing the
  interconnection of discrete, fully encapsulated objects.
  When the language supports this, it's object oriented.

While this definition might clearly define and easy to use  OO tool, it is not the generally accepted definition of an OO langauage.

For a language to be OO like it should support inheritance, encapsulation, abstraction and polymorphism and C++ definitely offers these characteristics.

For what it's worth I personally think C++ is not such a
great programming langauge but it definitely fits the
definition of an OO programming language.

Jussi (
Sunday, November 9, 2003

Yeah I know that C++ is considered by just about everyone as either a OOL or a multi-paradigm language that natively supports OO. So it's real easy to attack my assertion on these grounds, heck I can do it myself if you like. I'm approaching this from a different direction, seeing that C++ does not natively support OO. Encapsulation, for example, is not supported in C++. Yes, you can do it manually, but with the same amount of effort as in C. Java has better support for encapsulation, Objective C has very good support for encapsulation, and modular programming (I am making this word up, it's not the right one perhaps) fully supports encapsulation.

Really, when the interface and the implementation both are completely exposed and required to access an object, it simply can not be said to be encapsulated. And without encapsulation, it can't possible be considered to be object oriented.  It is possible to support object oriented architectures in all these languages, but you have to do it yourself. The apparent lack of standardization on name mangling in C++ makes it the clumsiest lanugage to do OOP in. C has more standardization in this regard, and thus objects compiled with different compilers can be mixed and matched more easily with C than C++.

I do find encapsulation to be useful from a practical standpoint and so I am thinking about it in terms of languages really supporting that.

Regarding the schematic stuff, I am not talking about class diagrams and such supported in an IDE, but schematic diagrams in which signal flow is drawn rather than typed.

Encapsulated OOP is most useful for signal processing, in my experience. For GUIs I find a combination of structured and tabel based programming to be the most useful approach.

X. J. Scott
Sunday, November 9, 2003

I think I get what you're saying, but you're overstating your case by saying that C++ "can't possibly be OOP".  You're saying that encapsulation in C++ is by syntactic convention rather than run-time and compile-time behaviour. 

If that's true, I don't see why that's a problem.  I don't see why objects have to be "really" encapsulated, the way you're suggesting.  I don't see why the flow you describe that's drawn can't be done for C++.

Justin Johnson
Sunday, November 9, 2003

Right, yes.

The benefit is that you can reuse and extend objects, both without having to have the source code, and also without having to recompile other code that uses the objects.

X. J. Scott
Sunday, November 9, 2003

If you don't think C++ supports encapsulation, you have a strange definition of encapsulation.

Mr Jack
Monday, November 10, 2003

Oh, and to answer the original question.

I would never consider using 'Structured Orientated Programming' for anything, ever. In my experience OO is just too much better for everything I have ever needed it for.

Actually that's not quite true, if I want to knock up a quick (<100 line) app to perform something very simple, I may forego OO. Hell, I'll forgo any kind of structure on something that small.

Mr Jack
Monday, November 10, 2003

"The benefit is that you can reuse and extend objects, both without having to have the source code, and also without having to recompile other code that uses the objects."

Okay, I can see those benefits somewhat (though with C++, you don't need the full source, just the header file, if I'm not mistaken).

I don't see, though, how that's much more beneficial, unless, in your mind, OOP is closer to web services and microkernels than run-of-the-mill OOP.  Under your definition, Java and Smalltalk don't even qualify as OOPLs.

Justin Johnson
Monday, November 10, 2003

Structured Programming does nothing that Object-oriented programming does. Object-oriented programming does a lot more (usually with a lot less code and thinking).

It depends on whether you want to simplify your code, or boast about the difficulties that you've overcome to keep doing structured programming, decades after it has become obsolete.

Having said that, C++, ASP, Visual Basic, PHP, Perl, Java and C# provide great support for structured programming.... ;-)

Dafydd Rees
Wednesday, November 12, 2003

If someone wants to write some structured code to add up all the odd numbers between 1 and 9 here, I'm post my object-oriented version, for comparison.

Dafydd Rees
Thursday, November 13, 2003

*  Recent Topics

*  Fog Creek Home