Shashi Velur’s blog

I am a big fan of the Hibernate’s direct field access functionality. I am not sure why ”property” access is the default instead of “field”. Direct field access allows me to control the number of getters/setters that are actually needed from the DAO Client’s perspective.

I think using property access helps enforce better encapsulation of the data in the mapped/persistent classes. I have seen that most developers just use public getters and setters for all of the properties in the mapped class.

This creates problems for collections, especially. I seldom expose getters and setters for collections. I always use a combination of “addXXX(Obj)”, “removeXXX(Obj)” and “clearXXX()” (depending upon the need) instead of “get/setXXX”. This is for efficiency (as Hibernate uses a custom collection class) and better encapsulation.

The only situations where I do not use the direct field access are:

• If the DB schema data type does not directly map to the mapped attribute in Java where a translation is required. This is mostly true for Legacy Database schemas and also where custom introducing custom SQL type mapping is not an option perhaps due to inconsistent use of the same data type in legacy applications.
• If there are dependent (child) tables that have composite primary keys (which include the primary key of the parent table). In this case, for saving a new entity I would need to intercept the setter of the primary key of the parent table to set the appropriate fields in the child tables.
• If I use lazy initialization, I would use property access for the primary key. This allows us to call persistentObj.getId() without completely initializing the proxy. This is applicable only for the “Id” field.
• If there is any other need to intercept the getters/setters for whatever reasons (validation, logging, debugging, etc.). This is very unlikely.

Technorati Tags: direct field access, encapsulation, Hibernate

I am in the process of rearchitecting a fairly large legacy web application. Almost all of the classes in the old code base are public classes with the key classes containing mostly public (and sometimes static) methods. I am tasked to modularize this application for various obvious reasons in an evolutionary and progressive manner.

Java package names are used for various purposes such as:

• Namespaces for tiers (web-tier, middle-tier, EIS-tier, etc.)
• Namespaces for layers (service layer, DAO layer, etc.)
• Namespaces for the purpose of the classes (Utility classes, implementation classes, etc.)
• Namespaces based on module structure, deployment architecture, etc.

So, it is not always possible to put the implementation classes and the classes that need to access the implementation classes in the same package for any combination of the above reasons or use inheritance between them. So, the standard Java package-private and protected access specifiers might come up short.

So, one of the consequences of these restrictions in Java is to make the class public, eventhough you may not want this class accessible to every other class in that module/bundle or classpath by default (depending on whether you are talking about OSGi or non-OSGi based applications).

Sometimes, I miss the C++ “friend” Class (not the function) access specifier. However, I think the “friend” class in Java should not have access to all of the private members, instead it should have access to the “friend” or “protected” members of the other class. But, perhaps the designers of the Java language may have decided against this due to fear that the not-so-OO-developers might violate encapsulation by misusing this feature.

I have seen or heard of various approaches to solve this problem:

• Use Delegation and/or Composition
• Use “internal” package names
• JavaDoc them as “for internal use only” (org.springframework.orm.hibernate3.SessionHolder in Spring API)
• Use classloading trickery to simulate “friend” access specifier. This may not work in web applications or OSGi (due to the “modularity” or various classloading architectures))

My preferred way to do this (if I absolutely cannot put them all in the same package and make them package-private) is to use delegation or composition or a factory class (depending upon the type of situation that causes this problem).

What do you think? Are there better ways to do this?

Don’t we need a modified form of “friend” access specifier in Java?

Technorati Tags: encapsulation, friend access specifier, Java friend class