1. CMSC 202
Encapsulation
Version 9/10

2. Types of Programmers Class creators Client programmers
those developing new classes
want to build classes that expose the minimum interface necessary for the client program and hide everything else
Client programmers
those who use the classes (a term coined by Scott Meyer)
want to create applications by using a collection of interacting classes
Version 9/10

3. OOP Techniques
Class creators achieve their goal through encapsulation.
Encapsulation:
Combines data and operations into a single entity (a class)
Provides proper access control
Focuses on implementation
Achieved through information hiding (abstraction)
Version 9/10

4. The Value of Encapsulation
Client programmers do not need to know how the class is implemented, only how to use it.
The information the client programmer needs to use the class is kept to a minimum.
Class implementation may be changed with no impact on those who use the class.
Version 9/10

5. Access Control Encapsulation is implemented using access control.
Separates interface from implementation
Provides a boundary for the client programmer
Visible parts of the class (the interface)
can only be used, not modified, by the client programmer.
Hidden parts of the class (the implementation)
Can be changed by the class creator without impacting any of the client programmer’s code
Can’t be corrupted by the client programmer
Version 9/10

6. Access Control in Java
Visibility modifiers provide access control to instance variables and methods.
public visibility - accessible by everyone, in particular the client programmer
A class’ interface is defined by its public methods.
private visibility - accessible only by the methods within the class
Others - later
Version 9/10

7. Date2 Class public class Date2 {
In this new date class, the instance variables have been labeled private.
public class Date2 {
private String month; private int day;
private int year;
public void toString( )
return month + “ “ + day + “ “ + year; }
// setDate and monthString same as Date1 class
Any Date2 class method may use the class’ private instance variables.
Version 9/10

8. Access Control Example
Date1 class - public instance variables were used
Date2 class - private instance variables are now used
public class Date2Demo {
public static void main( String[ ] args ) { Date2 myDate = new Date2( ); myDate.month = “July”; // compiler error myDate.day = 4; // compiler error
myDate.year = 1950; // compiler error
myDate.setDate( 7, 4, 1950 ); // OK – why?
System.out.println( myDate.toString( )); }
Version 9/10

9. Private Instance Variables
Private instance variables are only usable within the class.
Private instance variables hide implementation details, promoting encapsulation.
Private instance variables are not accessible by the client programmer (class user).
Good programming practice:
Label all instance variables as private.
The class has complete control over how/when/if the instance variables are changed.
Version 9/10

10. Encapsulation Summary
Combine methods and data in a single class.
Use private instance variables for information hiding.
Minimize the class’ public interface.
“Keep it secret, keep it safe.”
Version 9/10

11. Accessors & Mutator
Class behavior may allow access to, or modification of, individual private instance variables.
Accessor method
retrieves the value of a private instance variable
conventional to start the method name with get
Mutator method
changes the value of a private instance variable
conventional to start the name of the method with set
Gives the client program indirect access to the instance variables.
Version 9/10

12. More Accessors and Mutators
Question: Doesn’t the use of accessors and mutators defeat the purpose of making the instance variables private?
Answer: No
The class implementer decides which instance variables will have accessors.
Mutators can:
validate the new value of the instance variable, and
decide whether or not to actually make the requested change.
Version 9/10

13. Date2 Accessor and Mutator
public class Date2 {
private String month; private int day; //
private int year; // 4-digit year
// accessors return the value of private data
public int getDay ( )
{ return day; }
// mutators can validate the new value
public boolean setYear( int newYear ) {
if ( 1000 <= newYear && newYear <= 9999 )
year = newYear;
return true; }
else // this is an invalid year
return false;
// rest of class definition follows
Version 9/10

14. Accessor/Mutator Caution
In general you should NOT provide accessors and mutators for all private instance variables.
Recall that the principle of encapsulation is best served with a limited class interface.
Too many accessors and mutators lead to writing procedural code rather than OOP code. More on this later.
Version 9/10

15. Private Methods Methods may be private.
Cannot be invoked by a client program
Can only be called by other methods within the same class definition
Most commonly used as “helper” methods to support top-down implementation of a public method
Version 9/10

16. Private Method Example
public class Date2 {
private String month; private int day; //
private int year; // 4-digit year
// mutators should validate the new value
public boolean setYear( int newYear ) {
if ( yearIsValid( newYear ) )
year = newYear;
return true; }
else // year is invalid
return false;
// helper method - internal use only
private boolean yearIsValid( int year )
return 1000 <= year && year <= 9999;
Version 9/10

17. More About Methods
Different classes can define a method with the same name.
Java can determine which method to call based on the type of the calling object.
Example:
Date2 birthday = new Date2( ); Dog fido = new Dog( );
System.out.println(birthday.toString( ));
System.out.println(fido.toString( ));
birthday.toString( ) will call the toString( ) method defined in the Date2 class because birthday’s type is Date2.
fido.toString( ) will call the toString( ) method defined in the Dog class because fido’s type is Dog.
Version 9/10

18. Method Overloading
Two or more methods in the same class may also have the same name.
This technique is known as method overloading.
Version 9/10

19. public boolean setDate( int month, int day, int year )
Overloaded setDate
The Date2 class setDate method:
public boolean setDate( int month, int day, int year )
Suppose we wanted to change only the day and year?
Define another method named setDate:
public boolean setDate( int day, int year )
(After all, setDate is a good descriptive name for what this method does.)
Version 9/10

20. Date3 Class - Overloaded setDate Method
public class Date3 {
private String month;
private int day; //
private int year; // 4 digits
public boolean setDate( int newMonth, int newDay, int newYear )
// code here }
public boolean setDate( int newDay, int newYear );
// code here, doesn’t change month
// toString( ), monthString( ), setYear( ), etc. follow
Version 9/10

21. Date3Demo Class How does Java know which setDate method to call?
public class Date3Demo {
public static void main (String[ ] args)
Date3 myDate = new Date3( );
myDate.setDate( 1, 23, 1982 );
System.out.println( myDate.toString( ) );
myDate.setDate( 4, 1999 ); }
How does Java know which setDate method to call?
Version 9/10

22. Method Signature A method is uniquely identified by
its name and
its parameter list (parameter types and their order).
This is known as its signature.
Examples:
public boolean setDate(int newMonth, int newDay, int newYear)
public boolean setDate(String newMonth, int newDay, int newYear)
public boolean setDate(int newDay, int newYear)
public boolean setDate(int newDay, String newMonth)
Version 9/10

23. Return Type is Not Enough
Suppose we attempt to overload Date3’s setDay() method by using different return types.
public void setDay( int day ) { /* code here */ }
public boolean setDay( int day ) { /* code here */ }
This is NOT valid method overloading because the code that calls setDay( ) can ignore the return value.
birthday.setDay( 22 );
The compiler can’t tell which setDay( ) method to call.
Just because a method returns a value doesn’t mean the caller has to use it.
Version 9/10

24. Too Much of a Good Thing
Automatic type promotion and overloading can sometimes interact in ways that confuse the compiler. Example:
public class X {
//version 1
public void printAverage ( int a, double b) {/*code*/}
//version 2
public void printAverage ( double a, int b) {/*code*/} }
And then consider this:
X myX = new X( );
myX.printAverage( 5, 7 );
The Java compiler can’t decide whether to
promote 7 to 7.0 and call the first version of printAverage, or
promote 5 to 5.0 and call the second.
Version 9/10