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?

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]

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.