Question regarding encapsulation

[kumarjit banerjee]

I am preparing for the SCJP 6 and following the book of K&B and I encountered the following question.

Question

Given:
1. ClassA has a ClassD
2. Methods in ClassA use public methods in ClassB
3. Methods in ClassC use public methods in ClassA
4. Methods in ClassA use public variables in ClassB

Which is most likely true? (Choose all that apply)

A. ClassD has low cohesion
B. ClassA has weak encapsulation
C. ClassB has weak encapsulation
D. ClassB has strong encapsulation
E. ClassC is tightly coupled to ClassA

Ans. C

Then with respect to this question consider the following code

public class Demo{
int[] a = new int[10];
public static void main(String[] args);
int k = a.length;
}
}

So in the class Demo the public variable length of the array class. So is the array class has weak encapsulation.

[Mohamed Sanaulla]

The array in your example is not public.

And this- 4. Methods in ClassA use public variables in ClassB - is the reason why C is true. For something to be public- it has to be declared as public.

[kumarjit banerjee]

Mohamed Sanaulla wrote:The array in your example is not public.

And this- 4. Methods in ClassA use public variables in ClassB - is the reason why C is true. For something to be public- it has to be declared as public.

Here the main method of Demo class which is public is using the public variable of the array of int that is length.
So the array class of int has weak encapsulation

[Mohamed Sanaulla]

Its not only for the int array but for all the arrays the length can be accessed via the variable- length. And you should be trying to set the value for "length". You cannot because length is a final variable. So its basically a constant which holds the length of the array.

Also there's a compilation issue with your program, you might want to fix it after trying to compile the code.

[Suhrid Karthik]

I think the original question was related to the practice of accessing a variable. Everybody tells you that variables should not be accessed directly and then you have something like array.length right in the core of the language. One would expect to see array.getLength() instead.

[Mala Gupta]

The following is from the Java Language Specification (http://java.sun.com/docs/books/jls/second_edition/html/arrays.doc.html):

10.7 Array Members
The members of an array type are all of the following:

* The public final field length, which contains the number of components of the array (length may be positive or zero)
* The public method clone, which overrides the method of the same name in class Object and throws no checked exceptions
* All the members inherited from class Object; the only method of Object that is not inherited is its clone method

Since the array type has a public variable (length), it isn't well encapsulated. A well encapsulated class shouldn't allow direct access to any of its variables.

[M Srilatha]

Hi,

Encapsulation says that none of the instance variables should be public so that the variable values cant be changed directly accessing those variables. Instead all instance variables should be private and the class needs to have public methods to modify the value of private variables.

in your example, the length property of array is a final variable and one cant modify the value of a final variable. So even if the property is public, it doesnt violate the encapsulation concept.
So its also well encapsulated.

Hope this is clear!

Regards,
Srilatha

[Mohamed Sanaulla]

M Srilatha wrote:
...

in your example, the length property of array is a final variable and one cant modify the value of a final variable. So even if the property is public, it doesnt violate the encapsulation concept.
So its also well encapsulated.

I was trying to explain this

[Mala Gupta]

M Srilatha wrote:Hi,

Encapsulation says that none of the instance variables should be public so that the variable values cant be changed directly accessing those variables. Instead all instance variables should be private and the class needs to have public methods to modify the value of private variables.

in your example, the length property of array is a final variable and one cant modify the value of a final variable. So even if the property is public, it doesnt violate the encapsulation concept.
So its also well encapsulated.

A well encapsulated class does not allows 'direct' access to its instance variables, even if they are defined as 'final' members. What happens, if for some reason, the author of the class decides to use an instance variable 'size' to define the length of an array. In this case, the following code will crash:

int[] myArr = new int[5];
System.out.println (myArr.length);

However, the getLength() can easily be redefined by the author as follows:

public int getLength() {
        // return length;          // previous code
        return size;                 // new code
}

If getLength() is used to access the 'length' of an array, the following code (written by another programmer) will survive:

int[] myArr = new int[5];
System.out.println (myArr.getLength());

One of the main goals of encapsulation is to facilitate modification of the 'inner' working of a class, without making any other code to crash that uses it.

I would re-iterate that defining a public 'final' instance variable doesn't evaluate to defining a well encapsulated class.

cheers
Mala

[Anton Sotnikov]

By the way I have a similar question:

A team of programmers is reviewing a proposed API for a new utility class. After some discussion, they realize that that can reduce the number of methods in the API without losing any functionality. if they implement the new design, which two OO principles will they be promoting?

- Looser coupling
- Tighter coupling
- Lower cohesion
- Higher cohesion
- Weaker encapsulation
- Stronger encapsulation

And what do you know What does it mean separately?
Please bring explanation.
thanks!

[Henry Wong]

Anton Sotnikov wrote:By the way I have a similar question:

A team of programmers is reviewing a proposed API for a new utility class. After some discussion, they realize that that can reduce the number of methods in the API without losing any functionality. if they implement the new design, which two OO principles will they be promoting?

Please QuoteYourSources

Henry

[Rico Felix]

The concept of encapsulation in object-oriented programming is to wrap data and methods that operate on the data into a single component by means of a class... This provides a protection layer between the client and the data because its suppose to hide the data which can only been seen and manipulated through the use of the methods in the component... Therefore the client should not even be aware of specifics of the component but only what services it provides... With that being said it should be clear that any component that exposes its internals by use of public field members is not properly encapsulated even if that member is final...

[Anton Sotnikov]

The concept of encapsulation in object-oriented programming is to wrap data and methods that operate on the data into a single component by means of a class.

As like?

Class One {

private int counts;

public One() {

count = 0;

}

public void SetCount(int x){

	counts = x;

}