object oriented programming vs structured programming

[rehans oberoi]

can anybody explain me the
difference between object oriented and structured programmming
thanks

[Stan James]

Start at the WikiPedia. They did a nice job on Object Oriented Programming and Structured Programming.

What questions do those raise?

[Jaison Peter]

Object oriented programming means its relates objects...

In programming we use real objects and link with our objects in program


In structured programming there will not be any objects...

program will run from in a structured manner...

[Ilja Preuss]

Robert C. Martin likes to say:

Structured programming is discipline imposed upon direct transfer of
control.


Object-oriented programming is discipline imposed upon indirect
transfer of control.

The first could be roughly translated as "manage code dependencies by using function calls instead of GOTO".

The second means approximately "manage code dependencies by using jump tables (polymorphism) instead of conditionals (if-/switch-statements)".

Notice that OO is *not* an alternative to structured, but an addition.

[rehans oberoi]

structured programming give more preference to functions
and control flow. and global data can be used by any functions .
so it is hard to do debugging

and object oriented programming give more preference to data
we can made data private or public . so it helps in
debugging and maintaibility in large programs


am i right in understanding

[Ilja Preuss]

Originally posted by rehans oberoi:
structured programming give more preference to functions
and control flow. and global data can be used by any functions .
so it is hard to do debugging

Structured programming was an advancement over non-structured programming - it introduced functions with parameters and local variables. Non-structured programs (for example as written in early BASIC dialects) only had global variables and GOTOs for control flow.

and object oriented programming give more preference to data
we can made data private or public.

That's an important part of OO, but not at its core. There are non-OO languages where you can do this, too (for example for a long time Visual Basic, which was often called "Object Based"). What those languages are missing to make them OO is polymorphism.

And the main purpose of polymorphism is to allow new patterns for decoupling code. The whole notion of Dependency Injection is at the core an OO pattern, for example.

[Stan James]

All the things you learn to do good structured programming carry right over to OO - low coupling, high cohesion, expressive code, information hiding and so on. Ed Yourdon called object oriented stuff "structured structured sutff."

You can look at OO as adding only a couple new ideas - most importantly inheritance - or you can look at OO as turning the whole world backwards. The inventors of Simula thought the only thing they added to programming was putting data on the heap instead of the stack, but that opened the way for Smalltalk which does nothing the same way previous languages did.

On a good day objects can be all about behavior - what you want them to do for you - and data all but disappears.

[Ilja Preuss]

Originally posted by Stan James:
All the things you learn to do good structured programming carry right over to OO - low coupling, high cohesion, expressive code, information hiding and so on.

Yes - the "only" think OO adds are more (powerful) tools to implement those principles.

You can look at OO as adding only a couple new ideas - most importantly inheritance

I don't think inheritance is even nearly as important as polymorphism. (In Java, those are closely linked - in other languages, they are fully orthogonal concepts.)

or you can look at OO as turning the whole world backwards.

Yes - OO adds just a few additional options for managing code dependencies; but those are so powerful that they can totally change how we write our programs.

[Stan James]

I don't think inheritance is even nearly as important as polymorphism

I agree polymorphism is profoundly important, it just felt less "new" when I hit OO. I was able to call different programs by knowing their names (in a string, say) in most other languages I used and solved some of the same dependency and flexibility problems that I do with polymorphism. Call-backs and "user exits" gave some of the same feeling in other environments. So polymorphism felt pretty familiar.

Anybody recall "frame-based" programming? It wasn't object oriented, but you could define a new module (of any granularity you like) as a set of changes to an existing frame. I saw a couple magazine articles on it about the same time I started hearing about objects. I don't think it was related to the productivity suite called Frames.

[Ilja Preuss]

Originally posted by Stan James:
I agree polymorphism is profoundly important, it just felt less "new" when I hit OO. I was able to call different programs by knowing their names (in a string, say) in most other languages I used and solved some of the same dependency and flexibility problems that I do with polymorphism. Call-backs and "user exits" gave some of the same feeling in other environments. So polymorphism felt pretty familiar.

I know some people who would argue that you already were using OO techniques then, you just didn't know it...

[Robert Hill]

Originally posted by rehans oberoi:


and object oriented programming give more preference to data
we can made data private or public . so it helps in
debugging and maintaibility in large programs

I do not think that OO has truly been tested in the "large program" area. Look at programs that are >1gb ie operating systems, games, ect. They almost are all mainly written in C with some C++ thrown in here and there.

If course it depends on your definition of large programs. I do not think that OO has a large advantage in maintainability or debugging, if at all. A well written C program can follow design patterns even though it is structured programming. OO does not always make sense in a program.

[Ilja Preuss]

Originally posted by Robert Hill:
If course it depends on your definition of large programs. I do not think that OO has a large advantage in maintainability or debugging, if at all. A well written C program can follow design patterns even though it is structured programming. OO does not always make sense in a program.

OO makes *absolute* sense for large programs - in fact *especially* for large ones! OO basically gives us additional tools to manage code dependencies, and managing code dependencies becomes the more vital the bigger the code base. I'm currently working on a system that has around a million lines of Java code. When I joined the team, much of the code was very procedural, and further development was very slow. By refactoring the code, introducing OO techniques, we dramatically improved the maintainability and extensibility of the system.

BTW, operating systems were using OO techniques for a long time: device drivers, for example, being able to be plugged in by the use of jump tables are implementing polymorphism.

So, yes, you can use OO techniques without using an OO language. But it's so much work that you typically only do it for very limited amounts of code. With an OO language, it becomes the default behaviour, which radically changes the way you can manage the complexity.

[Tony Morris]

OO makes *absolute* sense for large programs

The term *absolute* here makes me cringe in ways unimaginable.
For the time being, I request that the term be removed from the statement, and replaced with something along the lines of "more sense than the available alternatives". Any objections?

[Robert Hill]

Unitl OO is proven to be of value in programs of 10+ million lines of code, I stand by my statement. And no OO does not make sense everywhere. Small embedded devices are still the domain of C(no I am not talking about cell phones), and probably will be until a legitimate C replacement comes along. Operating systems and most of the processes are still written in C and some assembly. When an OS(or something of similar complexity) gets written in a OO language that more or less enforces object use, then there will be something to talk about.

It makes me cringe everytime I read someone say that OO is always the way to go. It is not and makes me suspicious that the programmer really only has experience in one or two OO languages and no legitimate CS background. AKA self-taught 'programmer'.

[Ashutosh Limaye]

You cannot compare Object oriented with structured languages...even OO programs are structured....

Procedure oriented and Object Oriented can be compared...

[Stan James]

I'm not sure languages were ever structured. I'd probably stand by: procedural languages were used to implement structured designs. PJ Plauger has a great little set of essays (magazine columns) called Programming On Purpose that shows many ways to think of structured design - there are chapters like top down, bottom up, outside in, inside out, left to right, right to left, and so on. Structured designs can be quite rich and quite good.

As mentioned above you can do OO designs with non-OO implementation languages. IBM did an OO design for a CICS rewrite and then implemented in PLI and assembler. They did a neat job of improving the coupling/cohesion ratio and provided implementation-independent interfaces for many interesting services. I wonder if they still develop that way.

I don't think OO languages are absent from deep OS and embedded systems (if they really are) because of the merits of OO vs something else, but because they often take more memory and cycles than hand-tuned low-level code. And there is huge momentum in supporting and connecting to legacy components through existing APIs. Those may or may not be permanent conditions but I don't think they reflect on whether OO is good for large business systems.

[Ilja Preuss]

Originally posted by Stan James:
I don't think OO languages are absent from deep OS and embedded systems (if they really are) because of the merits of OO vs something else, but because they often take more memory and cycles than hand-tuned low-level code.

What is the alternative to polymorphism? If statements, switch/case statements or hand-coded jump tables. Who is going to say that those *have to* be faster or take less memory?

To me, it seems more to be a question of knowing your tools (i.e. using the right C++ compiler with the correct options, and only using polymorphism where you need it), than one about using or not using OO.

But that's just what I infer from countless discussion I observed - don't have any personal experience in that domain.

[Ilja Preuss]

Originally posted by Robert Hill:
Unitl OO is proven to be of value in programs of 10+ million lines of code, I stand by my statement.

I'm not sure what kind of prove you are waiting for, and frankly I don't know which projects are of that size, and which of it use OO or whatever other paradigm.

Anyway, I wonder what you think could reduce the value of OO for "big" programs.

And no OO does not make sense everywhere. Small embedded devices are still the domain of C(no I am not talking about cell phones), and probably will be until a legitimate C replacement comes along. Operating systems and most of the processes are still written in C and some assembly. When an OS(or something of similar complexity) gets written in a OO language that more or less enforces object use, then there will be something to talk about.

Of course where things *are* used and where things would *make sense* to be used are mostly orthogonal...

It makes me cringe everytime I read someone say that OO is always the way to go.

Just for the record, I'm not at all saying that OO is always the way to go. But *if* program size is a deciding factor at all, I'd definitely say that it has less value for *small* programs, where managing code dependencies isn't that important.

[Ilja Preuss]

Originally posted by Tony Morris:

The term *absolute* here makes me cringe in ways unimaginable.
For the time being, I request that the term be removed from the statement, and replaced with something along the lines of "more sense than the available alternatives". Any objections?

I meant "makes sense" as in "could comprehend if someone choose to use it", not as in "there can't possibly be any alternative".