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”);
  }