Re: [資料] 神之物件 (God object, Blob AntiPattern)
不管是不是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
討論串 (同標題文章)
本文引述了以下文章的的內容：
完整討論串 (本文為第 19 之 19 篇)：
OOAD 近期熱門文章
PTT數位生活區 即時熱門文章
0
18
