Welcome!

Java Authors: Elizabeth White, Sematext Blog , Liz McMillan, Yeshim Deniz, Torben Andersen

Related Topics: Java

Java: Article

Evolving Functionality

Evolving Functionality

C++ brought into vogue the concept of interfaces, abstractness, and implementations. Java went a step further and formalized them with proper keywords for each of the concepts. There are a substantial number of patterns in which interfaces, abstract classes, and classes can be combined for various purposes. You only have to look at the book Design Patterns, by Erich Gamma et al (Addison-Wesley), to realize the importance of recognizing these constructs.

Constructing a software program that you expect to have a long life is an attempt to evolve its functionality over time, without abandoning older behavior for backward compatibility. This is a lot more essential when you're designing libraries and frameworks. The newer libraries should work with older systems that were designed for the older releases of a library. Here are some concrete examples of why this is important and how to accomplish this in situations where every programmer is encouraged to adapt the scheme owing to its simplicity.

What Is Evolving Functionality?
To understand what evolving functionality is, let's walk through the design of a very simple class in Java. Here's the class:

class LogFacility
{
public log(final String message)
{
// implementation
}
}
LogFacility provides a mechanism to log messages. Everyone on the team would use this functionality as follows:
LogFacility lf = new LogFacility()
lf.log("log this message for me");

As it's simple and useful, it's hard to argue against it. Now I take this utility and ship it to two different teams. One team wants to log to a file and the other to stdout. I improvised and came up with StdoutLogFacility and FileLogFacility, and suggested that the programmer use the appropriate logging facility as follows:

StdoutLogFacility lf = new
StdoutLogFacility();
lf.log("log this message for me");

FileLogFacility lf = new
FileLogFacility();
lf.log("log this message for me");
You'd quickly realize that irrespective of what log facility is constructed, it gets used the same way. This is a cue to design an interface for the usage of the log facility as follows:
public interface ILogFacility { public
log(final String message); }
StdoutLogFacility and FileLogFacility would implement this interface. In this scenario the programmer would do the following:
ILogFacility lf = new
StdoutLogFacility();
lf.log("log this message for me");
ILogFacility lf = new FileLogFacility();
lf.log("log this message for me");
As you can see, irrespective of the nature of the construction, an object of type ILogFacility is used the same way.

This brings us to an important observation in OO programming - construction is different from usage. In other words, the construction interface of an object is different from its usage contract/interface. We can delegate the construction of the ILogFacility to any number of mechanisms, but the usage remains the same. Using this property let's investigate a method where the programmer doesn't have to do the following:

ILogFacility lf = new FileLogFacility();
This line of code is hard-coding the construction of an implementation. In doing so we create a compile-time dependency with the implementation. And we can't substitute StdoutLogFacility for FileLogFacility because that dependency is necessitated by the compiling.

So, in a general sense, you can't really vary the implementation of a given interface at runtime if we use the "new" option for construction. Also you'll have to know the name of the implementation class, which may not even exist at compile time. What to do? The solution lies in understanding the factory pattern. Here's an example:

class ObjectFactory
{
public static Object create(final String
objectName, Object args )
throws CreationException;
}

You can attempt the following:

ILogFacility lf = ObjectFactory.create
(ILogFacility.NAME, null);
if.log("log my message"):
As a programmer you've delegated the construction of an interface named ILogFacility.NAME to a factory. This factory could look up a system-wide properties file for a class that's responsible for this interface and load it at runtime. Let's look at one such properties-file entry:
Objects.loggingObject.className=com.your_
company.StdoutLogFacility;

Assuming ILogFacility.NAME is "Objects.loggingObject", it is not difficult for the factory to do the following:

public static Object create(final String
objectName, Object args )
{
Properties systemWidePropertiesFile;
String className = systemWide
PropertiesFile.getValue
(objectName);
Object o = Class.forName(className);
return o;
}

Using this mechanism you can improvise StdoutLogFacility gradually without impacting its users. For example, you've improved logging but don't want to replace the older implementation until it's been field tested. You can cut and paste the source code of StdoutLogFacility to another class called StdoutLogFacility1 and replace your properties file as follows:

Objects.loggingObject.className=com.your_company.Stdout
LogFacility1
This way the older clients can continue to use the older implementation while you migrate to the new one. You can continue to evolve this functionality while incrementing the numbers. The same facility can provide a radically different implementation if necessary. For example:
Objects.loggingObject.className=com.your_company.Socket
LogFacility

logs all your messages to a socket.

This discussion isn't limited to logging; any of your core modules can follow the same pattern, which allows them a path for evolution while maintaining backward compatibility.

To summarize the points so far, we've learned the following:

  1. Construction is different from usage
  2. Use interfaces, not implementations for, key areas of functionality
  3. Use factories to construct implementations, at runtime
  4. You can use properties files to associate implementations with their interface names
  5. Having an interface.NAME as a standard allows a programmer a simple reference to instantiate an interface

Usage Pattern for an Evolving Implementation
Let's reexamine how we can utilize an interface. The emphasis here is that you get your implementations via a global factory instead of "new"ing them explicitly. This allows for runtime variations of the implementation. For example:

MyInterface i = (MyInterface)ObjectFactory.create
(MyInterface.NAME,null);
i.useMethod();
Let's examine the MyInterface.NAME:
interface MyInterface
{
public static final String NAME =
"MyInterface";
                                                                                                                        . .. other public method signatures
}
Using a synonym like "interface.NAME" instead of a literal string, we reduce the risk of getting the name wrong. If every interface has the same public synonym, it's just that much easier for the programmer to instantiate an implementation for it.

Interface Definition for an Application-Wide Factory Service
Now we'll discuss the factory object in more detail and define some desirable characteristics. The idea is we'll use this factory object to create all our implementations for the desired interfaces. By that I mean to choose interfaces that are going to be instantiated by factories. Once decided, these interfaces can be instantiated by the same global object factory. The aim of this section is to define a simple interface for such an application-wide factory service.

Static vs Nonstatic Method
The method "create" of the ObjectFactory is declared static and public. It's public for obvious reasons and static so the programmer can invoke it without an object reference. For example:

ObjectFactory.create(..)
instead of
ObjectFactory of = new ObjectFactory();
of.create(..)
There are some exceptions to this rule for example, if you want to evolve the functionality of the factory itself. The method also throws a suitable exception indicating any failures in the construction process. There are some interesting consequences to the nature of this exception, which I'll cover at the end of this article.

getObject vs createObject
At this point I'd like to change the name of the "create" method of the ObjectFactory to "getObject". create() implies that an object is being created every time the method is called. This may not be true for a number of reasons. Certain objects you may want to create only once, others with each request, and some as part of a pool. Because of this, getObject() suits the semantics of this intention more accurately.

Passing Arguments
Certain objects require construction arguments. How do you pass them? The arguments are passed via the second parameter to the function call. This could be any object, including a collection of objects that get passed to the constructor of the target object. This can get sophisticated with EJBs when the constructors are invoked through reflection and the correct constructor called. But for simplicity the classes can have default constructors, with a well-known "init()" method that accepts the passed parameter as an argument.

The implication is that programmers not only need to know the interface name of the object that they want to instantiate, but also the nature of its arguments. This I call the construction interface of the object. This needs to be published and adhered to by all the implementations. And it's the responsibility of the programmer to pass the correct set of arguments. Otherwise an exception is thrown by the generic factory.

Caching Strategy
Once you start using this facility, it won't be long before you start asking, "How can I limit the number of object occurrences of a specific class?" For example, singleton. To facilitate this a factory can use multiple strategies to cache object instances. The factory can save the instantiated objects in a hashtable keyed by their interface names. So, when a repeated request comes in for an interface, the factory can return the previously constructed object. But how does the factory know to cache an object? You can specify in the properties file that a certain interface needs to be cached, which is how it's done in EJBs at deployment time. Specifying the number of object instances at deployment time is more generic. But for systems of medium complexity, you may want to define an ISingleThreaded interface and implement that interface to force multiple instances of the object. This avoids the errors that might occur due to lack of knowledge at deployment time, or you could provide both facilities.

Name-Based Caching May Not Be Sufficient
Interface name-based caching sounds good until you consider the fact that a given implementation can support multiple interfaces. In this case you'll have two such objects cached when one would have been sufficient and even wrong at times. I believe the right approach is to use caching based on class names instead.

Pooling Support
I think a factory shouldn't provide pooling; it should be implemented on top of factory. Otherwise the simple factory interface also needs to deal with synchronization and return to pool semantics.

Support for Object Filters
When a factory instantiates an object, it can also pass the object to an object filter and return the output of the filter instead. This allows for the chaining of objects, which is similar to the servlet chaining popular in Web-based systems. It's fairly trivial to do, but adds a great value to the overall functionality. For example, using such a functionality you can convert an incoming result set to a comma-separated string or sum the values into a single entity. All this can be done without recompiling the target code. This properties file demonstrates how this can be accomplished:

Objects.employee.className=com.comp.Employee
Objects.employee.filterName=SumSalary
Objects.SumSalary.className=com.comp.Sum-
EmployeeSal
The Default Object
When you're specifying target implementation objects via a properties file, it's possible that anything might go wrong in the construction process, resulting in an exception. In this case you'd like a default implementation to be available. For example:
MyInterface myObj = null;
try
{
myObj = ObjectFactory.getObject
(MyInterface.NAME,null)
}
catch( FactoryException x)
{
x.printStackTrace():
myObj = new MyDefaultObject;
}
Doing this everywhere discourages the programmer from using the facility. The following code alleviates the problem:
MyInterface myObj = ObjectFactory.get
Object (MyInterface.NAME, args, new
MyDefaultObject();
This method doesn't throw any exceptions, instead it returns the MyDefaultObject on any kind of internal exception, ensuring the default functionality of the application.

A Well-Defined Factory Interface to
Fulfill the Factory Service

With that discussion we're able to define an interface for our factory object:

interface IFactory
{
Object getObject(final String
interfaceName, Object args) throws
FactoryException;
Object getObject(final String
interfaceName, Object args, Object
defaultObject);
}
An interface definition tells you only the contract of the factory and doesn't specify its intended behavior. For that reason I'm summarizing here the desired characteristics of a typical factory implementation:
  1. Provides a static façade for easier calling semantics
  2. Uses getObject, not createObject, semantics
  3. Requires a default constructor for the objects to be constructed
  4. Arguments are passed to the init method for initialization
  5. Caching is based on the class name of the object
  6. Caching is also based on the IsingleThreaded tagging interface
  7. Supports object filters
  8. Supports default objects
  9. Uses an application-wide configuration interface for class definitions
ObjectFactory Implementation
Although we've defined an interface for a factory, we need a convenient set of static methods that would make use of the above interface internally. Such a facility provides the best of both worlds. On one side it obviates the need to instantiate a factory interface and on the other it adheres to a nonstatic factory interface definition. Here's one such implementation. Obviously many variations are possible, but the idea is to give the programmer the simplest way to accomplish the characteristics stated above (see Listing 1).

Role of an Application-Wide Configuration Service
So far all the object definitions are stored in a properties file. It's not that difficult for the factory implementation to instantiate a properties object and read in the properties file. What if in the future you'd like to move the entries from a properties file to a database, an LDAP, or an XML configuration file?

For this reason the factory implementation accesses the object definitions through a common configuration interface.

Interface Iconfig
{
public String getValue(final String key)
throws ConfigException;
public String getValue(final String key,
String defaultValue );
}
Again, for programmer simplicity, this interface is exposed through a static Config class as follows:
Class Config
{
static public String getValue(final String
key) throws ConfigException;
static public String getValue(final String
key, String defaultValue );
}
With this you'd be able to do:
String value = Config.getValue("key","default value");
Why go to such lengths when properties is such a simple interface; why not use it? Frequently you would want the IConfig implementation to exhibit the following characteristics:
  1. Case-insensitive keys so you don't have to constantly remember capitalizations
  2. Ability to include multiple-properties file inside the main configuration file
  3. Ability to provide substitutions based on keys that were defined at the beginning of the properties file
All these can be provided gradually by the evolving implementations of IConfig. In this case, one of the facilities of the framework evolves using the same principles.

Evolving an Interface
So far I've discussed where the implementations are changing. What if the interface itself has migrated to the next level? Although less common, this will happen eventually, even in the best of designed interfaces. For instance, with the logging interface defined above, I'd like to extend the interface by providing a logging mechanism for exceptions. One approach is to extend the base interface instead of modifying it:

interface ILogFacility_1 extends
ILogFacility
{
public void log(Throwable t);
}
If there's an implementation that supports the ILogFacility_1 interface, it automatically supports the ILogInterface and hence can be used in a backward-compatible manner. On the other hand, if an older implementation that supports only ILogInterface is used in a newer environment that's expecting ILogFacility_1, there are two alternatives:
  1. Let the system throw a class-cast exception and correct the mistake
  2. Write the client code in such a way that this can be handled gracefully:
Object logFacility =
ObjectFactory.getObject
(ILogFacility.NAME,null,new MyLogFacility);
if (logFacility instanceof ILogFacility_1)
{
(ILogFacility_1)logFacility.log(x);
}
else (logFacility instanceof ILogFacility)
{
(ILogFacility)logFacility.log(x.getMessage());
}
Request-Based Factories
As I've mentioned, factory plays a central role in adapting this evolution-based approach to programming. The factory I've discussed so far is primarily creation-based because it instantiates the necessary class and calls the well-known method to initialize it. A more sophisticated approach would be a request-based factory in which the input symbolic name refers to a request rather than a class name. You can simulate the creation-based factory from a request-based factory. For example:
Object o = RequestBasedFactory.getObject
("GET_OBJECT", null):
The request-based factory locates a class name identified by "GET_OBJECT" in a properties file. Instead of calling the init method to initialize the object, the request factory calls the "executeRequest" method with the parameters. Whatever the executeRequest method returns is then returned to the caller as the return object.

When the executeRequest method returns the self-reference, we basically have the RequestFactory behaving like a creation factory. RequestFactory has broader applications than a simple CreationFactory. For example:

RequestBasedFactory.getObject("GET_EMPLOYEE_
ROWS","employee_name=John Doe")
invokes a database request executor identified by "GET_EMPLOYEE_ROWS" and returns the result set back to the caller.

Interfaces and Exceptions
I'd like to cover one more detail since we're dealing extensively with interfaces, particularly such generic interfaces as the factory interface I've shown here. When a factory tries to load a class at runtime and fails, all the client sees is the factory exception. If you're not careful, the root cause of the exception is never known. To deal with this scenario, interfaces should define exceptions that can carry with them a child exception, and the child exception can carry another child exception. This way the root exceptions are propagated all the way to the top. When the final exception is printed, you'll see a complete hierarchy of exceptions, which is extremely good for debugging purposes. I call this the principle of Kangaroo exceptions, and it's necessary for interface-based programming. This is because interfaces are like firewalls and compile-time exceptions can't propagate through them without help. This concept of Kangaroo exceptions hides the root exception in terms of the interface-specific exception.

Conclusion
Using a simple application-level factory service, it's possible to effectively employ interfaces and implementations to write code that provides backward compatibility. Even when you don't need this compatibility, it enables you to try new bug fixes without affecting the old behavior. This provides developers with some assurance that they won't undo everything they've done before.

More Stories By Satya Komatenini

Satya Komatineni is Chief Technology Officer of INDENT, Inc and the author of a Java based RAD framework for developing J2EE based HTML applications. The product has the distinction of supporting multiple html transformations (XSL,JSP, proprietary templates) while utilizing the same data abstraction to interact with EJBs, relational databases and ERP systems. After earning an M.S. in Electrical Engineering from Indian Institute of Technology, New Delhi, worked with LAN based collaboration technologies, C++ patterns and frameworks, Java and Web based frameworks in a distributed environment.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


@ThingsExpo Stories
The BPM world is going through some evolution or changes where traditional business process management solutions really have nowhere to go in terms of development of the road map. In this demo at 15th Cloud Expo, Kyle Hansen, Director of Professional Services at AgilePoint, shows AgilePoint’s unique approach to dealing with this market circumstance by developing a rapid application composition or development framework.

ARMONK, N.Y., Nov. 20, 2014 /PRNewswire/ --  IBM (NYSE: IBM) today announced that it is bringing a greater level of control, security and flexibility to cloud-based application development and delivery with a single-tenant version of Bluemix, IBM's platform-as-a-service. The new platform enables developers to build ap...

"BSQUARE is in the business of selling software solutions for smart connected devices. It's obvious that IoT has moved from being a technology to being a fundamental part of business, and in the last 18 months people have said let's figure out how to do it and let's put some focus on it, " explained Dave Wagstaff, VP & Chief Architect, at BSQUARE Corporation, in this SYS-CON.tv interview at @ThingsExpo, held Nov 4-6, 2014, at the Santa Clara Convention Center in Santa Clara, CA.
The major cloud platforms defy a simple, side-by-side analysis. Each of the major IaaS public-cloud platforms offers their own unique strengths and functionality. Options for on-site private cloud are diverse as well, and must be designed and deployed while taking existing legacy architecture and infrastructure into account. Then the reality is that most enterprises are embarking on a hybrid cloud strategy and programs. In this Power Panel at 15th Cloud Expo (http://www.CloudComputingExpo.com), moderated by Ashar Baig, Research Director, Cloud, at Gigaom Research, Nate Gordon, Director of T...
The Internet of Things is not new. Historically, smart businesses have used its basic concept of leveraging data to drive better decision making and have capitalized on those insights to realize additional revenue opportunities. So, what has changed to make the Internet of Things one of the hottest topics in tech? In his session at @ThingsExpo, Chris Gray, Director, Embedded and Internet of Things, discussed the underlying factors that are driving the economics of intelligent systems. Discover how hardware commoditization, the ubiquitous nature of connectivity, and the emergence of Big Data a...
SYS-CON Events announced today that Windstream, a leading provider of advanced network and cloud communications, has been named “Silver Sponsor” of SYS-CON's 16th International Cloud Expo®, which will take place on June 9–11, 2015, at the Javits Center in New York, NY. Windstream (Nasdaq: WIN), a FORTUNE 500 and S&P 500 company, is a leading provider of advanced network communications, including cloud computing and managed services, to businesses nationwide. The company also offers broadband, phone and digital TV services to consumers primarily in rural areas.
“In the past year we've seen a lot of stabilization of WebRTC. You can now use it in production with a far greater degree of certainty. A lot of the real developments in the past year have been in things like the data channel, which will enable a whole new type of application," explained Peter Dunkley, Technical Director at Acision, in this SYS-CON.tv interview at @ThingsExpo, held Nov 4–6, 2014, at the Santa Clara Convention Center in Santa Clara, CA.
SYS-CON Events announced today that IDenticard will exhibit at SYS-CON's 16th International Cloud Expo®, which will take place on June 9-11, 2015, at the Javits Center in New York City, NY. IDenticard™ is the security division of Brady Corp (NYSE: BRC), a $1.5 billion manufacturer of identification products. We have small-company values with the strength and stability of a major corporation. IDenticard offers local sales, support and service to our customers across the United States and Canada. Our partner network encompasses some 300 of the world's leading systems integrators and security s...
DevOps Summit 2015 New York, co-located with the 16th International Cloud Expo - to be held June 9-11, 2015, at the Javits Center in New York City, NY - announces that it is now accepting Keynote Proposals. The widespread success of cloud computing is driving the DevOps revolution in enterprise IT. Now as never before, development teams must communicate and collaborate in a dynamic, 24/7/365 environment. There is no time to wait for long development cycles that produce software that is obsolete at launch. DevOps may be disruptive, but it is essential.
"People are a lot more knowledgeable about APIs now. There are two types of people who work with APIs - IT people who want to use APIs for something internal and the product managers who want to do something outside APIs for people to connect to them," explained Roberto Medrano, Executive Vice President at SOA Software, in this SYS-CON.tv interview at Cloud Expo, held Nov 4–6, 2014, at the Santa Clara Convention Center in Santa Clara, CA.
Nigeria has the largest economy in Africa, at more than US$500 billion, and ranks 23rd in the world. A recent re-evaluation of Nigeria's true economic size doubled the previous estimate, and brought it well ahead of South Africa, which is a member (unlike Nigeria) of the G20 club for political as well as economic reasons. Nigeria's economy can be said to be quite diverse from one point of view, but heavily dependent on oil and gas at the same time. Oil and natural gas account for about 15% of Nigera's overall economy, but traditionally represent more than 90% of the country's exports and as...
The Internet of Things is a misnomer. That implies that everything is on the Internet, and that simply should not be - especially for things that are blurring the line between medical devices that stimulate like a pacemaker and quantified self-sensors like a pedometer or pulse tracker. The mesh of things that we manage must be segmented into zones of trust for sensing data, transmitting data, receiving command and control administrative changes, and peer-to-peer mesh messaging. In his session at @ThingsExpo, Ryan Bagnulo, Solution Architect / Software Engineer at SOA Software, focused on desi...
"At our booth we are showing how to provide trust in the Internet of Things. Trust is where everything starts to become secure and trustworthy. Now with the scaling of the Internet of Things it becomes an interesting question – I've heard numbers from 200 billion devices next year up to a trillion in the next 10 to 15 years," explained Johannes Lintzen, Vice President of Sales at Utimaco, in this SYS-CON.tv interview at @ThingsExpo, held Nov 4–6, 2014, at the Santa Clara Convention Center in Santa Clara, CA.
"For over 25 years we have been working with a lot of enterprise customers and we have seen how companies create applications. And now that we have moved to cloud computing, mobile, social and the Internet of Things, we see that the market needs a new way of creating applications," stated Jesse Shiah, CEO, President and Co-Founder of AgilePoint Inc., in this SYS-CON.tv interview at 15th Cloud Expo, held Nov 4–6, 2014, at the Santa Clara Convention Center in Santa Clara, CA.
SYS-CON Events announced today that Gridstore™, the leader in hyper-converged infrastructure purpose-built to optimize Microsoft workloads, will exhibit at SYS-CON's 16th International Cloud Expo®, which will take place on June 9-11, 2015, at the Javits Center in New York City, NY. Gridstore™ is the leader in hyper-converged infrastructure purpose-built for Microsoft workloads and designed to accelerate applications in virtualized environments. Gridstore’s hyper-converged infrastructure is the industry’s first all flash version of HyperConverged Appliances that include both compute and storag...
Today’s enterprise is being driven by disruptive competitive and human capital requirements to provide enterprise application access through not only desktops, but also mobile devices. To retrofit existing programs across all these devices using traditional programming methods is very costly and time consuming – often prohibitively so. In his session at @ThingsExpo, Jesse Shiah, CEO, President, and Co-Founder of AgilePoint Inc., discussed how you can create applications that run on all mobile devices as well as laptops and desktops using a visual drag-and-drop application – and eForms-buildi...
We certainly live in interesting technological times. And no more interesting than the current competing IoT standards for connectivity. Various standards bodies, approaches, and ecosystems are vying for mindshare and positioning for a competitive edge. It is clear that when the dust settles, we will have new protocols, evolved protocols, that will change the way we interact with devices and infrastructure. We will also have evolved web protocols, like HTTP/2, that will be changing the very core of our infrastructures. At the same time, we have old approaches made new again like micro-services...
Code Halos - aka "digital fingerprints" - are the key organizing principle to understand a) how dumb things become smart and b) how to monetize this dynamic. In his session at @ThingsExpo, Robert Brown, AVP, Center for the Future of Work at Cognizant Technology Solutions, outlined research, analysis and recommendations from his recently published book on this phenomena on the way leading edge organizations like GE and Disney are unlocking the Internet of Things opportunity and what steps your organization should be taking to position itself for the next platform of digital competition.
The 3rd International Internet of @ThingsExpo, co-located with the 16th International Cloud Expo - to be held June 9-11, 2015, at the Javits Center in New York City, NY - announces that its Call for Papers is now open. The Internet of Things (IoT) is the biggest idea since the creation of the Worldwide Web more than 20 years ago.
As the Internet of Things unfolds, mobile and wearable devices are blurring the line between physical and digital, integrating ever more closely with our interests, our routines, our daily lives. Contextual computing and smart, sensor-equipped spaces bring the potential to walk through a world that recognizes us and responds accordingly. We become continuous transmitters and receivers of data. In his session at @ThingsExpo, Andrew Bolwell, Director of Innovation for HP's Printing and Personal Systems Group, discussed how key attributes of mobile technology – touch input, sensors, social, and ...