Personal Opinion: Designing and Coding with Interfaces The Spring reference documentation and many articles on the web recommend designing and coding with interfaces. Spring supports both interface-based and class-based beans. You might have noticed in Time Expression's class design that I have not used Java interfaces. This is related to my philosophy on when and where to use interfaces. Let me start out by saying that I like programming with Java interfaces a lot! However, similar to the way many people jumped on the EJB bandwagon a few years ago, I see people jumping on the interface bandwagon recently. So, allow me to share my thoughts on this matter; you may agree or disagree with them. I would like to begin by telling you a little story on the topic of designing and coding with interfaces. I have been using interfaces since 1996 and love the concept behind them. In 1997, I developed a 100% pure Java-based backup software named BackOnline (http://visualpatterns.com/backonline/). This product was mentioned in several well-known trade journals and won a Best Client award at JavaOne; it was even nominated by Scott McNealy (CEO, Sun Microsystems) for a Computerworld-Smithsonian award. BackOnline is a client-server product; the server is a multithreaded and multiuser server that essentially receives the files and stores them using an implementation class for an interface named DataStore. The DataStore interface has FTP-like methods, such as get, put, open, close, and so on; these, had to be implemented by concrete classes. The BackOnline software (which is no longer being sold) came prepackaged with two default DataStore implementation classes, DataStoreFileSystem and DataStoreJDBC (the fully qualified implementation class names were specified in a configuration file and dynamically loaded at runtime). DataStoreFileSystem essentially used the java.io package to store the files using the local file system. DataStoreJDBC used JDBC to store the file contents as Binary Large Objects (BLOBs) in a relational database. I provided Javadoc and additional technical documentation for the DataStore interface, so Internet Service Providers (ISPs) and products vendors who signed an OEM (original equipment manufacturer) with my company could write their own custom implementations, if necessary. For example, an ISP might have wanted to take advantage of the native operating system's features, such as extended file permissions. For the BackOnline example I just went through, using interfaces was an obvious choice. Also, many times I find that interfaces work well for lower-level APIs, such as the one I described for BackOnline or ones you find in frameworks such as the JDK or the Spring Framework (for example, java.util.Collections or java.sql.Connection). Furthermore, interfaces are great, if you think the underlying implementation can change (such as logging, authentication service, and OS specific functionality). Of course, with remote technologies (EJB, for example), you have no choice but to use interfaces. For business applications, more times than not, especially on smaller projects, I have found that you need only one implementation of domain (business) objects or service objects (such as the TimesheetManager class for Time Expression). Furthermore, it doesn't make sense to have interfaces for domain objects (such as Timesheet.java, for example). Creating one interface file for each implementation class amounts to unnecessary overhead, in my opinion. For large projects, this can amount to lots of extra .java (and .class) files without potentially adding much value. On the flip side, there are times when using interfaces makes sense. For example, in Chapter 2, we discussed multiple user types (roles) for the Time Expression application, such as Employee, Manager, and Executive. These could easily be created as concrete classes that implement an interface named Person or Role. On the other hand, given the common behavior in these objects, an abstract class would also make a lot of sense because the common methods could be pulled up into a super (parent) class (called Person, for example). In summary, given the right opportunity, you should use interfacesbut do not use them because it has been preached in some book or article as the right thing to do. Furthermore, you should not feel at fault for not using interfaces for each and every concrete class you write. Focus more on having a sound design for your applicationfor example, clean separation of layers, good database design, easy-to-follow code, appropriate use of architecture/design patterns, and so on. I hope I do not sound dismissive about interfaces because that is certainly not my intention; my point is to use everything in moderation and appropriately. |
