Jump to content
  • Advertisement


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


Tell me about OO programming

This topic is 6171 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''ve heard enough about Object Oriented programming, and heard it hearled as ''the ultimate solution'' to any and all forms of programming problems. So now, I''m curious. Anyone willing to explain some of the basics of Object Oriented Programming to me? Thanks a lot

Share this post

Link to post
Share on other sites
Guest Anonymous Poster
Here are the buzzwords:

Abstraction, Encapsulation, Inheritance, Polymorphism, Instantiation, Constructor, Destructor, Object, Class, Members, Methods, Overloading, Public, Private, Friend, Interface, Namespace, Patterns, Containers, and many many more...

Share this post

Link to post
Share on other sites
A very good explanation of OOP basics can be found here (Chapter 1 - Introduction to Objects).

However I am not sure that OOP is "the ultimate solution to any and all forms of programming problems" (or even that it is a good idea at all).

Share this post

Link to post
Share on other sites
OO is a strategy to use; it''s not just a way of coding. Just saying; "We''ll do OO; change from C to C++/java" is a total waste of time.

The point of OO is:

1) You can define small self contained objects, encapsulating data and methods togethor. Each of these objects can be developed independently, and tested seperately. This increases reliablilty, and decreases the complexity of testing individual components.

2) Heirarchies of similar objects can be created. For example, if you have a general animal class. The basic operations and data of lions, tigers, people and termites are all the same. By allowing new objects to inherit the public properties of existing objects, you get immediate effective code reuse. It also allows for techniques like polymorphism: A pointer to an animal object can hold an instance of any sub-class; lion, tiger, person or termite. Or any other class that -extends- animal.

3) Implementation becomes a step further removed. Design focuses on what, not how. The interfaces are designed, and class relationships. How classes interact with each other; "black box" specifications of each class. Only important information is what comes in, what goes out and what changed (state). How the black box is implemented? Unimportant. This frees up the design staff to actually design a proper achitecture, and (thank god) lets them throw away their structure charts.

OO can be good. It can be bad. There is an overhead in speed and memory allocation in using OO. However, it is (debatably) a superior method. It certainly has advantages in terms of code reuse, testing and maintenance, amongst other things.

There are advocates for it, and against it. Those who are against it probably have their reasons; as do those for it. Try it and see if you like it.

Good OO is a pleasure to even look at. Bad OO is a nightmare.

If you are seriously interested beyond a trivial level in it, I suggest a good book that says absolutely nothing about C++ or java in it. MANY many books cloud the waters by pretending that OO is in some mystical way directly related to programming languages that use it (seriously if you are reading a book on OO, as opposed to a book on programming in XXX, and it starts talking about a specific language, throw it away. Who ever wrote it has lost the plot. OO is not, and should not, be bound to a specific language).

I would suggest "Software Engineering: A practitioner''s Approach", Roger s. Pressman (mine is 5th ed, 2001, McGraw-Hill, NY). Even if you don''t buy the book, have a read of chapter 20, and maybe a flick through chapters 21-24).
For anyone who has an acute dislike of OO; I say this: Try using non OO techniques. Ive always found, ER diagrams, DFDs, structure charts, data dictionaries... way more work than a few solid UML diagrams.

Share this post

Link to post
Share on other sites
I too would have to be skeptical of calling OOP "the ultimate solution", but it is the next evolutionary step after modular code. And as Darwin would say: “Evolve or Die”

OOP is a method of designing and writing programs with greater generality than modular designs. Whether or not the increased generality is an asset or liability is often contested, but it is undeniable that OO code is more general than it''s modular counterpart.

There are four necessary and sufficient qualities a program must have in order to be OO program (meaning you *must* use all four in order for the program to actually be object oriented):

1) Encapsulation
Tie data to the functions that manipulate it.
This is a solid design technique carried over from modular coding. Everyone does this, even ID. This isn’t particular to OOP and does not require an OOPL (OO programming language).

2) Inheritance
Extend existing code in automated fashion by describing a relationship to existing code. The relationship must be automatically enforced.
This is particular to OO, and while I am tempted to say that it in fact requires an OOPL, I’ll just say that it would be “Scott Meyers Challenging” to actually fulfill this requirement without an OOPL. You can hack something together easily enough, but making it automatic is the hard part. In practice you define new classes in terms of old classes and the compiler makes certain you follow the rules of the old classes.

3) Polymorphism
Use the same algorithm or procedure on different types of data
This is not particular to OO, for instance functional languages have inherit support for polymorphic code. It is in fact part of every procedural language, as they all let you use operators such as + and - on different types (i.e. integral and floating point numbers). With regard to OO, you must write polymorphic code not just use it. This shows up in several different forms in different languages. Most (if not all) have virtual functions and C++, for instance, also offers templates. With C you can hack something together with void*’s, but type-safety is often a paramount priority when writing polymorphic code.

4) Data Hiding
Mark data to be protected from access by the outside world and enforce data-access rules it.
This is different than encapsulation, but sometimes they are combined into one item (if you hear/read about “The Three Pillars of OOP” they’ve combined these two).

Now, what I most certainly did not say, is that those four qualities will necessarily produce good OO programs – they just get you started.

Share this post

Link to post
Share on other sites
The biggest problem with oop is that it is a solution to a problem, but it is presented as a religion. Rather than it being presented as these features are to address these problems it is presented as a goal in itself. Arguing against oop is in many ways like arguing against using functions. The biggest differance is really just the scale. You have to really hit a scale where figuring out which function to call is a chore for oop to start to really shine. Once you hit that point I don''t see any valid debate. It is just arguing you should do it the hard way instead of the easy way. Oh yes, I prefer the 50 line case statement deciding which function to call.

Share this post

Link to post
Share on other sites

  • Advertisement

Important Information

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

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!