Example 2 is quite bad for testing... and I don't mean that you can't test the internals. You also can't replace your XmlReader
object by a mock object as you have no object at all.
Example 1 is needlessly hard to use. What about
XmlReader reader = new XmlReader(url);
Document result = reader.getDocument();
which is not any harder to use than your static method.
Things like opening the URL, reading XML, converting bytes to strings, parsing, closing sockets, and whatever, are uninteresting. Creating an object and using it is important.
So IMHO the proper OO Design is to make just the two things public (unless you really need the intermediate steps for some reason). Static is evil.
I don't agree with either of the two proposals.
Constants should be in their pertinent classes, not in an all-constant class in either of the two forms proposed.
There shouldn't be constants-only classes/interfaces.
A class CreditCard
(not an internal class) should exist. This class/interface has methods relative to credits cards as well as the constants UI_EXPIRY_MONTH
and UI_ACCOUNT_ID
.
There should exist a class/interface BankAccount
(not an internal class). This class/interface has methods relative to bank accounts as well as constant UI_ACCOUNT_ID
.
For example in the Java API every class/interface has its constants. They are not in a Constants class/interface with hundreds of constants, either grouped into inner classes or not.
For example, these constants pertinent to result sets are in the interface ResultSet
:
static int CLOSE_CURSORS_AT_COMMIT
static int CONCUR_READ_ONLY
static int CONCUR_UPDATABLE
static int FETCH_FORWARD
static int FETCH_REVERSE
static int FETCH_UNKNOWN
static int HOLD_CURSORS_OVER_COMMIT
static int TYPE_FORWARD_ONLY
static int TYPE_SCROLL_INSENSITIVE
static int TYPE_SCROLL_SENSITIVE
This interface has method signatures relative to result sets, and implementing classes implement that behavior. They are not mere constant-holders.
These constants pertinent to UI actions are in the interface javax.swing.Action
:
static String ACCELERATOR_KEY
static String ACTION_COMMAND_KEY
static String DEFAULT
static String LONG_DESCRIPTION
static String MNEMONIC_KEY
static String NAME
static String SHORT_DESCRIPTION
static String SMALL_ICON
Implementing classes have behavior relative to UI actions, they are not mere constant holders.
I know at least one "constants" interface (SwingConstants
) with no methods but it doesn't have hundreds of constants, just a few, and they are all related to directions and positions of UI elements:
static int BOTTOM
static int CENTER
static int EAST
static int HORIZONTAL
static int LEADING
static int LEFT
static int NEXT
static int NORTH
static int NORTH_EAST
static int NORTH_WEST
static int PREVIOUS
static int RIGHT
static int SOUTH
static int SOUTH_EAST
static int SOUTH_WEST
static int TOP
static int TRAILING
static int VERTICAL
static int WEST
I think constants only classes are not good OO design.
Best Answer
Taken from https://stackoverflow.com/questions/14028198/jpa-why-the-annotations-are-applied-on-getter-or-field, if you apply the annotation to the field, the jpa provider directly sets the field. If you annotate the getter, the JPA provider uses the accessor methods.
See Chapter 2.3.1 of the specification here.
I prefer field access for a couple of reasons:
- you do not need to provide getters and setters for all properties, so this actually enhances encapsulation.
- i prefer to have the information grouped at the beginning of a class on the fields because I thinks it is more readable