设计模式使用心得

0

写在前面

作为一名有追求的程序员,在完成项目的前提下,应该总是希望能够编写出便于阅读、便于扩展、结构良好的代码,简单概括的话,就是编写出优雅的代码。

一些团队在编码规范上,只要求了工程结构分层,并没有对如何编写优雅的代码进行更多的要求。

举个例子,团队可能要求开发Web程序时,工程有如下分层:

  • Controller:编写控制器;
  • Business:编写业务;
  • Dao:编写数据库访问;
  • Entity:编写实体类;
  • Util:编写工具类;

其中,以Business为例,团队并没有约定Business中的那些业务实现类如何设计。也许在大团队中,会有专职的架构师来对业务进行需求分析、绘制UML图、编写概要设计、详细设计。但多数团队并没有这样好的条件,更多的时候,是由架构师负责定义好技术架构,研发工程师负责进行需求实现(与业务人员或产品经理对接)。

如果是后面一种情况(研发直接负责需求实现),软件的可扩展性就完全落到研发的身上。

有些团队会因为时间紧张,任务繁重而放弃程序的扩展性,举个例子:一个功能模块编写一个业务实现类。如果是一个长期维护的项目,放弃扩展性可能会在首次研发阶段节省一点时间,但就长远来看,要付出的代价有可能会更多。

所以,如果在编写业务代码时,能自然而然的考虑扩展性,这样才能算是一名合格的软件工程师吧。

因此,我想把我从书本中学到的知识、从实战中收获的经验,进行一次全面的总结,希望自己能从这次总结中学习到更多,也希望总结提到的某一点,能对其他同行起到帮助。

同时,我始终觉得,如果能把一些平时都在做的事情语言化,会使我对我正在做的事情有更进一步的理解。

我对设计模式的理解

以我目前对设计模式的理解和实战中的使用,觉得设计模式是使程序具备高内聚低耦合的一种手段。当程序具备了这两种特定,在发生变更时,会使事情变得简单。

简单说说我目前对高内聚低耦合的理解,高内聚是指把相同种类的object都集中一个module中,低耦合是指modulemodule之间的关联尽量小而轻。

这么说可能比较抽象,如果比较通俗的描述,可以这么理解:

  • 高内聚:有一堆食材和几个筐,我把水果都放到一个筐里(高内聚,因为它功能单一,独立性强。),再把蔬菜都放到第二个筐里,把肉类放到第三个筐里。
  • 低耦合:筐和筐之间做简单的关联,关联范围尽可能小,这样就做到了低耦合。筐中食材的关联也尽可能做到低耦合,食材本身也尽可能做到低耦合。

在开发软件的过程中,尽量找到高内聚和低耦合的平衡点是最关键的。

设计模式给我带来的好处

使用设计模式(也就是程序相对的具备了高内聚和低耦合的特性)后,对我带来了肉眼可见的两点好处。

第一,应付需求变更。高内聚使我快速定位到需要变更的位置,低耦合使我修改代码时,对调用者的影响范围尽可能的减小了,也很少会出现“按下葫芦起来瓢”的情况(修改了某处功能导致其他地方出现问题)。

第二,与同行交流变得更简单,在《领域驱动设计》第二章中提到过 —— 模式:UBIQUITOUS LANGUAGE。使用设计模式后,可以很简单的用一些模式名称描述程序设计,配合约定好的一些命名规则,阅读其代码也变得很轻松。

我的记录步骤

目前打算记录的有:

  • 设计模式原则与分类;
  • 逐一记录设计模式的理解、使用与心得;
  • 领域驱动设计的理解、使用与心得;

参考书籍

  • 《Head First设计模式》
  • 《图解设计模式》
  • 《设计模式之禅》
  • 《领域驱动设计》
  • 《重构》
  • 《Effective Java》

你可能感兴趣的

载入中...