引子

最近看《Java Application Architecture-Modularity Patterns with Examples Using OSGi-中文译名Java应用架构设计》时，在物理模块的封装设计方面深受启发。市面上很多书都是介绍类的封装、访问性控制、逻辑设计，但是关于物理模块的设计的书并不多见，这本书是这方面的好书，有Bob大叔推荐作序。同时此书推荐的一本老书《Large-Scale C++ Software Design》也是这方面的经典好书。就像这本书所说的缺乏物理设计的逻辑设计并不会带来预期的影响，深有同感。

问题描述

讨论一个和参考资料[1]中3.4节、[2]、[3]中描述的问题相同的简化问题。根据面向接口编程的理念，提供服务的模块只暴露服务接口，隐藏实现。客户端模块以接口访问服务端模块的服务。客户端模块中不能出现任何具体实现类的引用耦合。这样便于以后改变服务端模块实现的同时不影响客户端模块。我们希望具体实现类对客户端模块不可见。这样在提供服务端模块时强制以接口公开服务。

解决方法

[1]中采用Spring框架注入实现类，[3]中描述了采用ServiceLoader和META-INF注入实现类。以下以[2]中类似的代码为例介绍Java的方法，此处没有采用框架，仅仅是用了一个简单的工厂控制实现类的注入。并和.NET的解决方法对比。这里采用参考资料[1]中的模块定义，Java定义jar文件为物理模块单元，.NET定义程序集dll文件为物理模块单元，这也是我们平时常用引用第三方类库的方法。

Java的解决方法

服务接口

package org.p2.helloworld;

public interface HelloService {  
void sayHello(String name);  
}

实现类

package org.p2.helloworld.impl;

import org.p2.helloworld.HelloService;

public class HelloServiceImpl implements HelloService {
public void sayHello(String name){
    System.out.println("Hello," + name);
}
}

简单的工厂控制实现

package org.p2.helloworld;

import org.p2.helloworld.impl.HelloServiceImpl;

public class HelloFactory {
    public static HelloService getHelloService() {
        return new HelloServiceImpl();
    }
}

服务模块单元provider.jar包含以上几个包，客户端client.jar内容如下。

package org.p1.helloworld.main

import org.p2.helloworld.*;

public class Main {
public static void main(String[] args) {
    HelloService helloService = HelloFactory.getHelloService();
    helloService.sayHello("World"); 
}
}

以上实现由于将接口和实现类放在了不同的包中，所以实现类可见性必须为public。如果将实现类和接口放在同一个包中，则实现类可见性可设置为仅包可见。实现类代码如下，其他类同上，可实现provider.jar仅向外暴露接口。

class HelloServiceImpl implements HelloService {
public void sayHello(String name){
    System.out.println("Hello," + name);
}
}

.NET解决方案讨论

服务接口

namespace Provider
{
    public interface HelloService
    {
        void SayHello(string name);
    }
}

实现

namespace Provider.Impl
{
    internal class HelloServiceImpl : HelloService
    {
        public void SayHello(string name)
        {
            Console.WriteLine("Hello," + name);
        }
    }
}

工厂类

using Provider.Impl;
namespace Provider
{
    public class HelloServiceFactory
    {
        public static HelloService GetHelloService()
        {
            return new HelloServiceImpl();
        }
    }
}

以上为服务模块单元provider.dll包含内容，.NET下可实现将实现类和接口放在不同命名空间下，同时向外仅暴露接口。

分析讨论

以上将HelloService接口和实现类HelloServiceImpl放在了同一个物理provider.jar下的两个包下，以provider.jar类库形式提供给客户端。无论是采用[1]中的Spring框架注入实现类，还是[3]中的方法注入实现类，如果将实现类和接口放在不同包中，都必须将HelloServiceImpl的包可见性设置为public。这样导致了一旦客户端模块引用了服务端模块并导入包，则可直接实例化实现类。这就是参考资料里所说的Java没有提供将包或类定义为模块作用域的方法，导致一个模块中的类总是能够访问另一个模块的实现细节，这也OSGi这样的框架致力解决的问题。如果将实现类和接口放在一个包中则可以向外仅暴露接口，但同一物理模块jar下的其他包无法使用实现类。
对比.NET下的解决方法，.NET下可以将实现类设置为internal，物理模块内可见，对引用此模块的客户端程序不可见。而Java的包可见性有逻辑方面和物理设计方面的限制，并不是很纯粹。因此java的包和.NET的命名空间有很大不同。个人猜测这可能和跨平台有关，毕竟物理模块和具体平台有关。结合实际的应用情况，确实需要物理方面的可见性控制，这样才能提供更好的封装性。物理模块的组织设计及良好的封装性确实是这本书给我最大的启示。