Data Retrieval Patterns: Public Data Access Pattern

Public Data Access is the only way for C and common form for C++, but making data public has gone completely out of vogue for Java. I know I'm old fashioned, but this is still my favourite pattern. I like to think it is because I prefer simplicity and clarity.

class MyObject
  {
    public int integer;
  }

 

Strengths

1. Minimal overhead in usage. No additional methods required.
2. Maximum readability in usage code (providing the fields are named clearly).
3. Tight, concise class files. No code bloat for getters and setters. KISS.
4. Finally, and most importantly, clarity when retrieving data - there is a clear differentiation between basic data retrieval and data retrieval with overheads (method call).

Weaknesses

1. If data needs code before it can be retrieved (lazy loading, database access, property retrieval), it must be changed to a Method Access Pattern. This means that client code that uses the object will also need to be changed. As I've often attested, this isn't so much a problem as JavaBean supporters make out. It forces you to review the client code (always a good idea), to see how the changes could affect things. At the very least a local copy of the data should be made if retrieved by a method and used more than once.
2. Data setting can't be controlled, but that's no different to typical usage of the JavaBean Pattern or the Method Access Pattern, either. For these two patterns you can ommit setters and only allow data storage as part of a constructor. The same facility can be provided for the Public Data Access Pattern by using the final keyword.
3. The Java security model can't be used, as it's an AOP model that is called before a method is called. If your application uses implementations of the security model, use another pattern for those instances where it has value. Since this is usually only at a service interface to an external system, the use of methods will indicate the overhead of a security call - so document this accordingly.

Uses

Personally I use this pattern whenever I can, and it's only rarely that a post-design change forces me to change to a Method Access Pattern, and then only for some fields. By using methods of the same name as the data, the change becomes easy to implement in the client code, and provides the opportunity to view how the change will affect said clients.