My opinion is that OO is an object orientated language, meaning instead of solving problems procedurally by writing steps of what must be done, you break the problem into the objects that are actually involved, and the methodologies that exist between those objects.

I'm sure someone more informed can give you a better answer.

:astylin today:

a language can be structured to support OO more, but it's very possible to do OO applications in things that aren't designed for it. Just requires writing a bit of framework.

Quote:Original post by Anonymous Poster

Quote:Original post by stylin
My opinion is that OO is an object orientated language

OO is more than a language.

You're right. Some might say it has nothing to do with language at all, just thinking, concepts, objects. It's a different way of looking at problems and solutions.

:very astylin:

I would suggest that what was originally described is merely good design, not necessarily good object oriented design.

In imperative programming, you still take a lot of ideas, and then abstract out general ideas to simplify the process. This usually takes the form of writing generalized functions that in turn call more specific functions. Example:

InitializeGame()Do  Quit = PlayGame()While Quit = FalseTerminateGame()

Really simple, and really abstract. InitializeGame() might look like:

InitializeGraphics()InitializeInput()InitializeSound()FileName = AskUserForSaveFile()OpenSaveFile(FileName)

And the those functions, and other functions, would contain more specific details, until you finally get down to the smallest pieces of logic and such that don't need to be broken down, abstracted, any further. This is definitely a good design practice, but it can be done using any programming methodology that I am aware of.

Now I'm far from an expert at OOP, so my description might be really bad according to some, but I'd say that OOP tries to emphasize the actions that can be performed on an object (by strongly attaching the actions to the object itself, or to its type), and deemphasize how those actions actually work. Additionally, it encourages structuring a program based on relationships between objects. "This object has an instance of that object." "This object is a type of that object." "This object interacts with that object using a public interface." Things like that.

Object oriented programming is about considering the basics of how something works, in both abstract and concrete terms, then establishing how these interact, then building and connecting each piece of the puzzle. In this way, each piece has fully encapsulated the data and methods that it needs, so that when plugged together, it works as intended.

Using C++ to compose the system also allows the use of interface classes, to that the details of implementation can be hidden from the end user. Furthermore, as we learn more about the power of C++, we can use powerful object-oriented tools such as functors and functoids, that are difficult or clumsy to write in other languages.

In Smalltalk and Objective-C, we talk about 'using objects' and sending messages. In C++ we instead talk about 'composition' and 'wiring'. Another major advantage is the ability to build re-usable code.

An analogy is the construction of a bridge. In early times, bridges were built piece by piece, slowly but surely. This is like the development of software in a procedural way. Today, it is possible to build bridges of breathtaking beauty and span distance. This is possible because, like C++ and other OOP languages, the bridge is build of precast, cabled 'objects', each object containing the material, properties and interface needed to achieve the whole.

--random

Quote:Original post by luasitdown
More,when extra 100 thing to do ,maybe you still only need do 20 abstract thing. And.... what is your opinion?

I'm not entirely clear on what you're asking, but it sounds like you want to know what the main points of OO are. It can be briefly summarized in three components, some of which were also explained by previous posters:

First, OO provides the tools to make useful abstractions about the real world. These are abstractions in the programmatic sense, not necessarily abstractions in the real-world, however. For instance, in the real world, an ellipse is an abstraction of a circle (all circles are ellipses). In a OO program, a Circle might be an abstraction of a Ellipse (all Ellipses are Circles, which is not true in the real world), since an Ellipse object must necessarily contain more data than a Circle.

Second, OO allows you to describe a program in terms of the entities it involves and the relationships between them. This is a key distinction from other programming paradigms, which describe a program in terms of the messages they pass, or in terms of the functions that can be operated on, and so on.

Finally, OO encourages productive programming. This is a subjective statement rather than an objective one, but I've found it to be true. It closely mirrors the way we already tell stories and describe events in the real world -- with actors and actions. Likewise, in OO we also have actors -- the objects involved in the program -- and the actions -- the things those objects do.