Books can be wrong or misleading. It is certainly true that having getters and setters for every field provides little more encapsulation than having those fields be public, and it's unfortunate that this kind of design is very widespread.
But it's nonsense to conclude that getters and setters should be avoided altogether. Instead, they should be added deliberately where appropriate, as part of the API design of the class:
- If everything a field does can be handled by domain-specific methods, don't have a getter or setter - this is the best case.
- If the value of a field is by itself useful and necessary for other classes, add a getter (not a setter)
- If the fields represents something like a configuration value, a way for the behaviour of the object to be influenced from outside, add a setter (and a getter iff knowing this configuration could also be useful to other classes).
A Comparator could be seen as an example for case 2, especially if the Comparator is deliberately used instead of having the class implement Comparable. This indicates that the comparison logic is external to the class, and it depends on the field, so the field is useful outside the class.
A compromise might be to have a package private (default visibility) getter and keep the comparator in the same package - or even have it as an inner class that accesses the private field. That would be appropriate if you want the class itself to offer a choice of different sort orders.
If your only concern is that the sort order may change globally in the future, I'd actually stay with Comparable - it's still a change in once place, no need to separate it artificially.
Part 1
This is a good design question. You are correct in detecting code smell concerning getters and setters. They generally indicate a design problem exposing the implementation details of your object.
Try to think in terms of what your objects should do - Tell, Don't Ask:
Your first problem may be that you are trying to design "data classes". Rather than worry about the data (implementation details), think about the functionality. Again, what should your objects do? In your case, what do you want to do with character styles? Who (software-wise) cares about character styles? What do they need to do?
Hopefully that gets you started. Test driven development helps with these kinds of design problems. It forces you to think in terms of function not data.
On the contrary, if all you need is a data container, write a C-style struct class and go to town. I wouldn't recommend that, maintaining it will be a $@#%#.
Good luck!
Part 2
What you want is either a simple data class - skip the getters and setters completely, or you want to create a platform independent abstraction that places a facade (Facade Pattern) in front of the rendering and style setting. It simply provides an interface for setting styles and rendering. Your platform specific implementation does the dirty work (using NSTextView in your example).
The benefit of the simple data class is that it is initially simple to write. Its drawback is that you will have a hard time avoiding a giant tangle of if-else statements. You will also be lacking a clear place to make you platform specific rendering calls that use the styles. As the system's complexity grows, you may find it more diffcult to decide where implementation details go.
The facade is a more abstracted approach. The benefits are that it is more flexible and can be reused if you decide to port to another platform. Its drawbacks are more upfront development time.
The facade's public interface will provide what you need to set and remove styles as well as initiate rendering when the time comes.
The details of how you want to set styles are up to you. Use what ever system feels best. Simple getters and setters or a generic set and get that uses a dictionary internally works too (see boosts ptree if you are using C++). You could even take all (or default) styles at construction time. You could decide to not even expose mutators at that point. Your call. Perhaps you decide it is important to data drive the styles you support and use a configuration plus factory system (We can add more detail later if that is important to you). In fact different implementatios of the facade could provide different ways of approaching the problem. You could prototype a few and choose what works best.
The platform specific implementation of you facade abstraction will use the platform specific rendering system (NSTextView in your case) and the styles you have set to make the appropriate calls to the system. Simply inject the platform specific classes at construction (Dependency Injection), implement your render() method and you should be good to go.
Part 3
If your system design allows, you could take all styles for a particular element at construction time. This could allow you to avoid getters and setters completely if you chose to make your element immutable. Your would then have a simple, clean and possibly immutable abstraction in front of your character styles system. Immutable state generally leads to fewer bugs but does require you to operate under the premise that you cannot change things willy-nilly.
Taking this a step further, a configuration file might define the different style setups you have. Again this would require prior knowledge of what styles you are setting (similar to constructing with the styles above). Give the type of style you are seeking, say "heading", you might fetch the configuration for headings which specifies a larger, bold font.
These are just some ideas off the top of my head. Without further requirements gathering and use cases it will be tough to get more specific.
Hope that helps. Good luck!
Best Answer
His #9 principal is incorrect. Objects need getters and setters to be used in most real life applications. However, they should be used as little as possible.
Displaying the properties of an objects to an end user will need getters.
Allowing an end user to edit an objects properties will need setters.
A persistence layer will need getters and setters to save the object to disk and read it again.
A builder will need setters.
A better rule would be:
Other logical entities within the domain layer should not use another entity's getters and setters if it can be practically avoided
Now, there are some work-arounds to avoid using getters and setters in the above exceptions, but they are overly complex for most situations.
Your approach to object design has its own problems, and is the other extreme. You are basically doing functional programming in an OO language without proper functional facilities. However, that is a topic for another discussion.
Please see Ben's answer, it is great: How do you avoid getters and setters?