Java包问题

Question

Ok, I'm used to structuring my projects like this

|--com.mycompany.interfaces
|         |--IFoo1(public)
|         |--IFoo2(public)
|         |--IBar1(public)
|         |--IBar2(public)
|
|--com.mycompany.foos.impl
|         |--Foo1(default) implements IFoo1
|         |--Foo2(default) implements IFoo2
|
|--com.mycompany.bars.impl
|         |--Bar1(default) implements IBar1
|         |--Bar2(default) implements IBar2
|
|--com.mycompany.services
|         |-FooBarService (public)

I have one package to organize all interfaces and then the implementations are in their own related pacakges.

The public class FooBarService has to return instances of Foo1, Foo2, etc via their interfaces IFoo1, IFoo2, etc to callers outside this project. But class FooBarService cannot access the concrete classes Foo1, Foo2, etc as they are package scoped.

What is a good way to not expose the concrete classes to outside libraries but stil keep implementations in meaningful multiple packages? or is that even possible? In .net I can just specify concrete classes as internal , where ever they are implemented and whatever their namespace is but I'm wondering if it's possible in java use such structure?

Answer 1

First do you really need all those interfaces? Unless your building a framework, library, or you forsee multiple implementations don't go around making interfaces because it seems like good design. With modern AOP and mocking libraries and IDE's that can refactor like a charm there is very little benefit in making hundreds of interfaces. Its especially (IMHO) stupid to make an interface for every Java Bean POJO just to hide special (or all) setters. I know it seems like good design but KISS is better.

Lets assume you do. You should deal with package visibility with project dependencies. That is the best way is to make multiple projects eg a multi module maven project .

something like

myproject
|  | myproject-api  // interfaces here, depends on pretty much nothing
|  |  | src
|  |  | pom.xml // or build.xml or whatever
|  | myproject-foo // implementations here, depends on myproject-api
|  |  | src
|  |  | pom.xml // or build.xml or whatever
|  | myproject-bar //implementations here, depends on myproject-api and maybe foo.
|  |  | src
|  |  | pom.xml // or build.xml or whatever
|  pom.xml  // or build.xml or whatever

The myproject build would produce three different jars (names might be different): myproject-api.jar , myproject-foo.jar , myproject-bar.jar

If your looking for a more pedantic organization you should look at this guys blog but you can't really enforce it (like you can in C#) with out separating out into separate projects.

You should also be familiar with the canonical Java SPI practice and dependency injection (now that its sort of standardized with @Inject ).

I really don't recommend you do the @his static method factory pattern for services (especially instantiating instances of an interface). If you do this what happens at best is the service locator pattern but something far worse can happen where developers will wire dependent objects in the constructors (ie aggregation construction pattern) and you end up sometimes with the evil singleton pattern. Finally static methods are always available leading to unpredictable usage and lifecycle (compared to DI).

Also if your really adventurous you can go look at OSGI .

Regardless of SPI and OSGI I highly recommend the multi-module approach.

Answer 2

I am not very happy with the separation of "every interface in one package, implementations separate by type in different packages". I would put implementations and interfaces in one package and separate further by functionality. But you certainly have your good reasons.

Apart from the "big" solution (a module system like OSGi that hides anything except published interfaces) you can only hide concrecte classes with factories and inner classes. The point is to put the factories inside the impl package and to make the concrete class an inner class of the factory. The factory obviously still is visible to the outside but as the point is to prevent programmers from using specifics of concrete implementations this is not a problem.

So:

package com.mycompany.foos.impl
public class FooFactory {
    private static class FooImpl implements IFoo1 {
        ...
    }
    public static IFoo getFoo() {
        return new FooImpl();
    }
}

If your intention is to prevent any deeper inspection of the classes than it indeed can't be done with pure Java; it is not the purpose of the visibility modifiers; and need some module system. But even then the class can be inspected by reflection.

Answer 3

You need to have a factory class which will return you the implementation instances.

Something like

if(requestedClass.equals("IFoo1"))
     return(IFoo1)new Foo1();

Answer 4

It is not possible to do that in Java. A outside librabry can create a class with the same package of your app, and it will have package visibility.