碰巧的是，该项目陷入停顿，进一步发展成为不可能。 这种失败的原因并非罕见，是在开发之初就建立了失败的架构。 还是您必须观察有关“两把椅子”中哪一个更好的争执，或者甚至参加而不能真诚地理解对手的想法！
然后，我们将尝试不理解很多抽象，它们来自何处以及如何使用它们。
根据Wikipedia的说法，抽象是抽象的一种理论概括。 反过来，抽象是在认知过程中从非必要的当事人，属性，对象（对象或现象）的关系中分散注意力，以突出其基本的规律性。
根据定义，我们可以得出结论，只有有意义才可以是抽象。 在这种情况下，感知只是现实世界的投影。 事实证明，对实物的所有反射都是对我们实物模型的反射。
抽象形成层次结构，可以与两个私有实体一起识别，并将相似的实体组合成更高级别的抽象。
意识抽象
除了感知棱镜之外，我们的模型还受到另一种扭曲：真实实体非常复杂，并且具有不同的方面和参数。 在思考或谈论某事时，总会有一个存在模型的上下文。 有时，这种情况下的对话者是不同的。 最重要的是，根据经验，经验的存在与否（全局）会导致我们的模型发生更大的变化。 结果，两个不同的人对现实世界中相同实体的理解可能会非常不同。
事实证明，每个人都在不断处理抽象，还有待学习如何清楚地看到和管理它们。 可以提出这样的论点，即程序代码是基于形式化抽象的思维模拟。 因此，我认为软件开发是激发抽象思维的最佳模拟器之一。
开发中的抽象
编程接口也许是最明显的形式化抽象。 所有多余的东西都被切除，只有“它做什么”保留下来而没有“它如何做”。
通过实现接口，我们创建了行为或交互的更现实的模型，该模型已经可以回答“如何”的问题。 通过相互结合接口，我们可以创建通用的代码架构。 通过适当的技巧和灵巧性，以这种方式创建的体系结构将在将来保留其结构。 虽然复合接口的实现可能会发生变化，但无法识别。
这种体系结构简化了工作中的某些要点。 单元测试归结为编写“相邻”抽象的测试实现以及比较输入和输出的测试方法。 模块的绝缘使您可以安全地进行重构。 而且，如果重构不成功并且一切都中断了，那么您将只需要回滚一个模块。 足够抽象的模块可以用于相似但不同的任务。 同时，一个不好的实现不会影响其他人的工作-隔离govnokod。
例子有一个用于处理输入数据的模块，有几种获取它们的选项：从数据库； 从文件 通过http。 可以通过突出显示用于接收数据的通用接口并为每个通道和数据通道进行测试来解决此问题。 现在，一个处理程序可以使用“数据通道”参数解决几个类似的问题。 而且，如果发现其中一种实现是曲线，则可以重做以影响其他模块。
不再需要抽象
没有完美的解决方案，因此使用抽象，事情就不会那么顺利。 首先，抽象是主观的，它们可能引起关于一个从哪里开始以及另一个从哪里开始的争论。 当为喷嚏的每种类型和音调创建不同的抽象时，也存在过度抽象的问题。 其次，此方法通过添加新实体和新层次结构级别来增加代码复杂性。 我敢肯定，这种方法仍然有缺点，其中有些是主观的，部分是情境的，但是将会存在
一切都应该保持平衡。 对于我自己，我推断出以下备忘录。
- 如果您要编写一个大型且重要的模块-最好将其脱离。
- 如果该模块被大量使用和/或在不同的地方使用，则最好将其隐藏在抽象之后。
- 如果模块应作为单独的库分发，则最好使用抽象。
- 如果可以更改算法或交互路径，则最好实现抽象的交互。
- 如果该类是在其他类中使用的，则可以考虑将它们组合或保持原样。
- 如果这是一项“一次性”的小任务-最好不要打扰它的复杂性。
- 如果这是一个极有可能永远不会改变的模块-您可以显示其界面，最好将所有内容保留在里面。
合计
抽象是我们内心深处的一种工具，就像其他任何东西都有其优缺点一样，但是了解替代方法只会帮助找到更好的方法。