Differences between version 4 and predecessor to the previous major change of ObjectOrientedProgramming.
Other diffs: Previous Revision, Previous Author, or view the Annotated Edit History
| Newer page: | version 4 | Last edited on Saturday, June 21, 2003 1:35:42 am | by SamJansen | Revert |
| Older page: | version 3 | Last edited on Friday, May 30, 2003 11:27:04 am | by DavidHallett | Revert |
@@ -66,6 +66,16 @@
There is a lot of theory involved in ObjectOrientedProgramming. A lot of processes have been invented in attempts to make designing systems easier: people who have studied it may remember CRC cards and class diagrams. Object oriented design purists will talk about class responsibilities and communications between classes and such.
Done well, object oriented programming is great. Given a good design, doing it well is not all that hard. Getting a good design is often near impossible.
+
+----
+
+Now, you do not have to go all out when using ideas that form parts of ObjectOrientedProgramming. PerryLorier pointed out after reading this article that ObjectOrientedProgramming has bought some very useful ideas into programming languages that can be used for general purpose programming.
+
+Encapsulation - everything in a class is __encapsulated__ in that class. A class is its own [Namespace]. This is an idea you often do not understand too well when you are new to programming but makes a lot of sense as you get a bit more experienced at writing somewhat larger applications. Now, the idea of full encapsulation of data and functions is quite a powerful one. It allows us to instantiate an object of some class and know it only works on its own data. It even easily allows us to instantiate more than on instance and know each will work separately. There is a little more to it than this, but that is the basic idea: functionality and data __encapsulated__.
+
+Increased type checking is helpful in many cases, the use of some object oriented techniques can help find type errors in some languages earlier. Not all languages need stronger type checking, though, and not all programmers want this. In general it is fair to say it helps lower programmer errors, though, making it a useful feature of object oriented techniques.
+
+The last two points are just trying to get across the fact that some of the ideas of ObjectOrientedProgramming can be used in general programming without "going the full hog" and using all the design patterns and implementing things in a purely object oriented way.
(Feedback to SamJansen if you like)
