面向对象软件开发代码结构（1）

类内部结构

类内部架构实际上是一个小型的状态机，成员变量是状态变量，成员函数是处理机。一般提倡一个类实现一种特定的功能，这样可以降低实现的复杂性，状态机越简单，越利于实现。

实例间通信

软件的功能是多个模块共同协作来实现的。这就需要多个模块的实例进行通信、相互调用。
相互调用和访问对类或模块来说，就是设计对外接口。这也是public、private关键字的设计思想。

对外接口数量越少，每个模块间的耦合越少，代码维护起来越简单；反之，模块间交互越多，耦合性越高，软件维护难度越高。

对于开发人员来说，类或者模块实例间的相互访问，要求程序员控制好实例的可见性。如果控制不好，软件后期的维护难度会增加。

实例可见性管理

实例可见性管理分为实例生命周期管理和实例访问路径管理两个方面。

实例生命周期管理

每个实例都有生命周期，生命周期是软件开发人员可以控制的。例如基本类型的变量只能存在于作用域内，超出作用域其保存的数据就会失效。实例也一样，实例只有在生存期内才可以被访问。这是一切访问的前提。
生命周期管理，即要求软件开发人员正确分配实例存活时间。

如果实例存活时间太短，会导致找不到此实例，无法实现预期功能。
如果实例存活时间太长，会持续占用内存等资源，造成资源利用率低。例如将所有实例采用全局变量保存，优点是此实例在整个软件运行时间，任何模块都能访问，缺点是这样的软件资源消耗会很严重。

实例访问路径管理

访问途径和实例的嵌套程度有关。
例如，全局实例、可全局访问的单例、位于全局实例内的实例（半全局）可以通过最多一次函数调用获取到实例地址。而对于嵌套的类来说，嵌套的层数即获取实例地址需要间接寻址或函数调用的次数。显然，访问路径越简单，需要编写的代码越少，开发和运行效率也越高。
所以最简单的路径还是全局的或半全局的，并且在软件设计中，减少类嵌套，简化访问路径。

例如，你现在参与一个已在开发中的项目后，为了添加一个需求，你需要访问一些已有的实例数据。你可能会遇到暂时获取不到目标实例指针的问题，这就需要你自己添加获取目标实例指针的代码，或者调整代码结构，这无疑是不少的工作量。但是对客户来说，明明窗口都在那摆着，直接一句话访问不就行了吗？而客户却不知道你为了修改一个功能，要考虑如何更好的管理实例生命周期。最后的结果是加班或者拖延项目进度。
从上面的例子可知，已有的代码可以帮助你，也可以让你发疯。

实例可见性管理是会随着需求的改变而需要动态调整的。例如有的变量本来只需要在内部访问，在需求改变后，需要在几个模块间共享，这就需要对其可见性进行修改。

正因为可见性管理是会随需求改变而改变的，所以在实际开发中，可以将其生命周期设置得灵活一点，或者留有一些余量，以便于对未来的改变做较少的调整。

有一种比较松散的实例管理方式。每种实例设置一个全局的管理器，多个相关实例具有相同的id。根据其中一种数据，查找相关数据时，只需要用同一个id去查找。一个实例销毁，不影响其他实例，可以自由控制实例的生存时间。

量化

如果将实例的访问管理交给软件开发者管理，会增加软件开发者的负担，同时也因为软件开发者能力或项目预算等因素导致软件的开发、维护工作量不稳定，降低软件质量。

所以如果可以将实例的访问管理进行量化，让所有的需要交互的实例（即相对非内部的实例或数据）均为全局、半全局实例，在开发完成后进行自动优化，及时释放资源未被使用的资源，这就会减轻软件开发者的负担，提高开发效率，最终有更多的时间去减少bug，优化交互等等，从而提升软件质量。

总结

本文主要介绍了使用面向对象的方法开发软件时，程序中对象协作方式与实例管理相关内容，为了写出更好的软件，可以参考上述内容考虑代码的组织结构。