As an opposite to "Make fields public", you might want to try full self-encapsulation, http://www.rolemodelsoftware.com/moreAboutUs/publications/articles/self-enc.php

Abstract State (and all the other patterns which depend on it) was my previous default design. But now that tool support makes it trivially easy to Encapsulate Field at any point in the future, I go for the simplest thing - which is to leave the field public.

When might you choose one approach over the other? That is, when is "Make fields public" a good or bad idea? When is full self-encapsulation a good or bad idea?

[with the important caveat that these rules do not apply to published APIs] this is a typically evolution for the internal state of a new class :

When a new class comes into being, I'll make all of its fields private - total encapsulation.

As I add new behavior, I try to follow the "tell, don't ask principle" and keep the internal state private whenever possible.

Sometimes, though, the state really does need to be made available to other classes. In that case, I'll just make the field public.

If I discover that the state can be derived from other fields (like the diameter in the Abstract State pattern that Jason pointed us to) or if subclasses will have a different notion of what constitutes the value, I'll just Encapsulate Field and use the accessor method everywhere (inside and outside the class).

Ken Auer's paper implies that once you have committed to a particular data structure, it will be hard to change later, but modern refactoring tools make it trivial to change your mind later so it's possible to always do the simplest thing until you need something more flexible.

"Names of test methods should always include the word "should"...forces you to think more about the responsibilities of the object you are testing."

Yes. Separating "should" from statements about the problem, or problems with the solution, is so important, it's the basis of the issue/position/argument form that's so central to sorting out political 'shoulds'. If it can handle those messy problems, it can handle yours.

"Make fields public" vs. "Don't expose an object's state" can be best resolved by esuring that you have no objects that are so passive that they can work with fields exposed. Refactor. And do all your "setting" with assertions, in other words:

"...have a single assertThat() method that takes an actual value and a constraint. With suitable sugar-methods, you can make your assertions read almost like english :

assertThat(myFile, contains("this string));"

This is exactly the principle applied in the living ontology, that active verbs (from the perspective of the user or using service) ought to be strictly controlled as to their meaning. There's one list of all control verbs paralleling the list of all issues debated. The "should" language is restricted to positions, and assertions about testable behaviour exactly as you describe, i.e. many "position:" namespace articles have a "should" either explicit or implied in their title.

This restriction of verbs is the same principle as REST and standardized user interface design, which rely on a very few verbs ("preview", "post"). You might be familiar with it in dating services where such self-assertions as "I'm a ___ age __ in __ seeking a ___" are common. When I designed the predecessor to the lavalife service, reducing all the language to simple assertions with common verbs was the main goal, and it worked very well: the instructions read similarly to the screens, and so on. What's harder is to make errors and exceptions also converge to this language:

Bill Joy considers the convergence of error messages to the architectural objects to be the number one sign of good operating system design, and I agree.

How anyone thinks they can make user interfaces more natural for users to read, but also

W3C link checker    Powered by Movable Type 3.16
This weblog is licensed under a Creative Commons License.
Agitar, Agitator, Software Agitation, Open Quality, and Quality Level Agreement are trademarks of Agitar Software, Inc.

Terms of Use