Penguin
Recent Changes
Blame: ObjectOrientation
EditPageHistoryDiffInfoLikePages
Annotated edit history of ObjectOrientation version 3, including all changes. View license author blame.
Rev Author # Line
1 AristotlePagaltzis 1 A style and to an extent a paradigm of programming. A ProgrammingLanguage may, but does not have to support this style for object oriented code to be written in it. Though furiously hyped by [MarkeTroid]s since the late 1990s, serious programmers find it overused. It also underdefined, which means many people will claim something is object oriented when just some of the paradigms principles are implemented.
2
3 The central concept in OO is to model your problem as set of self contained objects. A self contained object respects the three fundamental principles:
4
5 !! Encapsulation
6
7 AddToMe
8
9 !! Delegation / Inheritance
10
11 AddToMe
12
13 !! Polymorphism
14
15 AddToMe
2 AristotlePagaltzis 16
17 ----
18
19 In [ProgrammingLanguage]s with StrongTypeChecking, objects are often instances of a class, an abstract DataType.
20
21 ----
1 AristotlePagaltzis 22
23 !!! Some criticism and discussion
24
25 ''needs cleanup and reflow. possibly its own page? --AristotlePagaltzis''
26
27 Sounds nice doesn't it? Code reuse! Your programmers will spend less time re-inventing the wheel! That means more money to be had.
28
29 Or does it? Lets take a look at how object oriented programming works a little closer before making any judgements.
30
31 A basic component is often called a __class__. Lets make a class (in Java for now).
32
33 public abstract class Animal {
34 public abstract String getName();
35 public void talk() {
36 System.out.println("Hi, I am an animal.");
37 }
38 }
39
2 AristotlePagaltzis 40 What a boring class. Let us ''extend'' this class a little by ''inherit''ing from it.
1 AristotlePagaltzis 41
42 public class Dog extends Animal {
43 public String getName() { return "Dog"; }
44 public void talk() {
45 super.talk();
46 System.out.println("I am a specific animal: a dog!");
47 }
48 }
49
50 public class Cat extends Animal {
51 public String getName() { return "Cat"; }
52 public void talk() {
53 System.out.println("There may be talking dogs, but cats do not talk.");
54 }
55 }
56
57 "So what" you say? Things still boring. Ok, here is the catch. Have a read of the following code:
58
59 public void hello(Animal a) {
60 System.out.println("Talking to a " + a.getName() + ".");
61 a.talk();
62 }
63
64 This takes an Animal as a parameter. If called as follows:
65
66 hello(new Dog());
67 hello(new Cat());
68
69 We get the desired functionality:
70
71 Talking to a Dog.
72 Hi, I am an animal.
73 I am a specific animal: a dog!
74 Talking to a Cat.
75 There may be talking dogs, but cats do not talk.
76
77 There are a few concepts here. First is inheritance. The Dog and Cat inherit from Animal, meaning they have same functionality by default as Animal. See what the Dog does? It calls its ''superclass'', the Animal, in the talk() function. The Cat does not. This allows the programmer to either extend or replace functionality. The next is the concept of an ''abstract'' function. Look at getName(). It doesn't have any code; it doesn't do anything for an Animal. You can't just go an make an Animal in the code above, you need to create either a Cat or a Dog. This is because the abstract function, otherwise known as a ''pure virtual'' function prevents the Animal class from being created. Now, look at the simple hello() function. It takes an Animal as a parameter! But Animals can't exist, can they? Well, no they can't. The Animals passed to hello() are actually classes inherited from Animal, a Cat and a Dog passed in. We can see here we have an ''is a'' relationship: because a Cat ''is an'' Animal and a Dog ''is an'' Animal it is allowed to be treated as an animal inside the hello function. Next concept is ''polymorphism''. Even though the hello function only knows about the Animal class, when it calls the getName() and talk() functions the functions inside the Cat and Dog are actually called. Get it? If you don't, I'm not suprised. Go get a book about object oriented coding. I can't cover it all here.
78
79 Now, the nice thing here is that you can write code to only deal with Animals. Then someone out there can go and code a Human Animal, for instance, and all your code will work nicely with this new case without any modification. Isn't that cool?
80
81 Ok, sure, it is a contrived example. Which is actually a bit of a problem. You see, given a very good design, object oriented programming is, well, very good. Unfortunately, this design is very hard to come by. Some think it is impossible for many situations. So therein lies the real problem. It is easy to think up silly situations where object oriented programming works flawlessly. In practice, it can be very hard to apply. There are some good situations. Windowing systems come to mind: a well designed GUI can make excellent use of object oriented programming.
82
3 StuartYeates 83 Technical difficulties also get in the way at times. [C++] especially suffers here. All sorts of complexity has gone into allowing C++ to be useful as an object oriented language. The COM programming model by Microsoft is an example of an excellent attempt at making C++ useful as a component-based and object-oriented language.
1 AristotlePagaltzis 84
2 AristotlePagaltzis 85 There is a lot of theory involved in ObjectOrientation. 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.
1 AristotlePagaltzis 86
87 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.
88
89 ----
90
2 AristotlePagaltzis 91 Now, you do not have to go all out when using ideas that form parts of ObjectOrientation. PerryLorier pointed out after reading this article that ObjectOrientation has bought some very useful ideas into programming languages that can be used for general purpose programming.
1 AristotlePagaltzis 92
93 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__.
94
95 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.
96
2 AristotlePagaltzis 97 The last two points are just trying to get across the fact that some of the ideas of ObjectOrientation 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.
1 AristotlePagaltzis 98
99 (Feedback to SamJansen if you like)
3 StuartYeates 100
101 ----
102 Object oriented languages don't have [Function]s, they have [Method]s, which are functions associated with an object or class (static objects in [Java], for example are associated with the class but not an object). All of the optimisations applicable to [Function]s (InLining, etc.) are also applicable to [Method]s.