Less APIs or more encapsulation?

Question

3 class, A contains B, B contains C. So user want to use some service of C, there are two choice:

First, more encapsulation:

class A:
    def newMethod(self):
        self.b.newMethod()

class B:
    def newMethod(self):
        self.c.newMethod()

class C:
    def newMethod(self):
        #do something
        pass

a.newMethod()

Call service of c directly:

class A:
    pass

class B:
    pass

class C:
    def newMethod(self):
        #do something
        pass


b = a.b
c = a.c
c.newMethod()

Generally, what I learned from books told me that 1st choice is better.
But when C has many many methods to expose to outer user, 2nd choice seems to be more reasonable. And in the first design, A and B did nothing really useful.

What will you choose?

Answer 1

Get your objects to do things for you, rather than asking them for their data and doing stuff with it.

If c in your example is exposing a lot of methods, I would suggest that you shouldn't be exposing these to a and your clients, but rather a and b should be working together to use these methods on behalf of the client.

A good indicator of a problem is a class that contains data, and provides getters for those data items, and the client code accessing that data and then performing work (DAOs excepted). In this (common) scenario the class most likely shouldn't be exposing that data (and perhaps breaking encapsulation), but rather doing the work for that client (either by having that functionality, or perhaps some injectable strategy object).

Check out the Law of Demeter (the linked document looks rather dry and academic, regrettably), which offers some good guidelines as to how objects and members should communicate.