模块的封装性分析-读书笔记
引子
最近看《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的命名空间有很大不同。个人猜测这可能和跨平台有关，毕竟物理模块和具体平台有关。结合实际的应用情况，确实需要物理方面的可见性控制，这样才能提供更好的封装性。物理模块的组织设计及良好的封装性确实是这本书给我最大的启示。
