作者yauhh (姚呵呵)
看板OOAD
标题Re: [资料] 神之物件 (God object, Blob AntiPattern)
时间Fri Apr 4 14:54:19 2008
不管是不是OO,写程式都该保有通用性,循「以较少做最多」的原则.
有一些功能是当需要时执行,另一些却是当物件存在就要执行.
大家支持神物的理由是:拜托不要把物件装得太中规中矩.
反对神物的理由就是:不要让一件东西包山包海.
我想神物所犯的问题就是让一件通用的物件变得太具有特殊性.
若有人写一个物件在建构时同时做了A功能与B功能,
别人用此物件就必须做「建构 - 挡A功能 - 挡B功能 - 呼叫物件另外存在的C功能」
才能单纯使用物件的C功能.
此例,对原case是做了最少,对其他人却要做更多.
神物也让沟通变得麻烦,因为只有作者知道此物件建构时同时会做A功能与B功能,
却让其他人感到疑惑,如果不知道物件建构子的副作用,反而遇到所谓难以维护与了解
的程式码.
想要神物,多弄个带参数的神物建构子不很麻烦,且满足通用与特殊二方面的需求.
仅保留之前引文;没有反对哪一位.
※ 引述《H45 (!H45)》之铭言:
: ※ 引述《greatroy (雪碧猪)》之铭言:
: : OOP应该是帮助我们建构系统的一种手段,
: : 而不应是为了OO而OO才是,
: : 能写出高深精简的程式码固然是件好事,
: : 但已经看过太多为了突显技术,
: : 而写出一堆往後连自己都难以了解及维护的程式码,
: : 这样似乎有些本末倒置, 不是吗?
: : 另外, OO的另一个目的就是让Team work更加顺畅,
: : 没人能维护的程式码, 对Team而言,
: : 不过是一团垃圾.
: 一个好的程式码,固然着重於容易阅读与容易修改
: 自己写出来的程式码,不只要让未来的自己看得懂,也要让别人也看得懂
: 撰写完整的注解以及说明文件是其中一个解决办法
: 但是物件导向分析与设计的主要目标仍然是为了满足使用者的需求
: 所有的分析以及设计都是源於需求而发展出来的
: 以物件导向做这些事情,与过去的功能导向呈现明显的对比
: 功能导向是把整个需求看成是一条一条的功能
: 做出了所有的功能就等於满足了所有的需求
: 物件导向是把整个需求看成是一个一个的物件
: 做出了所有的物件就等於满足了所有的需求
: 而物件导向优於功能导向的原因是物件比较容易被模型化、比较容易被人类理解
: 以此概念衍生出来的 UML, 帮助程式设计师建立软体模型
: 在实作之前就先设计好软体蓝图,可以让程式发展得更顺畅
: 比起功能导向的设计方式,物件导向似乎更适合塑模呢!
--
※ 发信站: 批踢踢实业坊(ptt.cc)
◆ From: 59.112.227.69