The first of the three major principles of an object-oriented program is encapsulation. On an abstract level we think in terms of independent agents working together. Then we encapsulate the representation of the data and behaviour into a class, thereby defining its implementation and interface .
According to good object-oriented programming practice, an encapsulated design usually hides its implementation from the class user and reveals only its interface. A seed of clemantite was created in such manner. Realisation of all its behaviour are hidden from us, we know only how to grow it, we know the interface.
God did not provide detail documentation on how seeds are implemented, but from the experience of human beings we know their interface and have the class documentation about it's interface. In technique, an ordinary user does not usually need to know how the steering mechanism of a car is implemented, and do not know implementation details. A designer of class should have documentation about implementation to develop and possibly change the user-level documentation.
By the way, JAVA has a special mechanism to produce documentation that will be described in the next lectures.
To control access the members of a class, JAVA uses the keywords public, private, and protected. It is easy to surmise what does the first two mean. The last word, protected, is used to provide inherited classes with special access privileges to the members of their base classes.
Usually for a good designed class user cannot modify the values in the instance variables without going through the interface.
Do you remember the fragments of the code? Now let's have a look at the full source.
1 class Human {
2
3 int tired; // instance variables
4 String name; // of the class
5 String origin; //
6
7 // instance method to store data
8 void setPerson (int state, String na, String orig) {
9 tired = state;
10 name = na;
11 origin = orig;
12 } // end method setPerson
13
14 // instance method to display info of a human
15 String getHumanInfo() {
16 String info;
17 info = ("My name is " +
18 name + " and I am " +
19 origin + " ");
20 if (tired > 1)
21 info = info +
22 ("I am very tired.");
23 else
24 info = info +
25 ("and I am ready to work.");
26 return info;
27 } // end method showHumanInfo
28
29 void drinking(){
30 System.out.println(
31 "I like drink with friends" );
32 }//end drinking()
33
34 // instance method Work
35 String Work() {
36 if (tired < 2) {
37 tired ++;
38 return
39 ("Ouff... working again...");
40 }
41 else
42 return
43 ("Sorry can't work, being too exhausted.");
44 } // end method Work
45
46 String rest() {
47 if (tired < 1)
48 return
49 ("Not very tired, so going to a party.");
50 else {
51 tired --;
52 return
53 ("Sleeping, hhhharrarrrdrrhhhh...");
54 }
55 }
56 } // end class Human definition
57
58 // Driver program
59
60 class ex1 { // defining the controlling class
61 public static void main(String[] args) { // define main
62
63 Human obj = new Human ();
64 obj.setPerson(0, "Olexiy", "Ukrainian"); //store data
65 // Get info about Olexiy
66 System.out.println ( obj.getHumanInfo() );
67 } //end main
68 } //end ex1 class
In general, to be visible to a user, the class consists of the public methods. In our program all methods as well as classes are public by default. The class user stores, reads and modifies values by invoking those methods. In the program above we used method setPerson to input information about me, and than getHumanInfo to get information about me.
The program we are examining has no hidden the implementation. From the OOP point of view, this is not a well-designed program, but it is too simple!
Note, in our program we used methods setPerson and getHumanInfo. There is a special note about names of the methods started with set and get:
Methods whose names begin with set and get have a special meaning in JAVA. In particular, the introspection capability of the JAVA Beans API considers these names to represent design patterns for manipulating the properties of an object.
An object-oriented design is not a good design by default. In an attempt to produce good designs, there are some general agreements on certain design standards for classes. For instance, the data members (instance variables) are usually private. The interface usually consists only of methods and includes few if any data members. This is, of course, a way of hiding the implementation.
However, there is one exception to this general rule: the data members which are going to be used as symbolic constants are made public and defined to disallow modifying their values.
The methods in the interface should control access to, or provide a pathway to, the private instance variables. The interface should be generic as possible, in that it is not bound to any particular implementation. It means, from the practical point of view, that the arguments of the method should have the same meaning. If for some reasons changing implementation is needed, it should be done in a such way to avoid changing the interface.
In our program we have only instance variables and instance methods. Let us have a look at class variables and class methods.