Stephen Davies wrote:
The Car Instance variable (in this case MyCar ref) has control of the goFaster() method of the Driver Class.
Even If you make the myCar reference private, then it still has controll over the goFaster() Method despite being hidden from outsiode the Driver class.
Stephen, I think you are a little confused in that example. The problem here is not that myCar has control over the goFaster() method (which it doesn't.) The problem is that the goFaster() method directly accesses the implementation of the Car class because the Car class is poorly encapsulated (the speed instance variable does not have access protection.) Thus, the Driver class becomes tightly coupled to the Car class. If the Car class coder decides to change the implementation (for example, change the name of the speed instance variable, make it private, or simply remove it,) it will break Driver's code. Again, the tight coupling in this case is a direct result of poor encapsulation.
Stephen Davies wrote:
What about this:
Ok so this is pretty basic, but the BankAccount is Encapsulated according to JavaBean specs, but still is influenced by the cutomer class is it not?
In this case it's the Customer class that is poorly encapsulated (the balance field has default access, which means that any class in the same package can access it freely.) Whether this should be acceptable or not is debatable (you can argue that since both classes are in the same package, and probably under the control of the same programmer, this should be appropriate. I personally think it's still poor encapsulation.) Again, the class BankAccount becomes tightly coupled to the Customer class because Customer is poorly encapsulated. It's not the BankAccount class that has poor encapsulation, but the Customer class.
So unless I see a counterexample, I still think that tight coupling (as defined by K&B) can only take place through poor encapsulation.