[Home]History of Object Oriented Programming

HomePage | Recent Changes | Preferences

Revision 9 . . (edit) December 18, 2001 7:06 am by Hannes Hirzel
Revision 8 . . December 18, 2001 7:05 am by Hannes Hirzel [reformatted entry a bit; still messy]
Revision 7 . . (edit) October 26, 2001 5:45 am by (logged).157.137.xxx
  

Difference (from prior major revision) (minor diff)

Changed: 10,12c10,12
- 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.
- inheritence? 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.
* 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.

Changed: 17,22c17,22
- [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 used 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.
* [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.

Changed: 26c26
/Talk?
/Talk?

HomePage | Recent Changes | Preferences
Search: