功能解耦,应用解耦
在编程过程中，最头疼的不是逻辑的编写过程，也不是算法的设计。 最头疼的是如何设计容易维护、可扩展性强的东西。 偶联问题最让人烦躁。 它的存在很多人无法发现，所以经常得不到。 真的很痛苦呢。 以下是我的经验之谈。 我通过例子体现了结合问题的影响。 第一个例子：开发游戏时，有很多实体类，通常属于同一条生产线。 例如地形：土地、石头、草地、雪、沼泽等具有相同特征，功能不同的对象。 初学者们通常在程序的某个地方默默地推出这些应用对象。 嗯，一个、两个、三个，慢慢地在程序中找到，同时对象提供了五个接口函数。 也就是说，读写操作在程序中出现了几十次。 这个时候，我放弃了这个对象，换成了其他的东西。 那你要换几十处吗？ 是的，问题在这里。 如果没有抽象的水平，毫无疑问维护会变得困难。 如果对象放大到100个，这将是维护的噩梦。 当然，仅从抽象的层面无法解决new物理对象的事实。 这是头痛的问题。 管理对象的生产是一个重要的模块。 在这里，对于C等部分高级语言，只有工厂模式的工厂方法可以缓和。 我喜欢用这个模式管理对象。 简单的工厂不要学习。 没有实际意义。 但最先带你来，最先让你睁开眼睛的模式绝对是工厂的方法模式。 如果你真的想学习模式，请先研究一下工厂的方法。 它的使用意味着将对象的生成延迟到子类，统一使用接口管理对象的初始化，并将变化点与调用方分离。 这里只能告诉你为什么要使用设计模式，在什么情况下使用。 不能理解取决于你自己的实际经验和理解力。 本人的理解力不高。 当时学习设计模式的时候，无论看多少次都无法理解工厂模式的深奥。 代码量和项目经验增加后才领悟到中理。 确实很难用文字来表达，但上述例子充分证明了其含义。 根本是为了理解联轴器。 第二个例子：因为我总是在开发游戏，所以所举的例子无论如何都和游戏有关。 只要写过完整的游戏，就一定知道这个例子。 游戏总是有接口的。 其中典型的界面是菜单界面。 菜单上有按钮吧。 嗯，这个问题，我当时想，菜单类和按钮类是分开的还是一起的。 仔细想想，当时的设计观念还没到家，最后把它们放在了一起。 这种做法绝对不好。 为什么呢？ 请不要从概念上说明。 通俗地说，菜单和按钮的对应关系是一对多的。 因为没有固定的关系，有1比2、1比3、1比10等可能性，所以把它们写在一起是僵化的，单从这个证明就可以看出，它们必须分离，但最后的表达被放在一起，根据不同的组合方式，按钮抽象组合方法不是这样，而是菜单中存储了按钮引用的结语：我认为这里是整篇文章中最重要的，比任何层次理论都重要。 因为它更通俗，更实际。 很多人并不擅长面向对象，只是觉得有什么不好。 我也经历过。 面向对象、封装、多态性、继承、学习的人知道，以为自己知道，其实不然。 有很多奇怪的因素，是误会了。 大部分是 只要记住以下原则，必然可以很好地封装。 成员尽量使用protected和private，不要使用public。 尽量不要提供给成员属性getter的外部接口。 意思是不露出成员。 为什么会这样呢？ 很简单。 暴露成员属性必然会导致自己业务的流失。 业务的流失会导致班级之间的无谓结合。 例如，a类中有一个成员a，程序需要更改a类中的数据，但是您提供了一个getter接口，b类可以访问a类中的成员，即使b类自己更改了a类，实际上也是如此因为习惯性地提供getter。写b类的时候不小心添加了修改业务，降低了a类的凝聚能力，必然会导致程序逐渐变得巨大。 正是牵着全身而动，用小程序确实很难明白问题。 就写这么多，我是愚见。 我希望对你有帮助。