#### Archived

This topic is now archived and is closed to further replies.

# OOP

## Recommended Posts

I know what OOP is and I understand why it is used, but Im a bit confused on when you would use it. Would you only use it if you were sharing your classes with another application or does it used to protect data from your own functions as well? Or am I way off?

##### Share on other sites
Objects can work together in a single program. That's usually how they're used, in fact.

Here's the basic premise behind OOP design.

Think of a piece of electronics. You wire together a bunch of individual parts - adders, logic gates, LEDs - to create a working device. Now each of these parts is made up of smaller parts (the adder contains a whole bunch of transistors, for example), but you don't worry about them. If you know you have an adder that works, you can use it and expect it to do what it's told. If you were to draw a diagram or schematic of your circuit, drawing the indiviodual parts of the adder would just be confusing; you just draw a black box. OO works like that. You put together a bunch of black boxes (which are themselves built from other black boxes) to get a program.

When you design a program with OO in mind, you think of how the problem can logically break down into objects. Then you design each object so that it is a self-sufficient entity. Your private and protected parts aren't really protecting the data from something, like a vault or a safe would; they're really just hiding them from the rest of the code. It also prevents you from accidentally accessing that data from outside objects. having objects access each other's data is something you only want to do only if you really have to, and usually it can and should be avoided. Remember that the whole point of using objects is to seperate code into black boxes whose workings are invisible to the rest of the code.

I built a simple program that had many similar but slightly different little critters floating around an environment. I made an abstract base class to define drawing the critters in general, moving, etc, and then derived specific classes that told what color to draw in and how to decide where to move when. These critters were derived from an even more abstract "Thing" class from which I derived a "Food" class, so my critters would have objects to eat. Then, since all Things had a Draw function, I just made an array of Things, and then iterated through it calling Draw on each member each frame. I know this isn't the most efficient thing in the world, but when you have a total of maybe 30 Things, each of which is composed of less than half a dozen triangles, it's not a problem!

[edited by - TerranFury on March 4, 2003 12:07:28 AM]

##### Share on other sites
Let me think a good analogy...

Ok. Think about an automatized car-factory. There is a robot for every different task related to make a car. Every robot is controled by a computer that has the data and knows the methods required for such a task.

The robot that weld the chassis doesn't (and shouldn't) know how to paint the car, because there is already a robot for that. In the same way, the robot that paints the car, doesn't know how to weld it, but it must know when the robot that weld has finished so it can start doing his job.

Specific data and methods on welding are private to the welding-robot, the state (working, stand by) of the robot is public so the other robot knows when to start.

Usually, the weld-computer, will send a message to the painting-computer telling that the welding process has finished.

OOP (among other things) is a methodology to structure your program in differents objects that have specific (private) data and knows how to do their job and (maybe) can interact with other objets to do a complex task.

Like in the car-factory, you can scale your car bulding process by adding new robots and modifiying the ones you had in such a way that they can communicate with the old version robots and the new ones.

.......

There are hudried millon of things I could say to give you a hint about why I find OOP very usefull to work with. I think encapsulation, scalability and structure are KEY when you are all alone and you want to save time. OOP will give you that if you know how to write a good design.

Buy a good book, and give it a try. Good luck.

[edited by - xaxa on March 5, 2003 4:44:28 AM]

##### Share on other sites
quote:
Original post by TerranFury
OO works like that. You put together a bunch of black boxes (which are themselves built from other black boxes) to get a program.

I hope I won''t get banned for my activities here, but you all are driving me crazy.

While object in OOP really can be viewed as a black box, there is something wrong with other component essential for Black Box paradigm - the interfaces between those boxes. Unfortunately at some complexity limit you start passing around object as arguments and return values, resulting in a monolithic structure, to which this paradigm cannot be applied.

More details here (Chapters "Black Box Bye Bye?", "Coupling Needed for Reuse?", "Types of ''Wires''", and "A Closer Look at Fat Wires ").

##### Share on other sites
I''m finding the article posted by Advanced Bug to be somewhat lacking in understanding. For example:
quote:

For example, take a typical Java statement:

data = new DataInputStream(new BufferedInputStream(astream));

You are feeding behavior (classes) in as parameters here. "BufferedInputStream" and "astream" are tied to OO classes with behavior attached to them. You are passing the equivalent of a black box into another black box here.

I find this line of code, and the objects, to be a very elegant solution to file IO. DataInputStream is just a wrapper to the InputStream type that provides useful functions such as endian independant read/write functions. DataInputStream has no knowledge of what BufferedInputStream is other than that it''s an implementation of InputStream. The elegant aspect of this method is that we can create a new InputStream that reads from a serial link or from a memory buffer or from wherever and we won''t need to re-write the functionality of DataInputStream - so we only need to write 10 functions for our new InputStream derived object as opposed to the 23 functions that DataInputStream provide. We''ve saved ourselves 13 functions (and therefore, 13 places to create bugs) and still have the same functionality.

Also, in the tax example, the author states:
quote:

If personClass is changed such that "income" is removed and replaced with "netIncome" (because gross can be calculated rather than explicitly stored), then module taxPerson_A will not work without modification. However, taxPerson_B will continue to work without internal modification. (Perhaps some of the calls to taxPersion_B may need to be altered, but no changes are needed to the module itself.)

which to me is missing the whole point of OO. Yes, you can store "netIncome" but provided that the personClass provides a "getIncome" function then nothing is broken. The author is suggesting that changing every instance of a call to the function is better / easier, which is not always the case.

There''s nothing in OOP that can''t be done in non-OOP languages (consider that they all end up as machine code). OOP just provides very useful syntax to help with OOD. And OOD can be implemented in OOP or non OOP languages. You probably use OOD without knowing it: CameraGetPosition (struct Camera *the_camera) for example. Renderware for example is very OOD but is entirely written in C.

Once you ''get'' OOP you''ll wonder how you ever lived without it.

Skizz

P.S. I''m trying to write that text editor in Java, mainly for fun, but I''m having to learn Swing so it''s taking a while, since I have a full time job (I''m using an API reference and some samples from the Sun website).

##### Share on other sites
If you want to grab a book on Object oriented design, you may want to look at "Applying UML and Patterns" by Graig Larman. It talks about many attributes of object oriented design and analysis. As you read through the book, the author designs a next generation point of sale system, so the reader can understand how to apply this information to the real world. This is the textbook we are using in our Object Oriented Analysis and Design course.

##### Share on other sites
That guy''s code examples do suck, but the main point is that OOP ends up with the monolithic design (and it cannot be demostrated by small code examples), while it was supposed to do the contrary.

##### Share on other sites

Advanced bug since you only see disadvantages to OO then stick to what you where doing before. If some one else chooses to move on to OO let them do so... If some one wants to keep coding in assembler, let them do so... Who f*cken cares!

##### Share on other sites
quote:
I hope I won''t get banned for my activities here, but you all are driving me crazy.

If you mean questioning OO, then there''s nothing wrong with your activities. It''s healthy. The source of my own objections to your lines of reasoning is that I get the impression you don''t understand the very thing you are arguing against. I''ve made arguments against OO myself, but I feel yours are misplaced. You keep setting up strawman arguments where you claim that someone has said "OOP is a superior technique" and go on to make arguments against that position, when nobody in the discussion has actually made that claim. I''ve made attacks on various interpretations of OO myself in the past, so I certainly share concerns over it, but I think you need to understand it better first.
quote:

More details here (Chapters "Black Box Bye Bye?", "Coupling Needed for Reuse?", "Types of ''Wires''", and "A Closer Look at Fat Wires ").

You should be very careful of supporting your case with material from well-known Usenet trolls. Bryce Jacobs seems to have an axe to grind, so he is not entirely rational.

##### Share on other sites
quote:
Original post by SabreMan
You should be very careful of supporting your case with material from well-known Usenet trolls. Bryce Jacobs seems to have an axe to grind, so he is not entirely rational.

I don''t know anything about other his activities, but, in my opinion, the chapters I quoted (about the "fat wires") do make sense (except for code examples). If you are interacting with some object by passing to it Renderers, Listeners, Adapters, Managers and Layouts, each having references to yet another objects, then it hardly can be viewed as a black box (bacause the interfaces are just as complex as the object itself). Also, what convinces me that he can be right, is my own experience, because my attempts to write OO programs suffered from total monolithism, there were no Black Boxes, only one giant monstrosity, without any chance to isolate individual components.

##### Share on other sites
quote:
If you are interacting with some object by passing to it Renderers, Listeners, Adapters, Managers and Layouts, each having references to yet another objects, then it hardly can be viewed as a black box

Yes, but the idea of black boxes as completely stand-alone entities, with no coupling whatsoever with the external world, is a myth. You cannot achieve such a thing with *any* approach to development - it is *not* a failure of OO that you cannot do this. We don't need you to set up straw man arguments for you to "debunk".
quote:

Also, what convinces me that he can be right, is my own experience, because my attempts to write OO programs suffered from total monolithism, there were no Black Boxes, only one giant monstrosity, without any chance to isolate individual components.

Can it be that you and Bryce Jacobs are equally incompetent?

[edited by - SabreMan on March 6, 2003 9:41:08 AM]

##### Share on other sites
For one to do proper OO design you have to know your system architecture inside out.

Two you also have to know what OO has to offer.

Then you should be able to apply OO design concepts and patterns together by knowing the advantages and disadavnatges of your system architecture and create a nice elegant non monolithic OO application.

For instance, you want to write a 3d renderer...
You have to know exceptionaly well either lets say D3D or OGL and your OS API.

1- When you say Simon Says... The API must execute...
2- You have to know how the graphics API interacts with your OS.
3- You have to know how your OS API works
etc...

Lets say you know your graphics and other APIS out by heart. If you don''t know OO design well, your application will certainly work, but your design might not be that elegant since you might have applied the wrong concepts/patterns and you end up with abig monolithic application.

Same goes if you know OO concepts inside out, but dont know your graphics API well. You might end up applying the wrong concepts and patterns, since you assumed that the API was suposed to work in a certain way, when in reality it didn''t.

Same goes for non OO concepts, if you dont know your language well then you will end up with spaghetti non the less and if you don''t know your API well you will end up designing an application bassed on assuptions, with a result of spaghetti code again...

Even Strousup said somthing about C++, something in the lines of... C makes it easy to shoot yourself in the foot. C++ makes it harder to shoot your self in the foot, but when you do, you blow your whole leg off...
Some one has this in his signature...

To get the tittle of chief architect or engineer, you need at least 8-10 years in your domain, to be able to get things right.

##### Share on other sites
quote:
While object in OOP really can be viewed as a black box, there is something wrong with other component essential for Black Box paradigm - the interfaces between those boxes. Unfortunately at some complexity limit you start passing around object as arguments and return values, resulting in a monolithic structure, to which this paradigm cannot be applied.

This idea doesn''t go along with my understanding of OO, whether that means anything or not.

OO''s uniqueness is not about reducing coupling. A modular approach to programming where your component design ideas are encapsulated reduces coupling. OO is a modular approach with encapsulation in mind, but isn''t the procedural paradigm modular as well?

##### Share on other sites
quote:
Original post by SabreMan
Yes, but the idea of black boxes as completely stand-alone entities, with no coupling whatsoever with the external world, is a myth.

But that article is not about OO resulting in coupling, and some other technique not resulting in coupling. The author builds the scale of different interfaces in order of inreasing complexity (and as a result, the degree of coupling), and points out that OO approach lays in one extreme end of the scale, which might mean that it's not the best solution for typical programming problems. Also the author doesn't deny that OO approach can be the right thing in some situations: "...Passing behavior as parameters is admittedly a powerful concept. It is tough to make highly generic modules without it. However, it does create dependencies between the passer and passee that can be hard to comprehend as single interacting units...".

That is, if you need to pass a rectangle, you can do:
// everybody knows what's an int, but if you have too many of those, things go badvoid set_foo_rect(int x, int y, int width, int height);

or
// now we need to understand the rect_t structure, but I don't think it's too hardstruct rect_t{  int x;  int y;  int width;  int height;};void set_foo_rect(rect_t *rect);

or
// (of course this is not real code)// this will take forever to learn, there must be some// serious reason to do thisclass Path{public:  void setBehaviourManager(BehaviourManager behaviourManager, boolean update, boolean shared);  PathIterator getIterator(PathTraversalPolicy traversalPolicy);// ...100 other methods...};set_foo_path(ShapeFactory.createRectangle(points, new  GeometryAdapter(Shapes.INTERPOLATION_NONE |  Shapes.UNIT_PIXELS)).getIterator(Path.FORWARD_OPTIMIZED)));

[edited by - Advanced Bug on March 7, 2003 4:23:57 AM]

##### Share on other sites
Advanced Bug: If you''re going to compare OOP and non-OOP then at least compare like for like to make the point. Comparing a function that takes a simple rectangle to a function that takes a path does not mean anything because the end result is different. If you want to make a fair comparison then the final section should be:
class Rectangle{    Rectange (const int x, const int y, const int w, const int h) : [initialisers]    {    }    ...other rectangle related functions...};set_foo_rect (Rectangle (x, y, w, h));

See, it''s not that different to the first two versions.

Let''s see you do the set_foo_path in non-OOP to get a real comparison.

Skizz

##### Share on other sites
quote:
Original post by Skizz
Advanced Bug: If you''re going to compare OOP and non-OOP then at least compare like for like to make the point. Comparing a function that takes a simple rectangle to a function that takes a path does not mean anything because the end result is different.

Yes, you''re right, those code examples ARE completely different (and useless, since we don''t know what "foo_rect" is). Actually I am just trying to demostrate the syntax of different approaches, as an illustration for the "scale of wires", rather than compare them in real-life conditions (I tried that, too, you know the results). Not that it''s so hard to imagine how the first and second approaches looked like in the path scenario.

##### Share on other sites
quote:
But that article is not about OO resulting in coupling, and some other technique not resulting in coupling.

Then what, if anything, are you on about? You said this:
quote:

While object in OOP really can be viewed as a black box, there is something wrong with other component essential for Black Box paradigm - the interfaces between those boxes. Unfortunately at some complexity limit you start passing around object as arguments and return values, resulting in a monolithic structure, to which this paradigm cannot be applied.

Which is exactly about coupling. You then said "more details here". If you cannot make your point with any clarity, then don''t expect people to go on a wild-goose chase trying to figure out what your point is.

##### Share on other sites
quote:
Original post by NotAnAnonymousPoster
OO''s uniqueness is not about reducing coupling. A modular approach to programming where your component design ideas are encapsulated reduces coupling. OO is a modular approach with encapsulation in mind, but isn''t the procedural paradigm modular as well?

Uniqueness is a heavy qualification to work with. one of the primary benefits of OOD is a reduction in coupling, but that doesn''t make OO unique. A modural design is a reduction in coupling over a procedural "design". An OOD is a further reduction in coupling over a modular design (ala Design Patterns).

PS Does anyone have a decent OO Payroll example or reference?

##### Share on other sites
quote:
Original post by Magmai Kai Holmlor
Uniqueness is a heavy qualification to work with.

That''s because there''s been no revolution.
quote:

one of the primary benefits of OOD is a reduction in coupling

All of a sudden, I empathise with Advanced Bug. Please explain how OOD leads to a reduction in coupling over other approaches. OO offers various ill-agreed upon approaches for modelling the "real world", and generally fails to present the all-encompassing world-view that some proponents claim. Even so, that doesn''t detract from the fact that there are various useful ideas to have come from the OO world. Having said that, I''m not aware that an OO approach significantly reduces coupling, given that dependency management is a concern of any serious development approach. But, since you made the claim, let''s ask you. When you say OOD gives a benefit of reduced coupling, what are you comparing it to? Which non-OOD approaches fell into your sphere of analysis when you concluded that OOD necessarily provides lower coupling than other approaches?
quote:

A modural design is a reduction in coupling over a procedural "design".

Please define "modular design" and "procedural design", and explain why they are (apparently) mutually exclusive. Furthermore, please explain how a modular design intrinsically has lower coupling than a procedural design. Either that, or admit to emitting hot-air.
quote:

An OOD is a further reduction in coupling over a modular design (ala Design Patterns).

##### Share on other sites
quote:
Original post by Magmai Kai Holmlor
Uniqueness is a heavy qualification to work with. one of the primary benefits of OOD is a reduction in coupling, but that doesn''t make OO unique. A modural design is a reduction in coupling over a procedural "design". An OOD is a further reduction in coupling over a modular design (ala Design Patterns).

A good OO design is a modular design. But its generally accepted that any good design should be a modular design. It is a modular design which reduces coupling, and it isn''t specific to OO.

##### Share on other sites
quote:
NotAnAnonymousPoster
A good OO design is a modular design. But its generally accepted that any good design should be a modular design. It is a modular design which reduces coupling, and it isn''t specific to OO.

Yes, certainly all OOD are modular (but not vice-versa), and certainly modular designs have less coupling than procedural "designs". However, you can achieve a further reduction in coupling by using abstract interfaces and an OOD.
The question asked was why would anyone do OOP? Well, one reason is to get a further reduction in coupling over a modular design.

Abstract interfaces provide the additional reduction in coupling in OOD over modular ones. You no longer know _exactly what type you are using, only a portion of the type - the public interface.
In a modular design, you know exactly what type you are working with. Unless you use an OOPL, and the data-hiding characteristics-thereof, to implement the modular design, you have access to the internals of modules that you ought not to touch. For example, a Win32 critical section is a modular design in which you can toy with the internal state. Also, bsd sockets are a modular design, where you have access to the internals of the socket.
ActiveX controls use an OOD, where any control can be manipulated like any other control since they all share a common interface. To use a different socket implementation you must recompile, because you are coupled to the socket module. You can switch out ActiveX controls at run-time if you are so inclined, because you are only coupled to the interface, which all controls share.

Picture this in your minds eye: With a modular design, your program is coupled to the module, two boxes with one connection line. Then add two alternatives to the first module (say Reference Software Renderer, D3D8, & OGL). We now have the program box, and three lines to each module. Now, let''s add a second program. We have two program boxes, and six lines going to the modules (one line from each program to each module). Add a third program, and we have 9 lines all criss-crossing each other.

Let''s refactor, and add an interface, IRenderer. Each program is coupled to this interface (3 lines), then each module (now a concrete class) is also coupled to this interface (3 lines).

Also, we can add a fourth module (say D3D9) without changing the program code, which adds one line from D3D9 to IRenderer. Then the programs have access to a fourth option in the graphics settings. With the pure modular appraoch, we have to add lines directly to each program (add two lines), make some changes to the selection code, and then recompile it.

The more programs and ''swappable'' modules that are involved, the more you stand to gain from the interface abstation.

The first thing that comes to mind with the modular approach, is to use dlls, and dynamically link to the one you want. Make a couple of required exports from the dll, and we can hook everything up at run-time. This is an ad-hoc OO design. You have imposed an interface requirement by using the dlls and requiring certain exports (you may have even hidden and protected the implementation details by placing them inside the dll). It''s perfectly fine to do it this way, but realize that this decoupling is what OOP is all about.

...
SabreMan, I never claimed anything of the nature you assert. I explicitly stated that OOD reduces coupling more than modular design. Design Patterns are how you do it. If you would like to dicuss it further, please make a new thread.

...
If we wanted to do something constructive, we each could take a design approach and solve the same problem (say an archetypical payroll example). Procedural/structured, modular, OO, & parametric? (I''m not familiar with functional design efforts so I''m not aware of the appropriate terminology).

Then whenever someone asks a question of this nature, we could just point the articles and let them decide on their own.

##### Share on other sites
Magmai Kai Holmlor:

OO did not give us these principles. The principles come from modular design (I''m not sure what definition of that you are using, but it isn''t the same one as me) and encapsulation. The idea is to decompose a program into independent modules where those outside the module only work with it through an interface but do not need to concern themselves with the implementation. This means that the implementation is free to change as long as the desired behaviour is consistent. OO supports these principles, forces the data hiding and makes life easier, as you say, by allowing us to create abstract data types. But the fundamental principles are not unique to OO.

##### Share on other sites
Magmai Kai Holmlor:

Sorry, I''ve just reread your post and I agree. The idea of polymorphic data types reduces coupling and I''m pretty sure it''s one that belongs to OO.

##### Share on other sites
quote:
Original post by Magmai Kai Holmlor
Abstract interfaces provide the additional reduction in coupling in OOD over modular ones.

Your claims would be correct if not for a fatal flaw in your reasoning. Abstract data types are not unique to OO.
quote:

You no longer know _exactly what type you are using, only a portion of the type - the public interface.
In a modular design, you know exactly what type you are working with. Unless you use an OOPL, and the data-hiding characteristics-thereof, to implement the modular design, you have access to the internals of modules that you ought not to touch.

Drivel. If I use Lisp for example, I can build a struct and specialise methods to work on that struct, and I can export only the methods I choose to export from a package. I can do all that without touching CLOS. You're claims are based on technology-dependent assumptions, and are not representative of the general principles in the manner you are implying. The problem with OO, like Structured Programming before it, is no two people can agree on what it is. In such a scenario, you can waffle on about whatever you like and profess it be OO. It's not productive to do so, and you cannot conclude that OO leads to any benefits over any other approach without strict defining criteria. You might like to read this article.
quote:

Picture this in your minds eye: With a modular design, your program is coupled to the module

And a module is what exactly? There's no defining criteria for what a module is so your assertion could mean anything you like. Ultimately, it's rather useless to waffle on about something if it's not clear what it means. As NotAnAnonymousPoster astutely observed, OO and modular design are not mutually exclusive. The are, in fact, complementary. In OO, a class is a valid unit of modularity.
quote:

SabreMan, I never claimed anything of the nature you assert. I explicitly stated that OOD reduces coupling more than modular design.

Huh? That's precisely what you claimed in the first place that I challenged. What is OO and what is modular design?
quote:

Design Patterns are how you do it.

Workaround recipes exist for non-OO technologies too. Ask yourself this: "why are most of GoF's patterns language-dependent?" They have little to do with the general theory of a concept such as OO.

Your claim that OO causes decreased coupling over some vague alternative is tantamount to an accusation that all informed developers who choose non-OO over OO must be incompetent. That is, if you accept dependency management is an important activity to all development approaches.

[edited by - SabreMan on March 9, 2003 10:18:59 AM]

##### Share on other sites
quote:
Original post by NotAnAnonymousPoster
Magmai Kai Holmlor:

Sorry, I''ve just reread your post and I agree. The idea of polymorphic data types reduces coupling and I''m pretty sure it''s one that belongs to OO.

It''s not. For example, the pure functional language ML is renowned for its polymorphic data types.

##### Share on other sites
This topic is now closed to further replies.

• ### Forum Statistics

• Total Topics
628394
• Total Posts
2982427

• 10
• 9
• 19
• 24
• 9