I am creating an application which uses ews-java-api to connect to an MS Exchange server. Once the connection is authenticated, the api dictates use of ExchangeService object for searching mailboxes, fetching mails and then reading its contents.

The emails are read by different classes down the line for analysis and actions depending upon email content. All these classes must need one pre-authenticated instance of ExchangeService object.

The instance of the object is obtained as -

ExchangeService service = new ExchangeService(ExchangeVersion.Exchange2010_SP2);
ExchangeCredentials credentials = new WebCredentials("emailAddress", "password");

In future there may be requirements to add more classes down the line as needed for more functionalities. All of them would be using the same instance of ExchangeService object.

My question is how should I design the sharing of ExchangeService instance among all these classes down the line? Keeping in mind that no one should inadvertently call the "close()" method on that instance, until whole of the application finishes.

On first look it might appear as a Database connection pool design sort of stuff, but its not. This application runs periodically every 5 minutes and connects to the Exchange server, does its job of analyzing unread mails (with all behavioral classes) and then ideally should close the connection.

One thought of singleton pattern also crossed my mind, but the issue of calling the "close()" method still remains.

Any design suggestion to simplify the system?

Thanks in Advance!

2 Answers 2


I would personally favor declaring an interface that you want your clients to use. Start out with just what is needed now, and expose more functionality later.

Your interface would ensure that the close() method is not available.

Your one implementation would handle the negotiation with the server and decide when/if to close the connection.

The remainder of your app gets a reference to the object either using dependency injection or your Singleton pattern. The important thing is that you are only exposing that interface.

This also gives you the option to change how you handle your connections in the future, automatically closing the connection when there is a period of inactivity, then re-establishing the connection on demand.


Do all the classes really need access to the entire object? Otherwise, this looks like a correctness problem (but not in a bad way), rather than a design problem. One approach is to consider a code contract enforced by a caller:

f(g, exchange-object) { 
   /* pre-condition/invariant */
   assert(exchange-object.open() == true);
   /* post-condition/invariant */
   assert(exchange-object.open() == true);
f ( obj-on-the-line.g, exchange-object )

More info: http://c2.com/cgi/wiki?DesignByContract

  • 1
    Thanks @john-p-feltz for sharing your thoughts and more so for your time in going through my question. Well, I am not familiar with the DbC concepts and its usage in Java, and I am avidly following up the link you have provided to see if that helps. But for your question, yes all those classes down the line need to access the entire object, as it has many many methods and we are not sure which class will need what method. Also, there is a 'close()' method in the service object, but no such method as isOpen() to check if the object is still active. Will be back on DbC, Thanks!
    – andromeda
    Sep 6, 2015 at 9:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.