cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <>
Subject Re: protected vs private instance members (in Woody)
Date Tue, 15 Jul 2003 14:21:07 GMT
Giacomo Pati wrote, On 15/07/2003 15.33:

> On Tue, 8 Jul 2003, Carsten Ziegeler wrote:
>>Vadim Gritsenko wrote:
>>>Carsten Ziegeler wrote:
>>>>I hope this makes sense :) if not at all, we can revert it.
>>>Not exactly; see Sylvain's response and in addition to it please recall
>>>a vote about flow model "add only very necessary things instead of
>>>adding all and everything you can think of" (majority agreed with the
>>>vote). Parallel between this flow vote and java private/protected
>>>members is easy to see: have everything private and open up only very
>>>necessary stuff. And, preferably, open up via accessor methods.

Accessors are the negation of object orientation if not used at 

Let me explain. Objects should *encapsulate* functionality. So they 
should keep data inside. Hence, no data should get out of the objects.


So objects should use between themselves only method calls or messages. 
In essence, objects expose a service.

To separate contract from the implementation, it's necessary to use 
interfaces: the "messages" use the interface, while the encapsulated 
part of code and data is in the concrete object.

What does this mean? That getters and setters should *not* be used when 
the objects are used in the program, but only at design-time. If you 
look at the JavaBeans spec, in fact, it's exactly what is written.

>>This is really an interesting topic to discuss :)
>>Now, I don't agree :) I think the contract we define is based on
>>Interfaces and perhaps on abstract implementations, but not on
>>concrete implementations. You can't guarantee that an implementation
>>does not change over time.

You can. You need interfaces only when you need to treat different 
objects in the same manner.

For example, if I have

     Transportation --> Car

and I want to change how fast the car goes, I need only to change the 
inner part of Car. Did I need an interface Transportation? Nope.

Objects already abstract the inner parts. Interfaces are needed to 
abstract *between* different objects (I use object instead of "class" 
sometimes, please disregard).

>>Some examples: assume you use an int as an instance variable and
>>change it later on to an object (Integer). Now, it's regardless
>>if you make the variable private and have a getter method or
>>did make it protected.


>>Or assume, we change from Composable to Serviceable which is a very
>>legal change for an implementation. Even a getter method for the
>>component manager does not help as when implementing Serviceable
>>you don't have a component manager.

Using proxies, yes ;-)

>>So, I think implementations can change incompatible over time and
>>if someone relies on the implementation he has to change its
>>implementation as well. The contracts (like the above mentioned fom)
>>are defined by interfaces.

No, they are defined by the *public* *signatures*. That means that they 
are defined by all public methods. As I showed you above, if you have a 
public method, the class can and should encapsulate all behaviour. 
Regardless to the interface.

> I'd like to suggest reading "Effective Java" by Joshua Block. 

I suggest Thinking in Java, Bruce Eckel (also free as PDF on his site

> Especially:
> Item 13: Favor immutability.
> Item 14: Favor composition over inheritance
> Item 15: Design and document for inheritance or else prohibit it
> It clearly shows the danger of uncontrolled inheritance if you don't
> specifically design for it.

Nicola Ken Barozzi         
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)

View raw message