Object Oriented Programming (OOP) is a software design methodology, in which related functions and data are lumped together into "objects", convenient metaphors, often mirroring real world things or concepts.
Some computer languages are inherently Object Oriented, such as Smalltalk, Java and Python, while others are a hybrid of OOP and otherwise, such as Perl and C++.
In terms of OOP languages I would say that there is a broad gradiation of the OOPishness of languages, ranging from
Smalltalk, self
? and
Ruby, in which literally everything in the language is an object, to languages such as
Java and
Python that are quite OOPish but also include [primitive data types]
?, to languages like
Perl and
C++, which are pre-OOP languages that have added some OOP features. And, of course, there are languages like
C and
assembler that aren't OOPish at all. That being said, OOP is more of a design philosophy than an attribute of a particular language, though the attributes of particular languages make OOP dramatically more easy or hard. But in theory you could do OOP in FORTRAN, or procedural programming in Smalltalk. In reality, of course, the languages and tools that you use shape what you produce.
OOP could be defined in terms of what it isn't, which is procedural programming.
Object Orientation is typically considered to consist of the following properties:
- encapsulation? means that you package the internal data structures and algorigms that operate on it into a class that hides its internals. This means that each class provides well-defined functions, and the implementation of those functions is hidden from anyone else who uses the class. This has some advantages: you can more easily debug the code because its functionality is limited and well defined. You can more easily use the code because you only need to learn the external interface, not understand the implementation. And you can rewrite the internal implementation of a class without breaking code that uses your class.
- inheritance? means that classes can extend other classes. This means that if you have many kinds of things in your program that share some behavior (e.g. SortableStuff?) you can extract out the common functionality into a common parent class so that you can write and debug the functionality once and reuse it easily elsewhere. There are a variety of interitence mechanisms, such as [single inheritance]?, multiple inheritance and interfaces?.
- polymorphism means that your code cares as little as possible about the class (data type) of the things it works with. For example, a good sort function should use polymorphism so that it could sort any kind of data that had a compare() function, so that you could later use it to compare things that you did not anticipate when it was first written. For example, if you wrote a sort function to handle numbers, it could later sort people, or colors, or buildings by capacity, so long as those classes of objects know how to compare themselves to each other.
Of course, those descriptions make a lot of assumptions that should be elaborated, which is why people write books about OOP. For example, the underlying goals of OOP are to increase software reliability and maintainability, and to make large software projects more manageable.
Also, OOP approaches to development tend to emphasise the complete development and runtime environment, not just the syntax of the language. Most OO languages are associated with:
- [runtime binding]? variables are associated with data of various types at runtime, rather than when the program is compiled.
- garbage collection means that the runtime environment manages memory rather than the programmer. This adds some performance overhead, but eliminates the source of 3/4ths of all coding errors in non-GC languages.
- [virtual machines]? allow the same compiled code to run on many different hardware platforms. Smalltalk was the first widely to use a VM that I know of, though there were many others. Java and C# are more recent languages with VM's.
- Integrated Development Environment, or IDE, is an idea from the OOP world that has been widely adopted across nearly all languages. The idea is that the tools should understand the language and what the programmer is doing, and present structured tools, rather than simply being a text editor. For example, a good IDE will allow you to browse the classes that you have written, and easily work with the methods for a given class, or see what code calls a given method.
- [the code is the documentation]? is a popular concept in OOP. The idea is that since the classes model business objects (people, departments, products, events) that it is most natural to document them via comments in the code, and that things should be given expressive names. That is, instead of writing loop as "for i=1 to 10" you might write "for each department in the bookstore" which is a better communication of the programmer's intent. Good OOP environments have tools that can allow you to easily browse such documentation, and to build traditional documentation (web pages, printed documents) from the code's structure and comments.
- [Iterative development]? means that instead of managing a software system as one, huge system, spending months getting the specifications just right, and then throwing a team at if for six months, then shipping the result to QA, you can apply decomposition? to manage the project as a series of small, more tractable projects. You can define a small part of the overall problem to solve, implement it rapidly, and test it, so that you can then iteratively expand the system.
Of course, some or all of the above can be applied without necessarily using OOP, or an OOP language. I have seem good IDE's for coding straight C, and iterative development, without any OOP aspects all, for example.
/Talk
![[Home]](wikipedia.png)