在程序设计过程中，最头痛的不是逻辑的编写过程，更不是算法的设计，最头痛的是如何设计出一个容易维护，扩展性好的东西。而耦合问题是最令人烦躁的，它的存在很多人发现不了，所以往往无从入手，真是有苦自己知了，呵呵。以下是我的经验之谈。我通过例子来体现耦合问题的影响。
第一个例子： 在开发游戏的时候，有很多实体类，通常属于一条相同的生产线，如地形：土地，石块，草地，雪地，沼泽，等，具有相同特征而功能不同的对象，新手们，一般是在程序的某个地方，默默地new出这些应用到的对象，恩，一个，两个，三个，慢慢你会发现程序中不断出现新对象，如果存在10对象实体，而对象的提供了5个接口函数，也就是，读写操作，在程序中出现了几十次，这时，我不要这个对象了，换成其他了，那你是不是要改几十处地方？恩，问题就是这里了，没有一个抽象层面，必然会导致维护困难，当对象扩大化到100个，这是一个维护噩梦，当然，单单一个抽象层面是无法解决new实体对象的事实的，这个是令人头痛的问题，管理对象的生产是一个很重要的模块，这里对于某些高级语言，如C++，唯一比较好缓解的是工厂模式中的工厂方法，我比较喜欢用这个模式去管理对象，简单工厂就不要学了，没什么实际意义，而我可以很明确告诉你，第一个带你入门，第一个让你打开眼界的模式绝对是工厂方法模式，如果真想学模式，请先研究工厂方法，其使用的意义在于把对象的生成延迟到子类，而统一使用接口去管理对象的初始化，把变化点分离出调用端，这里我只能告诉你为什么要用设计模式，什么情况下要用，理不理解就靠你自己的实际经验和悟性了，本人悟性不高，当时在学习设计模式的时候，看了很多次依然没有领悟到工厂模式的奥妙，直至代码量和项目经验不断地增加才顿悟出个中道理，确实是很难用文字来表达，不过以上的例子足够证明它的意义，根源都是为了解耦。
第二个例子： 由于我一直都在开发游戏，所以所举得例子不免都和游戏有关，这个例子，如果你写过一个完整的游戏，必然有所了解，游戏总会有界面，而其中比较典型的界面是，菜单界面，菜单里有按钮，对吧？恩，这个问题，我当时设计就考虑，菜单类和按钮类究竟是分开还是合在一起？想来想去，由于当时设计观念没到家，最后把它们合在一起了，这种做法绝对是不好的，为什么呢？我们不要从概念上入手解释，通俗的讲法就是，菜单和按钮的对应关系是一对多，对吧？没有一种固定的关系，有可能1对2，1对3，1对10等等，所以把它们写在一起，是很僵化的，就单凭这种证明就可以发现，它们要分开，而它们最后的表现是合在一起，通过组合的方式，把按钮的抽象层面注入到菜单里面，就可以动态地生成完整的菜单，所谓的组合方式，不就是，菜单里面有一个存放按钮引用的集合，希望你明白我所说的，具体我就不解释了。
结语：我认为这里是全篇文章最重要的，比任何所谓的分层理论都重要，因为它更通俗，更实际，很多人，并不是面向对象学得不好，但总觉得差什么，我也经历过，面向对象，封装，多态，继承，学过的人都知道，都认为自己了解了，其实不然，很多很奇妙的因素，让你误解了，大部分的人认为封装很简单，其实大错特错了，封装是最奇妙的，也是最难用好的。只要你记住以下原则，必然能很好地用好封装，成员尽量使用protected和private，不要去使用public.尽量不要提供给外部对成员属性getter的接口，意思就是不要暴露成员，为什么要这样呢？很简单，暴露成员属性必然会导致自身业务的外泄，业务外泄，会导致，类之间的无谓耦合，如A类有成员a,而程序需要对a数据改变，而你提供一个B类可以访问a成员的getter接口，B类在其自身对a修改，看上去没什么，实际上，就是类耦合，对a的修改是类A的职务，由于习惯的提供getter，导致了，在写类B的时候错误地添加了修改业务，使类A内聚能力降低，程序逐步庞大必然会越发明显，真所谓牵一发动全身，小程序确实是很难看出问题所在。
就写那么多，本人愚见，希望对你有帮助。
