What is OOP?
Author
I have vague ideas about what it means (or what I think it means) but if I was going to describe what OOP was to someone I dont think I would sell the idea very well.
Bjarne Stroustrup says OOP is programming using inheritance.
But what do you think or assert?
I doubt Bjarne says OOP is just programming using inheritance.
But, anyway. "OOP" has many definitions. Here is a discussion about the possible definitions (there are some opinions there, but also some information which you may find useful).
But, anyway. "OOP" has many definitions. Here is a discussion about the possible definitions (there are some opinions there, but also some information which you may find useful).
Author
I'll find a few quotes
TC++PL Chapter 12 Derived Classes
"This chapter is an exploration or the implications of this simple idea, which is the basis for what is commonly called object-oreinted programming"
There is a something in TD&E of C++ but I cant find it now, it says C with Classes didn't claim to be OOP until derived classes were added.
TC++PL Chapter 12 Derived Classes
"This chapter is an exploration or the implications of this simple idea, which is the basis for what is commonly called object-oreinted programming"
There is a something in TD&E of C++ but I cant find it now, it says C with Classes didn't claim to be OOP until derived classes were added.
That is a very vague and incomplete definition in my mind. Everyone will argue over some of the details but the majority will agree that OOP is simply another way to think about a program.
OOP is taking the program and describing it in terms of objects. What is an object? Well an object is a user-defined data type that has behavior and attributes. For example, if you need to write a program that acts like a jukebox and play songs, then the OOP approach says that you begin by asking yourself what is a jukebox? A decent way to think about this is to write out a few descriptive sentences about the jukebox. Something like this:
A jukebox takes its songs and can play them. The jukebox has a feature that pauses or stops the song too. A jukebox will display a picture of the album being played.
You look at these sentences and see that we can begin to construct a crude definition of a jukebox. The nouns (songs and pictures) suggest that these two items would make for good attributes. Meanwhile the verbs (play, pause, and display) would make for good behavior methods. So the jukebox has behavior and attributes. When you write this class you have a robust(hopefully) user-defined class which is nothing more than a blueprint for making a jukebox object. The class itself is not an object but rather a recipe for making objects. You make an object by instantiating a jukebox object like this:
cJukeBox myJukeBox; //creates a jukebox object called myJukeBox
I hope this gives you an idea of what OOP is. It's like seeing the world as not a whole but rather as a bunch of little pieces that work together to make a whole.
OOP is taking the program and describing it in terms of objects. What is an object? Well an object is a user-defined data type that has behavior and attributes. For example, if you need to write a program that acts like a jukebox and play songs, then the OOP approach says that you begin by asking yourself what is a jukebox? A decent way to think about this is to write out a few descriptive sentences about the jukebox. Something like this:
A jukebox takes its songs and can play them. The jukebox has a feature that pauses or stops the song too. A jukebox will display a picture of the album being played.
You look at these sentences and see that we can begin to construct a crude definition of a jukebox. The nouns (songs and pictures) suggest that these two items would make for good attributes. Meanwhile the verbs (play, pause, and display) would make for good behavior methods. So the jukebox has behavior and attributes. When you write this class you have a robust(hopefully) user-defined class which is nothing more than a blueprint for making a jukebox object. The class itself is not an object but rather a recipe for making objects. You make an object by instantiating a jukebox object like this:
cJukeBox myJukeBox; //creates a jukebox object called myJukeBox
I hope this gives you an idea of what OOP is. It's like seeing the world as not a whole but rather as a bunch of little pieces that work together to make a whole.
Author
I've just discovered Alan Kay invented term. And heres a quote...
"OOP to me means only messaging, local retention and protection and
hiding of state-process, and extreme late-binding of all things. It
can be done in Smalltalk and in LISP. There are possibly other
systems in which this is possible, but I'm not aware of them."
"OOP to me means only messaging, local retention and protection and
hiding of state-process, and extreme late-binding of all things. It
can be done in Smalltalk and in LISP. There are possibly other
systems in which this is possible, but I'm not aware of them."
Isnt that message based? Not OOP? Message based is a whole other paradigm I believe. Look up OOP on wikipedia, it has good info. Hope that helps.
Nobody really knows what object-oriented programming is.
Personally, I don't think the thing makes sense. I don't believe in programming paradigms. I've written enough functional C++ and imperative Lisp code to know that the supposed 'distinctions' between different paradigms don't really exist.
OOP is just a name given to a loosely defined set of programming techniques which are, by OOP proponents, considered to be good style. Some OOP detractors think that some (but not all) of those programming techniques are bad style.
Most people seem to agree that OOP consists of objects which encapsulate program state with mechanisms for querying and modifying that state, and that objects should be classified by the interface they provide rather than the state they encapsulate.
Outside of that, there are a lot of programming practices which some people think are part of OOP, but others do not.
For example, many people think that functions should be first class objects, whilst many other people (the designers of Java, for one) think that only instances of classes are "objects".
Many people think that inheritance is a good way to allow objects to share the state and behaviour of other objects. Many people think that inheritance has it all wrong and that composition is a good way to allow objects to share the state and behaviour of other objects.
Many people think that special types of objects called classes should serve as object "templates". Many people think that any object should be able to be used as a template.
Many people think that message-passing is the correct way to think about how control passes around an OOP program, and that function calls should map directly to message invocations; therefore single dispatch is the only morally correct choice. Many people think that functions should be able to dispatch on all of their arguments.
Many people think that classes are the only moral top level unit of decomposition. Many people think that classes, enumerations, namespaces, modules, typedefs, functions and sundry other things they consider 'objects' should be allowed at the top level.
Importantly, many people think that people who disagree with them about one of these choices is not, in fact, using OOP. Thankfully, many people think that OOP is a nebulous term not to be applied with exacting precision.
My point of view is that what most people mean by OOP is really just the consistent application of good programming practices.
Encapsulation was not an OOP invention: people had been encapsulating behaviour in subroutines for years. With ADTs, people figured you could encapsulate data and behaviour in a single package. Polymorphism was certainly not an OOP invention.
Since programming languages gained useful syntax, common mathetical operations have (almost universally) been polymorphic across all numeric types, and many languages supported polymorphic functions before OOP was famous. All that OOP does is extend this polymorphism to the functions which invoke encapsulated behaviour: an important extension, yes, but not in itself revolutionary.
Personally, I don't think the thing makes sense. I don't believe in programming paradigms. I've written enough functional C++ and imperative Lisp code to know that the supposed 'distinctions' between different paradigms don't really exist.
OOP is just a name given to a loosely defined set of programming techniques which are, by OOP proponents, considered to be good style. Some OOP detractors think that some (but not all) of those programming techniques are bad style.
Most people seem to agree that OOP consists of objects which encapsulate program state with mechanisms for querying and modifying that state, and that objects should be classified by the interface they provide rather than the state they encapsulate.
Outside of that, there are a lot of programming practices which some people think are part of OOP, but others do not.
For example, many people think that functions should be first class objects, whilst many other people (the designers of Java, for one) think that only instances of classes are "objects".
Many people think that inheritance is a good way to allow objects to share the state and behaviour of other objects. Many people think that inheritance has it all wrong and that composition is a good way to allow objects to share the state and behaviour of other objects.
Many people think that special types of objects called classes should serve as object "templates". Many people think that any object should be able to be used as a template.
Many people think that message-passing is the correct way to think about how control passes around an OOP program, and that function calls should map directly to message invocations; therefore single dispatch is the only morally correct choice. Many people think that functions should be able to dispatch on all of their arguments.
Many people think that classes are the only moral top level unit of decomposition. Many people think that classes, enumerations, namespaces, modules, typedefs, functions and sundry other things they consider 'objects' should be allowed at the top level.
Importantly, many people think that people who disagree with them about one of these choices is not, in fact, using OOP. Thankfully, many people think that OOP is a nebulous term not to be applied with exacting precision.
My point of view is that what most people mean by OOP is really just the consistent application of good programming practices.
Encapsulation was not an OOP invention: people had been encapsulating behaviour in subroutines for years. With ADTs, people figured you could encapsulate data and behaviour in a single package. Polymorphism was certainly not an OOP invention.
Since programming languages gained useful syntax, common mathetical operations have (almost universally) been polymorphic across all numeric types, and many languages supported polymorphic functions before OOP was famous. All that OOP does is extend this polymorphism to the functions which invoke encapsulated behaviour: an important extension, yes, but not in itself revolutionary.
Quote:Original post by Falling Sky
Isnt that message based? Not OOP? Message based is a whole other paradigm I believe. Look up OOP on wikipedia, it has good info. Hope that helps.
In correct OOP terminology, a member function is a message (it instructs an object to perform a particular operation). Hence the quote.
I tend to agree with Nathan on this one: OOP is a very neboulous term. For example, one can perfectly use OOP without inheritance (using the composition pattern and maybe function pointers). OOP is not bound by the technical possibilities of a language (see GTK+: C don't have inheritance, but GTK+ is an (over-engineered) object oriented framework).
Regards,
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
