Service/component based application in Java

Question

I have a Java project whose architecture is quite component-oriented, and I am wondering

• if this is a common way to organize code
• which rules/patterns are used,
• if there is a name for this coding style.

Component packages

src/namespace/component1
src/namespace/component1/error
src/namespace/component1/impl
src/namespace/component1/data

src/namespace/component2
...

Each component is a bit like a service. Some launch a Thread, some open some sockets for connections, etc

Structure of component

// "Root" of the package : Interfaces + InterfaceCoordinator
src/componentx/componentx/ComponentXInterfaceCoordinator.java
src/namespace/componentx/IStartup.java
src/namespace/componentx/IinterfaceFoo.java

// Implementation of the component
src/namespace/componentx/impl/Startup.java
src/namespace/componentx/impl/Foo.java
...

// Exceptions this component can throw
src/namespace/componentx/error/SomeError.java
...

// Data (not really sure exactly what we can call data or not)
src/namespace/componentx/data/SomeConfiguration.java
src/namespace/componentx/data/SomePersistedEntity.java
src/namespace/componentx/data/SomeNonPersistedEntity.java

Application Main

public static void main(String[] args) {
  ...
  logger.info("Initialize ComponentX Component");
  ComponentXInterfaceCoordinator.getStartup().init();

  logger.info("Initialize ComponentY Component");
  ComponentYInterfaceCoordinator.getStartup().init();
  ...

ComponentX Interface Coordinator

public class ComponentXInterfaceCoordinator {

public static IStartup getStartup(){
    return Startup.getInstance();
}

Startup Interface/impl

public interface IStartup {

    public void init(); 
}

public class Startup implements IStartup{

    private static Startup instance = null;
    private Logger logger = Logger.getLogger("ComponentX");


    public static IStartup getInstance() {
        if(instance==null)
            instance = new Startup();
        return instance;
    }

    @Override
    public void init() {

        logger.debug("Initialising subcomponents: xxx");
        SubComponentXy.getStartup().init();

        logger.debug("Initializing Connection Manager Component");
        ComponentX.getInstance().addProtocol(new MobileSystemListeningProtocol());
        ComponentX.getInstance().startProtocols();
    }
}

In addition/part of the questions I asked at the beginning :

Most of the main component classed also have this getInstance() code which return the singleton instance of the class

Is getInstance() following some kind of pattern ? or anti-pattern ? Is is actually just a way to get around thet fact that static methods cannot be declared in interfaces (in java <= 1.7) ? If I start a new project in JAVA 1.8, should I go for it a different way ?

Answer 1

Component packages

As for the component packages - this approach is usually called vertical folder (directory/package) structure and is common for larger projects.

Structure of component

Naming conventions are a little bit untraditional:

• Interfaces prefixed with capital I - this is C# convention, not Java one. In Java, interface is named without I - in this case Startup, implementation then commonly StartupImpl or something more descriptive
• Error - I suspect this contains exceptions. Errors in Java are special type of Throwables, but shouldn't really be used or thrown by application itself. If these are actually exceptions, they should be named accordingly.
• Data - these are usually called DTOs - Data Trasfer Object. Sometimes VO (for Value Object) in DDD terminology. Or if it has an identity (typically if it's persisted to the DB), then maybe "entity" instead of data, I'm not sure what's in there.

Startup Interface/impl

All the components seem to be singletons (and thread unsafe). I assume that you then call methods of other services through static getInstance() method. This reduces OOP to essentially procedural programming style. This is exactly why singleton is so often considered to be anti-pattern. It has its valid use cases, but this is not one of them.

This anti-pattern stems from the need to pull all the components together, make them cooperate. In Java there's no built-in way to do this properly, that's why this style is quite common (been there too). Answer to that is Inversion of Control, and Dependency Injection in particular. Look at Spring or Guice.