软件工程中的反面模式(anti-pattern)

软件设计

  • 抽象倒置(Abstraction inversion):不把用户需要的功能直接提供出来,导致他们要用更上层的函数来重复实现
  • 用意不明(Ambiguous viewpoint):给出一个模型(通常是OOAD,面向对象分析与设计)却没有指出用意何在
  • 大泥球(Big ball of mud):没有清晰结构的系统
  • 数据库式进程间通信(Database-as-IPC):使用数据库进行进程间通信,而不使用更轻量级的合适的机制。或者说,对于常规的进程间通信,不是去采用轻量得多的合适机制,而是将数据库用作消息队列。
  • 镀金(Gold plating):在项目达到最高价值后还继续工作。
  • 内部平台效应(Inner-platform effect):系统可自定义的太多,以至于成为一个软件开发平台的蹩脚的复制品。
  • 输入问题(Input kludge):无法确定和实现对异常输入的处理
  • 接口膨胀(Interface bloat):把一个接口做得过于强大以至于极其难以实现
  • 魔力按键(Magic pushbutton):直接在接口的代码里编写实现,而不使用抽象
  • 竞争风险(Race hazard):输出结果受到事件执行顺序和时机的影响,在多线程环境和分布式系统中可能发生
  • 烟囱系统(Stovepipe system):过度聚集数据和功能,忽视了与其他系统和模块的共享

面向对象设计

  • 贫血的域模型(Anemic Domain Model):仅因为每个对象都要有属性和方法,而在使用域模型的时候没有加入非OOP的业务逻辑
  • (BaseBean):继承一个工具类的功能,而不是委托给它
  • 调用父类(Call super):需要子类调用父类被重定义的方法
  • 圆还是椭圆问题(Circle-ellipse problem):基于变量的子类化关系进行子类化
  • 循环依赖(Circular dependency):在对象或软件模块中,直接或间接引入循环依赖。
  • 常量接口(Constant interface):使用接口定义常量
  • 上帝对象(God object):在设计的单一部分(某个类)集中了过多的功能
  • 对象粪池(Object cesspool):复用那些不满足复用条件的对象。对象池是一种管理对象的方法,在重复使用对象前,需要针对对象进行初始化,以避免上次使用后的状态等数据影响下次的使用
  • 不羁的对象(Object orgy):没有成功封装对象,外部可以不受限制地访问它的内部
  • 幽灵(Poltergeists):指这样一些对象,它们唯一的作用就是把信息传给其它对象
  • 顺序耦合(Sequential coupling):指这样一些对象,它们的方法必须要按某种特定顺序调用
  • 悠悠问题(Yo-yo problem):一个结构(例如继承)因为过度碎片化而变得难于理解

编程

  • 偶然复杂度(Accidental complexity):向一个方案中引入不必要的复杂度
  • 远隔作用(Action at distance):意料之外的在系统分离的部分之间交互
  • 盲目信任(Blind faith):缺乏对bugfix的校验或对子函数返回值的正确性检查
  • 船锚(Boat anchor):在系统中保留无用的部分
  • 忙等待(Busy waiting):在等待的时候不断占用CPU,通常是因为采用了重复检查而不是适当的消息机制
  • 缓存失败(Caching failure):错误被修正后忘记把错误标志复位
  • 拜物编程(Cargo cult programming):由于对模式的盲目崇拜,在不理解的情况下就使用模式和方法,企图得到好的结果
  • 靠异常编程(Coding by exception):当有特例被发现时才添加新代码去解决
  • 隐藏错误(Error hiding):在显示给用户之前捕捉到错误信息,要么什么都不显示,要么显示无意义的信息
  • 硬编码(Hard code):将对系统环境的假设写入实现中
  • 熔岩流(Lava flow):保留不想要的(冗余的或是低质量的)代码,仅因为除去这些代码的代价太高或是会带来不可预期的结果
  • 循环-switch序列(Loop-switch sequence)在循环结构中使用switch语句来编写连续步骤
  • 魔幻数字(Magic numbers):在算法里直接使用数字,而不解释含义
  • 魔幻字符串(Magic strings):直接在代码里使用常量字符串,例如用来比较,或是作为事件代码
  • 自我复制(Repeating yourself):通过不断复制已有代码的模式或代码段进行编码;而非采用once and only once(抽取原则)
  • 软代码(Soft code):在配置文件里保存业务逻辑而不是在代码中
  • 面条代码(Spaghetti code):指那些结构上完全不可理解的系统,尤其是因为误用代码结构
  • 霰弹枪手术(Shotgun surgery):开发人员一次性在一个多个实现的代码基中增加功能

方法论

  • 拷贝粘贴编程(Copy and paste programming):拷贝(然后修改)现有的代码而不是构造通用的解决方案
  • 黄金大锤(Golden hammer):认为自己最喜欢的解决方案是到处通用的(参见:银弹)
  • 不可能因素(Improbability factor):认为已知的错误不可能发生
  • 不是这里发明的(Not invented here):拒绝使用组织外的主意或方案
  • 这里发明的(invented here):拒绝组织内部实现的创新或解决方案,通常因为对成员没有信心
  • 不成熟的优化(Premature optimization):在编码的早期追求代码的效率,牺牲了好的设计、可维护性、有时甚至是现实世界的效率
  • 转换编程法或巧合编程(Programming by permutation or programming by accident):试图通过连续修改代码再看是否工作的方式来解决问题
  • 重新发明方的轮子(Reinventing the square wheel):已经有一个很好的方案了,又再搞一个烂方案来替代它
  • 银弹(Silver bullet):认为自己最喜欢的技术方案能解决一个更大的问题
  • 测试人员驱动开发(Tester driven development):需求来自bug报告的软件工程

来源于wikipedia

时间: 2024-11-05 13:28:17

软件工程中的反面模式(anti-pattern)的相关文章

备忘录模式(Memento Pattern)

备忘录模式(Memento Pattern)用来恢复一个对象的状态到以前的状态. 备忘录模式下属于行为模式的类别. 实现实例 在这个示例中,备忘录模式(Memento Pattern)使用三个操作者类. Memento类中包含要恢复的对象的状态. 创建者在Memento对象中创建和存储状态,Caretaker对象负责从Memento中恢复对象状态.在这个示例中,创建了以下几个类:Memento,Originator和CareTaker. MementoPatternDemo这是一个演示类,它将使

设计模式之七:建造模式(Builder Pattern)

建造者模式就是将一个复杂对象的构造与它的表示分离,使同样的构建过程可以创建不同的表示. 适用范围: 当创建复杂对象的算法应该独立于该对象的组成部分以及它们的装配方式时. 当构造过程必须允许被构造的对象有不同表示时. 建造者模式里面有四个角色: Builder: 给出一个抽象接口,以规范产品对象的各个组成部分的建造.一般而言,此接口独立于应用程序的业务逻辑.模式中直接创建产品对象的具体创建者角色.具体创建者角色必须实现这个接口的所有方法:一个是建造方法,另一个是结果返还方法. ConcreteBu

设计模式 - 代理模式(proxy pattern) 未使用代理模式 详解

代理模式(proxy pattern) 未使用代理模式 详解 本文地址: http://blog.csdn.net/caroline_wendy 部分代码参考: http://blog.csdn.net/caroline_wendy/article/details/37698747 如果需要监控(monitor)类的某些状态, 则需要编写一个监控类, 并同过监控类进行监控. 但仅仅局限于本地, 如果需要远程监控, 则需要使用代理模式(proxy pattern). 具体方法: 1. 类中需要提供

设计模式 - 迭代器模式(iterator pattern) Java 迭代器(Iterator) 详解

迭代器模式(iterator pattern) Java 迭代器(Iterator) 详解 本文地址: http://blog.csdn.net/caroline_wendy 参考迭代器模式(iterator pattern): http://blog.csdn.net/caroline_wendy/article/details/35254643 Java的标准库(util)中包含迭代器接口(iterator interface), import java.util.Iterator; 继承(

设计模式 - 外观模式(facade pattern) 详解

外观模式(facade pattern) 详解 本文地址: http://blog.csdn.net/caroline_wendy 外观模式(facade pattern): 提供了一个统一的接口, 用来访问子系统中的一群接口. 外观定义了一个高层接口, 让子系统更容易使用. 外观模式包含三个部分: 1. 子系统: 子类, 单个复杂子类 或 多个子类; 2. 外观(facade)类: 把子系统设计的更加容易使用; 3. 客户: 只需要调用外观类. 与适配器模式(adapter pattern)的

策略模式(Strategy Pattern)

策略模式(Strategy Pattern) 抛开晦涩的定义,首先看一个例子: 我们想要创建一个模拟鸭子的游戏,在这个游戏中,会有各种类型的鸭子,比如mallard duck,red head duck,rubber duck(除了rubber duck(橡皮鸭),看见这其余两种鸭子很好奇,于是查找相关图片,发现mallard duck是绿头鸭,red head duck是红头鸭,自己生活中还没有见过,有趣,哈哈!三种鸭子图片如下所示). 回归话题,在这个模拟鸭子的游戏中,各种鸭子均有两种能力,

[翻译] 理解贷出模式 Loan Pattern

Loan Pattern as the name suggests would loan a resource to your function. So if you break out the sentence. It would Create a resource which you can use Loan the resources to the function which would use it This function would be passed by the caller

规约模式(Specification Pattern)

前期准备之规约模式(Specification Pattern) 一.前言 在专题二中已经应用DDD和SOA的思想简单构建了一个网上书店的网站,接下来的专题中将会对该网站补充更多的DDD的内容.本专题作为一个准备专题,因为在后面一个专题中将会网上书店中的仓储实现引入规约模式.本专题将详细介绍了规约模式. 二.什么是规约模式 讲到规约模式,自然想到的是什么是规约模式呢?从名字上看,规约模式就是一个约束条件,我们在使用仓储进行查询的时候,这时候就会牵涉到很多查询条件,例如名字包含C#的书名等条件.这

《软件工程 ——理论、方法与实践》知识概括第五章 软件工程中的形式化方法

第5章 软件工程中的形式化方法    从广义上讲,形式化方法(Formal Method)是指将离散数学的方法用于解决软件工程领域的问题,主要包括建立精确的数学模型以及对模型的分析活动.狭义的讲,形式化方法是运用形式化语言,进行形式化的规格描述.模型推理和验证的方法.将形式化方法运用于软件工程实践当中的只要目的是保证软件的正确性. 软件生命周期中的形式化转化策略:常用转化策略.直接转化策略和运用半形式化表示的中间转化策略. 进行模型化的过程中涉及到三种系统模型:现实世界.模型表示和计算机系统.