A team of programmers is reviewing a proposed API for a new utility class. After some discussion, they
realize that they 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?
Shubham Semwal wrote:oh yes.. i know the answer now, it's Looser coupling and higher cohesion.
And why do you think those are correct? I would answer differently.
It's a bit confusing but i'd go with these two due to the following reasons :
looser coupling : Since they were able to remove some methods without change in any functionality it's safe to assume that either these methods were accessing fields of other classes or their code is now added to remaining methods. [it's a good contender for answer]
higher cohesion : Taking the 2 cases for loose coupling both increase the cohesion of existing class resulting in specialized methods (or the cohesion remains the same but certainly it doesn't lowers.)
Encapsulation : Not enough info for either of the options.
A and D would be my answers as well, but wow, what a vague and terrible question. Merely saying you're "reducing methods without losing functionality" can be applied to a lot of principles. Also having more methods isn't even necessarily a bad thing in itself, sometimes it makes code a lot easier to read.
I got my answers more from a process of elimination approach.
A, D, and F are generally considered "good". No one is having a meeting deciding that their classes need tighter coupling and lower cohesion. F, however generally means writing more methods because you're creating more getters and setters. So that just leaves A, and D.
I would say that there is a good case to say that 'F' implies less getters and setters, not more. The less ways there are to directly access the contents or state of an object the better encapsulated its functionality will be.
But obviously if the class is using public fields then it has no encapsulation.