逻辑设计与物理设计

有些原则和模式可以帮助解决软件设计和架构所面临的问题，这些问题几乎都是关于逻辑设计的。 ^[4]逻辑设计是关于语言结构的，如类、操作符、方法以及包。识别类的方法、类之间的关系以及系统中包的结构都是逻辑设计问题。

毫无意外，因为大多数的原则和模式强调的都是逻辑设计，所以开发人员将大多数时间都用来处理与逻辑设计相关的问题。在设计类及其方法的时候，你是在定义系统的逻辑设计。决定一个类是否为单例（singleton）是逻辑设计问题。确定一个操作是否为抽象的或者决定要继承自一个类还是要包含它，这些同样也是逻辑设计问题。开发人员生存在代码中，就会不断地处理逻辑设计的问题。

能够很好地使用面向对象设计原则和模式是很重要的。要适应大多数业务应用中所需要的复杂行为是很有挑战性的任务，如果不能创建灵活的类结构，将会对未来的增长和可扩展性带来负面的影响。但是逻辑设计并不是本书关注的焦点。有很多其他的图书和文章提供了必要的指导，它们能提供足够的智慧以保证创建良好的逻辑设计。逻辑设计只是软件设计和架构所面临挑战的一个方面。挑战的另一方面就是物理设计。如果你没有考虑系统的物理设计，那么不管你的逻辑设计多么漂亮，可能都不会带来预期的收益。换句话说，缺乏物理设计的逻辑设计并不会带来预期的影响。

物理设计表现为软件系统中的物理实体。确定如何将软件系统打包到部署单元中是物理设计问题。决定哪个类属于哪一个部署单元也是物理设计问题。同样，管理可部署实体之间的关系也是物理设计问题。如果我们不说物理设计比逻辑设计更重要的话，起码它们是同等重要的。

例如，定义接口可以使客户端与实现该接口的类解除耦合，这是一个逻辑设计问题。按照这种方式解耦显然能够让你在不影响客户端的情况下，创建这个接口的新实现。但是，要将接口和它的实现类放到物理实体中就是物理设计问题了。如果这个接口有多个不同的实现，并且每个实现类都有底层的依赖，那么如何放置接口和实现就会对系统的整体软件架构质量产生巨大的影响。将接口和实现放在同一个模块中将会引入不必要的部署依赖。如果其中的一个实现依赖复杂的底层结构，那么不管你选择使用哪一个实现，都需要在所有的部署环境中包含这个依赖结构。尽管逻辑设计的质量很高，但是物理实体之间的依赖将会阻碍可重用性、可维护性以及很多在设计时试图要获得的其他收益。

令人遗憾的是，尽管众多团队付出了很大一部分时间在逻辑设计上，但是很少有团队在物理设计上下工夫。物理设计是关于如何将软件系统拆分为模块系统的，物理设计是关于软件模块化的。