On Tue, 8 Jul 2003, Carsten Ziegeler wrote:
Vadim Gritsenko wrote:
Carsten Ziegeler wrote: <snip/>
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 design-time.
Let me explain. Objects should *encapsulate* functionality. So they should keep data inside. Hence, no data should get out of the objects.
oooooh...
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 www.eckelobjects.com)
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 [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) ---------------------------------------------------------------------
