5.1 Encapsulation, Coupling, CohesionHomepage  « Java5 Certification « 5.1 Encapsulation, Coupling, Cohesion

In our first lesson within this section we look at encapsulation, its advantages and how to achieve it within our code. We then look at the design principles of coupling and cohesion and describe the benefits of loose coupling and high cohesion.

Lets take a look at the points outlined at the Oracle Website for this part of the certification.

  • Section 5: OO Concepts

    • Develop code that implements tight encapsulation, loose coupling, and high cohesion in classes, and describe the benefits.

Encapsulation is a language mechanism used to restrict access to an object's components. In Java parlance this is a mechanism to restrict access to the members (instance variables and methods) of a class, constructors and even to the class itself. So how do we achieve this in Java?. Well Java provides us with the access modifier mechanism for restricting access to our classes, which are the basic unit of encapsulation in Java. We can also restrict access to our instance variables whilst providing access to them via public methods. We can limit construction to the class itself using the private keyword, or to the package the implementation is in using the protected keyword or with no modifier package-private / (the default). The table below lists access modifiers in more detail.

Access Modifiersgo to top of page Top

The table below shows the four types of access available in Java from the most open (public) to the most restrictive (private). We can only explicitly apply the public access modifier to our top-level classes (the classes we compile) but for members and constructors we can explicitly apply the protected and private access modifiers as well. We will talk about packaging in the Packages lesson, but for now we are going to examine how to protect our class members from unwanted access and modification.

Access modifier Class Member Constructor Description
publicYesYesYesA top-level class may be declared with the public access modifier, and if it is the class is accessible to all other classes everywhere.
A member may be declared with the public access modifier, and if it is the member is accessible to all other classes everywhere, assuming the class it resides in is accessible.
A constructor may be declared with the public access modifier, and if it is the constructor is accessible to all other classes everywhere, assuming the class it resides in is accessible.
protectedNoYesYesA member may be declared with the protected access modifier, and if so, is only accessible within its own package and also by a subclass of its class in other packages.
A constructor may be declared with the protected access modifier, and if so, it is only accessible to the package the implementation is in.

See the Packages lesson for more information on packaging.
See the Inheritance Basics lesson for more information on subclassing.
no modifier
package-private /
(the default)
YesYesYesIf a top-level class has no explicit access modifier, which is the default and is also known as package-private, it is accessible only within its own package.
If a member has no explicit access modifier it is only accessible within its own package.
If a constructor has no explicit access modifier, it is only accessible to the package the implementation is in.

See the Packages lesson for more information on packaging.
privateNoYesYesA member may be declared with the private access modifier, and if it is the member is only accessible within its own class.
A constructor may be declared with the private access modifier, and if it is the constructor can only be constructed from within its own class.

See the OO Concepts - Encapsulation lesson for example usage and information on how we use getters and setters to enforce tight encapsulation.

Couplinggo to top of page Top

By definition coupling is the degree to which one class has knowledge of another or in other words one class has a dependency upon another. Tight coupling occurs when a dependent concrete class contains a pointer to another concrete class that provides the required behavior and should be avoided. The problem here is that any changes to one class could impact the other and the person making the changes may be completely unaware of this and thus unknowingly break the class. So how do we avoid this scenario? We design by contract by using an interface to specify an API for other classes to use as discussed in the OO Concepts - Interfaces lesson or by using encapsulation as discussed in the OO Concepts - Encapsulation. The following code is an example of tight coupling and should be avoided:


/*
  Tight coupling example
*/ 
class A {
    int i;
    B b = new B();
    i = b.value;      // No encapsulation of this variable in class B!
}
class B {
    public int value; // Should be private and be accessed through public getters and setters
}

Cohesiongo to top of page Top

Cohesion is the degree to which components of a class belong together to fit a particular role. What we want to avoid is low cohesion where a class incorporates several different aspects. A class that tries to do many things comes with higher maintenance and lower reusability.


/*
  Low cohesion example
*/ 
class AllInStaff {
    void getStaffSalary();
    void getStaffDetails();
    void getStaffSalesReport();
}
/*
  High cohesion example
*/ 
class Accounts {
    void getStaffSalary();
    ...
}
class Personnel {
    void getStaffDetails();
    ...
}
class SalesReporting {
    void getStaffSalesReport();
    ...
}

Related Java5 Tutorials

OO Concepts - Encapsulation
OO Concepts - Interfaces

<<  OO Concepts                    5.2 Polymorphism & Casting  >>

go to home page Java5 Tutor Homepage go to home page Top