为什么一个计算机应用程序要使用多个文件？
Why use more than one or a few files for a computer application?
我开始制作自己的 php 非常小的框架，然后学习了 Symfony 框架的（非常）基础知识。一个小型 symfony 网站涉及大约 1000 个目录中的 11000 多个文件。我已经回到我自己的框架并且越来越抗拒创建新文件。
我致力于创建 DRY、MVC 代码，这意味着我确实需要一个文件用于应用程序，一个文件用于由多个应用程序共享的代码。本质上我需要 n+1 个文件，其中 n 是我构建的应用程序的数量。这不包括图像文件等资源。我在这里遗漏了什么（在我花太多时间在这种方法上之前）吗？将代码分布在多个文件上有什么好处？一个大文件是否比许多加起来相同代码量的小文件更糟糕？
简答：关注点分离。
假设您有两个应用程序，一个显示天气信息，另一个显示股票更新。看起来，它们彼此无关，因此您将它们放在不同的文件中。毕竟，您真的不希望在股票更新代码之间插入天气代码。
部分代码可以共享。您可以将该代码放在共享库中。到目前为止，还不错。
但是，如果您发现天气应用程序中的某些代码实际上可以用于股票更新，会发生什么情况？例如，执行 Web 服务客户端请求的代码。您必须从一个天气文件中删除该代码，并将其放入库中。随着时间的推移，该库将变得非常庞大，其中包含新应用程序可能不需要的功能。
如果将所有内容都保存在一个文件中，这些文件将不可避免地变成无法维护的毛线球、重复的代码以及其他类似的细节。它们将很难进行单元测试，而且您会忘记代码位于何处以及它们的作用。您将有重复的代码，并且在一个地方修复了错误，在另一个地方仍未解决。
这就是为什么最好的做法是以相似的功能放在一起的方式来组织功能，这样 webclient.php 就可以处理 Web 服务客户端，而不是在 weather.php 的某个地方丢失。
TL;DR
你的代码可读性和可维护性。为此你应该雇用
- 关注点分离，
- 低耦合，
- 高内聚
解释
详细说明 SeverityOne 的回答。并非所有事情都遵循关注点分离原则，尽管它无疑是现代编程中最重要的事情之一（哎呀，在所有编程中）。
您可以随心所欲地编写代码。我认识一个人，他喜欢随心所欲地编写代码。但如果你在一个团队中工作或者你的代码预计会由其他人维护，那么请准备好你的名字成为 "dumb duck" 和 "aye-ho" 的同义词。当我在他之后开始维护这个人的代码时，他的名字就成了 "dumb duck" 和 "aye-ho" 的同义词。原因？没有思想的不可读代码。一个任务可能需要一个小时，但花了六个小时才最终理解那只笨鸭子用他的鸭子躲避 aye-ho 变量意味着什么。谢天谢地，笨鸭子不再和我们一起工作了，我们扔掉了他制作的 "code" 并开始从头开始重写。看到我的情绪溢出了吗？那是因为那只笨鸭子和你一样想："oh, why go for readability and maintainability when I can get a sandwhich from the company kitchen!"
为了让你的同事喜欢和你一起工作，你需要想一个合适的方法来维护你的代码。你想到了关注点分离 - SeverityOne 已经解释过了。
你还应该保持低耦合，即不同classes相互依赖的程度。低耦合背后的想法是你的 classes（或模块）应该尽可能独立，并且最好永远不要 "know" 彼此。
最后记住高内聚。内聚度是指一个class的元素在一起的程度。其背后的想法是相关代码应该彼此靠近，并将所有相关代码尽可能紧密地绑定在一起。
一个例子
您正在创建博客。想想一个典型的博客例子。糟糕的方法是创建 2 种方法来列出您的 post 并显示一个 post，全部在一个文件中，运行 查询在同一个文件中，写 html和 css 在同一个文件中，无论想到什么。为什么不好？如果 Bob 或 Alice 需要向数据库中添加一个新列怎么办？他们必须在多少地方编辑 SELECT 查询？他们之后需要编辑多少 HTML？你能猜出这需要多少小时吗？ 5？ 17？ 42?
好的方法是将每个博客 post 分离到一个特定的实体，绑定到一个 ORM（或其他任何东西，但我个人最喜欢的是 Hibernate(Java) / Doctrine(PHP)).然后，如果正确使用 Symfony，您可以创建 2 个 select 的简短方法并显示列表或博客 post 详细信息。你在 Twig 中维护 HTML/CSS。当 Bob 或 Alice 需要向数据库中添加一列时会发生什么？带有简短 UPDATE 查询的迁移文件，实体中的一行代码，Twig 中的几行代码。快速、干净、可维护。时间？不到一小时。
我开始制作自己的 php 非常小的框架，然后学习了 Symfony 框架的（非常）基础知识。一个小型 symfony 网站涉及大约 1000 个目录中的 11000 多个文件。我已经回到我自己的框架并且越来越抗拒创建新文件。
我致力于创建 DRY、MVC 代码，这意味着我确实需要一个文件用于应用程序，一个文件用于由多个应用程序共享的代码。本质上我需要 n+1 个文件，其中 n 是我构建的应用程序的数量。这不包括图像文件等资源。我在这里遗漏了什么（在我花太多时间在这种方法上之前）吗？将代码分布在多个文件上有什么好处？一个大文件是否比许多加起来相同代码量的小文件更糟糕？
简答：关注点分离。
假设您有两个应用程序，一个显示天气信息，另一个显示股票更新。看起来，它们彼此无关，因此您将它们放在不同的文件中。毕竟，您真的不希望在股票更新代码之间插入天气代码。
部分代码可以共享。您可以将该代码放在共享库中。到目前为止，还不错。
但是，如果您发现天气应用程序中的某些代码实际上可以用于股票更新，会发生什么情况？例如，执行 Web 服务客户端请求的代码。您必须从一个天气文件中删除该代码，并将其放入库中。随着时间的推移，该库将变得非常庞大，其中包含新应用程序可能不需要的功能。
如果将所有内容都保存在一个文件中，这些文件将不可避免地变成无法维护的毛线球、重复的代码以及其他类似的细节。它们将很难进行单元测试，而且您会忘记代码位于何处以及它们的作用。您将有重复的代码，并且在一个地方修复了错误，在另一个地方仍未解决。
这就是为什么最好的做法是以相似的功能放在一起的方式来组织功能，这样 webclient.php 就可以处理 Web 服务客户端，而不是在 weather.php 的某个地方丢失。
TL;DR
你的代码可读性和可维护性。为此你应该雇用
- 关注点分离，
- 低耦合，
- 高内聚
解释
详细说明 SeverityOne 的回答。并非所有事情都遵循关注点分离原则，尽管它无疑是现代编程中最重要的事情之一（哎呀，在所有编程中）。
您可以随心所欲地编写代码。我认识一个人，他喜欢随心所欲地编写代码。但如果你在一个团队中工作或者你的代码预计会由其他人维护，那么请准备好你的名字成为 "dumb duck" 和 "aye-ho" 的同义词。当我在他之后开始维护这个人的代码时，他的名字就成了 "dumb duck" 和 "aye-ho" 的同义词。原因？没有思想的不可读代码。一个任务可能需要一个小时，但花了六个小时才最终理解那只笨鸭子用他的鸭子躲避 aye-ho 变量意味着什么。谢天谢地，笨鸭子不再和我们一起工作了，我们扔掉了他制作的 "code" 并开始从头开始重写。看到我的情绪溢出了吗？那是因为那只笨鸭子和你一样想："oh, why go for readability and maintainability when I can get a sandwhich from the company kitchen!"
为了让你的同事喜欢和你一起工作，你需要想一个合适的方法来维护你的代码。你想到了关注点分离 - SeverityOne 已经解释过了。
你还应该保持低耦合，即不同classes相互依赖的程度。低耦合背后的想法是你的 classes（或模块）应该尽可能独立，并且最好永远不要 "know" 彼此。
最后记住高内聚。内聚度是指一个class的元素在一起的程度。其背后的想法是相关代码应该彼此靠近，并将所有相关代码尽可能紧密地绑定在一起。
一个例子
您正在创建博客。想想一个典型的博客例子。糟糕的方法是创建 2 种方法来列出您的 post 并显示一个 post，全部在一个文件中，运行 查询在同一个文件中，写 html和 css 在同一个文件中，无论想到什么。为什么不好？如果 Bob 或 Alice 需要向数据库中添加一个新列怎么办？他们必须在多少地方编辑 SELECT 查询？他们之后需要编辑多少 HTML？你能猜出这需要多少小时吗？ 5？ 17？ 42?
好的方法是将每个博客 post 分离到一个特定的实体，绑定到一个 ORM（或其他任何东西，但我个人最喜欢的是 Hibernate(Java) / Doctrine(PHP)).然后，如果正确使用 Symfony，您可以创建 2 个 select 的简短方法并显示列表或博客 post 详细信息。你在 Twig 中维护 HTML/CSS。当 Bob 或 Alice 需要向数据库中添加一列时会发生什么？带有简短 UPDATE 查询的迁移文件，实体中的一行代码，Twig 中的几行代码。快速、干净、可维护。时间？不到一小时。