D
Dave Benjamin
If you browse through the JavaDoc documentation for the SWT graphical user
interface toolkit, it won't be long before you descover that public fields
are used in many places. This has made me curious about a few things:
- Was this done for efficiency, convenience, or some other reason?
- Does this represent a trend away from a style of strict encapsulation?
- Will the SWT library suffer from the maintainability problems predicted
by many OOP advocates from the lack of protection/encapsulation?
- Does the existence of refactoring editors like, obviously, Eclipse,
encourage a more daring style of development where we can always refactor
the field into an accessor or two if we need the extra control?
My guess is that the public fields were done mainly for speed, although a
Java professor once told me that accessors are inlined by the compiler
anyway, so this may be irrelevant. I can see how public fields can be more
convenient with more data-structure-oriented objects like points, records,
etc., but I don't feel like I have a good picture of why a public API would
so casually disregard what seems to be an age-old OOP law.
Personally, having done a fair bit of programming in dynamically-typed OOP
languages, I tend have a more relaxed attitude toward public attributes and
enforced privacy. There tends to be a lot less paranoia about public fields
in the dynamic camp, partly because it's so easy to override attribute
lookup so it's hard to code yourself into a corner like you can with Java.
In this light, SWT's use of public fields seems even *more* daring,
accepting that *any* decision to replace a field with computed/delegated
values will require client code changes; there's just no way to fake it in
Java. For a library as big as the SWT, this surprises me.
What do you think about this? Do you think this will cause maintenance
problems for SWT? Is there any evidence that this has caused problems
already? Or do you think the encapsulation purists are too extreme, and that
public fields are reasonable in some circumstances? If so, what circumstances?
Thanks for your input,
Dave
interface toolkit, it won't be long before you descover that public fields
are used in many places. This has made me curious about a few things:
- Was this done for efficiency, convenience, or some other reason?
- Does this represent a trend away from a style of strict encapsulation?
- Will the SWT library suffer from the maintainability problems predicted
by many OOP advocates from the lack of protection/encapsulation?
- Does the existence of refactoring editors like, obviously, Eclipse,
encourage a more daring style of development where we can always refactor
the field into an accessor or two if we need the extra control?
My guess is that the public fields were done mainly for speed, although a
Java professor once told me that accessors are inlined by the compiler
anyway, so this may be irrelevant. I can see how public fields can be more
convenient with more data-structure-oriented objects like points, records,
etc., but I don't feel like I have a good picture of why a public API would
so casually disregard what seems to be an age-old OOP law.
Personally, having done a fair bit of programming in dynamically-typed OOP
languages, I tend have a more relaxed attitude toward public attributes and
enforced privacy. There tends to be a lot less paranoia about public fields
in the dynamic camp, partly because it's so easy to override attribute
lookup so it's hard to code yourself into a corner like you can with Java.
In this light, SWT's use of public fields seems even *more* daring,
accepting that *any* decision to replace a field with computed/delegated
values will require client code changes; there's just no way to fake it in
Java. For a library as big as the SWT, this surprises me.
What do you think about this? Do you think this will cause maintenance
problems for SWT? Is there any evidence that this has caused problems
already? Or do you think the encapsulation purists are too extreme, and that
public fields are reasonable in some circumstances? If so, what circumstances?
Thanks for your input,
Dave