Data Retrieval Patterns: Method Access Pattern

While data is data, there are times when some minor code is required as part of the retrieval. For clarity's sake this code should use the same name as the data it serves, and this name should be a noun (i.e. Count, dayOfWeek, style). Methods requiring business logic should use names that are verbs (i.e. readLastCount or calculateMean).

class MyObject
  {
    private int integer;
    public int integer() { return integer; }
    public int integer( int newValue)
      { return integer = newValue; }
  }

 

Strengths of the Method Access Pattern

1. Can use the same name as the data – providing a clear relationship between the two.
2. 2.The data name has a minimal pollution (braces at the end).
3. 3.Allows for lazy loading and data caching.
4. 4.Can be used to protect data integrity, by restricting access to the setter.

Weaknesses of the Method Access Pattern

1. 1.Changing data usage from the Public Data Access Pattern requires a subsequent change to clients using these classes. Not entirely a bad thing – I use this as an opportunity to review the usage.
2. 2.It's a little too simple to abuse the data-only concept and add that 'little piece' of business logic, rather than creating a new verb method for the process.

Uses for the Method Access Pattern

1. Lazy Loading: where the data is retrieved from a secondary source (typically a database or properties file) the first time it's used.
2. Context specific data. The retrieval method may be used as a facade for data kept in the user session or thread-specific cache.
3. Minor data protection can be gained by not publishing a setter method – or making it package private so that it can only be used by specialist methods that can confirm access.

String dayOfWeek() // Lazy Loading example
  {
    if (System.currentTimeInMillis() > endOfDay)
      dayOfWeek = getDayOfWeek();
    return dayOfWeek;
  }

Integer count() // Context specific data example
  {
    return session.get().data.get( “count”);
  }

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.

Data Retrieval Patterns: The JavaBean Pattern

The JavaBean is the standard pattern for creating plug-and-play Java components for external or disassociated infrastructures. All data is private and retrieved by getters - named with get followed by the capitalised field name. A getter has no parameters. Fields can be set by the constructor or with a setter - named with set followed by the capitalised field name.

class MyJavaBean
  {
    private int integer;
    public int getInteger()
      { return integer; }
    public void setInteger( int integer)
      { this.integer = integer; }
  }

 

JavaBean's Strengths

1. Provides a consistent interface for factories and other component based systems (such as plug-and-play GUI components). BSF?
2. A well known pattern with strong IDE support.
3. Requires data to be private, accessed only by getter and setter methods.
4. Internals can be changed without affecting users of the bean. Local data can be lazy-loaded from a properties file, for example.

JavaBean's Weaknesses

1. As all fields with public access require getters and setters, JavaBean means significant code bloat.
2. No differentiation between simple local data access and more complex/time consuming data retrieval.
3. Points of usage are less readable with the inclusion of get and () to the field name.
4. Private data isn't actually protected, since setters need to be public to be used.

JavaBean's Uses

1. Where JavaBeans were meant to be used – as plug-and-play components in a separate infrastructure;
2. and where they aren't – wherever bureaucracy dictates when working for enterprise clients. Sigh.
3. Where you have a framework (such as Groovy) that make JavaBeans as easy to use and as concise as public data. Groovey, like Perl, triggers a getter or setter method call when you attempt to reference the data directly. Unlike Perl, the triggering is not optional.

Data Retrieval Patterns

Current Java practice has us using the JavaBean pattern for all data storage and retrieval. Most enterprise projects are insisting on it, a self-defeating practice when you think about it. Why restrict ourselves to one pattern when others can serve better in different situations? To help open up the options I've compiled a list of available data access patterns – in later articles I'll document my perceptions on the strengths and weaknesses of each one.

The JavaBean Pattern

Our favourite tall poppy – JavaBean is the standard pattern for creating plug-and-play components for external or disassociated infrastructures. All data is private and accessed by getter/setter methods, using a well-known naming pattern.

Method Access Pattern

Like a JavaBean, this pattern keeps data private and uses methods to retrieve and set. Unlike a JavaBean the method name is free-format – although it commonly has the same name as the data it refers to.

Public Data Access Pattern

If you're working in C, this pattern is all you've got. Public Data Access is also a common form for C++, but making data public has gone completely out of vogue for Java.

The Data Transfer Object (DTO) Pattern

A DTO can follow any of the above access patterns. It extends said base pattern to make the object purely data (zero logic), and loads it for transfer between other objects and services. DTO is the only pattern that truly protects the core data from harm since only copies are passed around.

What? When? Why?

Personally, I prefer to use the Public Data Access Pattern wherever possible. It's simple, clear and concise, and I know that I am accessing data without any surprises. If the data needs a little work, I use the Method Access Pattern, which looks almost the same but with braces at the end of the data name. I'm basically using the second pattern as a flagging method – it lets me know when reading code that there is more to the information than simple data retrieval. Using a data retrieval pattern in this way is lazy loading, but it does give me an indication if data from an external source requires work. For more complex business logic I would use a method name reflecting the work being done, not just the data name. I don't mind that a Public Data Access Pattern becomes a Method Access Pattern after class release, as the failures in client code are simple to change and remind me to to review those changes that the effects of less simple data access will cause. This review process is far more important to me at this level than the convenience of plug-and-play changes. The other two patterns I only use when I am forced to. JavaBean Pattern needs to be used when it's required by external libraries or infrastructures, and the DTO Pattern is a refuge for the paranoid – most enterprise level organisations, for example. DTO allows you to completely isolate the tiers by having specific classes that are only used to communicate across a single tier interface. This isolation also allows you to limit changes to data, but all at the cost of having to copy data regularly. Having said that, it is great for amalgamating or extracting data so that a module is provided with the data it needs and no more.