将代码分割成多个源文件

Question

我经常阅读关于将大型（单片？）应用程序代码块分成单独的源代码文件以便更容易维护等的需求，但我还没有看到任何解释如何做到这一点的东西。

创建单独文件的过程在添加子类的过程中很简单 - 当然这是我试图实现的一个很好的例子 - 但是如果我们只有一个控制器对象并且想要分割我们的代码到比方说，（1）含有仅用于计算的东西和（2）含有另一对仅印刷相关的方法的方法的接口和实现文件组，但具有各方法能够访问所有其它的方法，如他们都仍然在一个（源）文件。

任何有关如何去解决这个问题的详细建议（如果可能的话）将不胜感激。谢谢:-)

Answer 1

这最好通过使用类别完成。例如，创建一个名为+ myController的一个Printing.h头文件：

#import "MyController.h" 
@interface MyController (PrintingSupport) 
- (void)print:(id)sender; 
@end 

和执行文件+ myController的Printing.m：

#import "MyController+Printing.h" 
@implementation MyController (PrintingSupport) 
- (void)print:(id)sender 
{ 
} 
@end 

看在苹果的头文件对这项技术的很好的例子。

Answer 2

我对这种编程语言并不熟悉，但总的来说，模块化的要点是隐藏复杂的实现并暴露一个简单的接口。这很好，因为您通常不需要所有的数据和所有功能来完成每项任务。这是通过保持数据接近他们使用的地方（例如同一类）和使用少量的公共方法来完成的。

然而，有些情况下，你需要支持共享大量数据和模块之间的功能很容易，这听起来像你想做什么情况。例如。在GUI编程中，模型 - 视图 - 控制器设计模式就是这样做的。关键是要以其他方式对数据和功能进行分组，但做起来不那么容易。

问题要问自己： 而不是让控制器与数据分离，是否有可能重构，使每个部分的数据与控制器的相应部分？例如，如果您有两种类型的数据，您是否可以重构为两个类，每个类都有计算和打印该类型数据的方法？也许你会发现一些“数据”真的是控制器的状态，而这绝对属于控制器代码。

Answer 3

如果你的类增长如此之大，你想怎么砍他们到不同的源文件，你可能有一个设计问题。

的模型 - 视图 - 控制器（更好，模型的控制器视图）设计模式几乎自动创建小模块化的代码。

该模型处理与数据相关的所有内容。该视图管理实际的视觉用户界面，控制器将两者粘合在一起。每个模块都是一个独立的类，理想情况下，模型和视图应该非常独立，以便可以轻松插入其他应用。

关键是在分离功能上是完全无情的。将数据保存在控制器中总是很有吸引力。当你只是用很少的数据学习和编写小程序时，情况尤其如此。但是，随着数据复杂性的增长，您的控制器很快就会变得复杂起来。

所有优秀的设计都是从数据模型开始的。该模型应该处理数据中的所有逻辑关系，即创建，修改，验证，保存等。设计正确的数据模型对于用户界面来说是完全不可知的。理想情况下，数据模型应该可以与标准视图，Web视图，命令行一起工作或者抛出一个URL。

我总是通过在绝对最小接口的测试应用程序中创建数据模型来启动项目。 （通常它只是一个启动的空白应用程序，以编程方式操作数据模型，打印到控制台并退出。）只有当数据模型独立工作时，才会转向程序的其余部分。

现在，我了解数据和数据操作，我可以为每个要运行的环境设计一个UI。 UI仅了解如何创建UI元素以及如何响应事件。它不包含任何数据，甚至不包含将这些元素相互关联的逻辑。

控制器将视图和数据模型粘合在一起。控制器只知道向数据模型发送哪些消息以获取特定UI元素中响应特定事件的数据。它不验证数据或对其执行任何逻辑操作。它只是在数据模型和当前视图之间路由信息。

任何创建其他接口的操作（如打印）都应该有自己的控制器对象。例如，在打印时，只有数据模型能够理解所有数据如何在页面上进行拼接。没有理由为什么控制UI视图的同一个控制器应该控制打印。相反，打印控制器只是要求数据模型打印数据。 UI控制器只需要调用打印控制器并将其指向用户选择的数据即可。

在您的具体示例中，计算方法将在数据模型中，打印控制器中的打印方法等。使用模型 - 视图 - 控制器，最终会生成许多令人惊讶的小模块类，这些类很容易管理，测试和移植。