OOP

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]

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]

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 ").

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).

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.

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.

Who cares everything has it''s advantages and disadvatantages...

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!

quote:

---

Original post by Advanced Bug
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.

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.

quote:

---

Original post by Advanced Bug
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]

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.

quote:

---

Original post by Advanced Bug
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?

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 bad
void 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 hard
struct 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 this
class 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]

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

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.

quote:

---

Original post by Advanced Bug
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.

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?

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).

---

Similar treatment please.

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.