关于解耦的理解

在程序设计过程中,最头痛的不是逻辑的编写过程,更不是算法的设计,最头痛的是如何设计出一个容易维护,扩展性好的东西。而耦合问题是最令人烦躁的,它的存在很多人发现不了,所以往往无从入手,真是有苦自己知了,呵呵。以下是我的经验之谈。我通过例子来体现耦合问题的影响。第一个例子: 在开发游戏的时候,有很多实体类,通常属于一条相同的生产线,如地形:土地,石块,草地,雪地,沼泽,等,具有相同特征而功能不同的对象,新手们,一般是在程序的某个地方,默默地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内聚能力降低,程序逐步庞大必然会越发明显,真所谓牵一发动全身,小程序确实是很难看出问题所在。就写那么多,本人愚见,希望对你有帮助。

没有更多推荐了,返回首页