Jump to content
  • Advertisement

Archived

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

This topic is 5580 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

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 this post


Link to post
Share on other sites
Advertisement
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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
Share on other sites
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!

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
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 this post


Link to post
Share on other sites

This topic is 5580 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Guest
This topic is now closed to further replies.

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!