「軟體設計須面對現實」的迴響

由：同人的生活派對 » 永續物件查詢之設計（其二）

同人的生活派對 » 永續物件查詢之設計（其二） — Fri, 03 Aug 2007 05:55:01 +0000

[...] 就拿本文的例子來說，一開始我們並不著眼於 design pattern 上，而是隨著設計不同著眼考量上，逐步發現並解決設計問題的過程中，讓 design pattern 躍然成形。讓問題來主導設計，而非讓設計使問題複雜化。當然，這也有賴於開發者在平常就要不斷地練習與思考，畢竟簡潔而富有彈性的設計不是一蹴可幾的呀。 [...]

由：同人的生活派對 » 好的設計源自於紀律

同人的生活派對 » 好的設計源自於紀律 — Wed, 23 May 2007 10:54:00 +0000

[...] 運用 design pattern 雖然是增加設計彈性的利器，但為了維護這些設計彈性，卻必須付出開發成本，當我們的設計充斥了「沒有用的彈性」時，就會浪費許多無謂的時間與資源，而不會再有足夠時間回應軟體需求的變化，及足夠的空間來容納真正需要的功能。以經濟學的角度而言，設計者須重視設計的機會成本，要為現實需求而設計，避免想太多而造成軟體設計的過度工程化的後遺症，而在設計上充斥著沒有必要的複雜度。以物件導向設計原則而言，抽象性愈高的套件，穩定度就要愈低，否則它就會沒有什麼用處，穩定度愈高的元件，抽象性就要愈低，否則它就會很難被重複使用[1]。總之，要設計彈性與功能兼具的系統，其實最關鍵的是務實與務虛兩種設計觀點能夠相互達到均衡。 [...]

由：同人的生活派對 » 改變軟體開發現況的藝術

同人的生活派對 » 改變軟體開發現況的藝術 — Mon, 16 Apr 2007 09:44:17 +0000

[...] 對於同學的看法，我的觀點是改變軟體開發現況與面對現實其實是不相衝突的兩件事。創新的好處除了是為了創造更大利潤外，更重要的是如圖中的紅線所示，使競爭對手無法輕易模仿而減少競爭壓力，當愈沒有競爭壓力時，我們更有足夠的時間與空間可以發揮創新的做法而形成良性循環。而創新並不代表忽略現實，它是一種態度而非制式的特定作法，亦即面對問題對方法論的採用、調適與熟練三部曲。不要因為現實而忽略方法，也不要因為方法而昧於現實，徧向任何一端其實只是道德上或是情感上的無意義爭論。 [...]

由：同人的生活派對 » 物件導向繼承與程式碼的重用

同人的生活派對 » 物件導向繼承與程式碼的重用 — Tue, 27 Mar 2007 10:16:42 +0000

[...] 我對所謂的 mix-in 並不熟悉，於是循線看了〈PHP 實踐 mix-in 概念之可行性〉，我發現石頭成所用的實作方式，類似 GOF Design pattern 的 State pattern，利用多型介面與自委託（self-delegate）技巧，可以讓物件同時具有多種型別的行為能力，甚至還可以動態改變物件的型別。如此看來，石頭成對 Java 介面的負面觀感其實是出自於對 Java 介面使用的誤解。提高程式碼的重用性用 Java 技術不是只能靠繼承而已，繼承的誤用只會造成程式碼的僵化與脆弱而已，而實作介面來面對多重繼承的問題，那並沒有比誤用繼承高明到那裡！Java 或其它採用靜態型別的物件導向程式語言，解決一個實體有多種型別的問題，不是靠繼承樹或重覆實作介面，而是利用組合（Composite）角色子型別（Role subtype），即所謂的角色塑模（Dealing with role），介面的使用是用來除耦－讓設計與實作分開而不是用來當成類別多重繼承的替代方案。 [...]

由：同人的生活派對 » 探討「用 real world 的直觀來認知 model」

同人的生活派對 » 探討「用 real world 的直觀來認知 model」 — Thu, 25 Jan 2007 08:35:51 +0000

[...] 在〈軟體設計需面對現實〉一文中，我曾針對 Gameboy 提出「用 real world 的直觀來認知 model ，這有點危險」提出個人的看法。對此 Gameboy 為其觀點 defend，然而卻在討論過程中卻因為對文字感受不同而造成一些爭論。因此，我認為有必要再進一步地探討「用 real world 的直觀來認知 model 」這個主題，以避免不必要的誤會。 [...]

由：GameBoy

GameBoy — Sat, 13 Jan 2007 14:59:37 +0000

想請教一下同人

敝人常用的 "結構" 一詞

在敝人的認知裡是包含語意這部份的

(也就是 model 要能呈現 problem domain 中的 Business Semantic

像 domain class 之間的 association

應該要能呈現豐富的語意

)

您對 "結構" 一詞

應該有比較嚴謹的定義

從您的 po 文看來

結構和 Semantic 似乎是分開來的 (也許是敝人對您的文字解讀有誤)

若您有空針對此問題回 po

願聞其詳

Thx

由：GameBoy

GameBoy — Sat, 13 Jan 2007 12:57:29 +0000

因為我看到太多 beginner 的抽象化是

僅僅源自於他們的直觀認知

而非從 Requirement 下手

但 Real World 中直觀的名詞

不見得適合作為 Domain Model 中的 Entity

但卻往往被他們誤植於 Domain Model 中 …

有一位網友 John 提到

不妨看看 Evans 的書

我想他指的應該是這一本書

Domain Driven Design …

由：GameBoy

GameBoy — Sat, 13 Jan 2007 12:34:02 +0000

其實我常常拿 Agile Software Modeling 中的

Salary System 去考別人

大概十個人有九個人

會很直觀地用繼承來 Model Person 和 Role 的關係

(他們多半認為 Role is a Person 是很直觀的)

以該書該例的 reauirement 來看

這樣的繼承手法

自然會導出惡果

(但是在某些 requirement 來說

用 is-a 才符合 Business Semantic

或同時存在 is-a 和 has-a 的語意)

這是敝人提出這樣說法的起因

並非 Challenge 葉先生

葉先生提出

「用 real world 直觀的認知來 model，沒什麼不好」

在他本 PO 文來看

我個人解讀他要強調的是

小心 Over Design

小心為 Pattern 而 Pattern

而敝人提出

「用 real world 直觀的認知來 model，這有點危險」

純粹只是從過去的經驗來提醒初學者罷了

文字有其侷限性

解讀因人而異

我個人

倒不會將

「用 real world 直觀的認知來 model，這有點危險」

和

「用 real world 直觀的認知來 model，沒什麼不好」

解讀為兩個衝突的觀點

(我個人解讀是兩人的出發點不太一樣)

因為葉 Sir 的直觀不會犯了以上過於 Technical 的問題

但往往我看到初學 OO 的人卻常常因他們的過於直觀而犯了這樣的問題

我到認為葉 Sir 這篇 PO 文

對於初涉 OO 的人

是ㄧ個很好的活教材

供諸君作參考

由：GameBoy

GameBoy — Sat, 13 Jan 2007 11:16:52 +0000

敝人同樣也在葉 Sir 另ㄧ篇 PO 文做了回應

http://www.lifeparty.idv.tw/bl.....8#comments

由：GameBoy

GameBoy — Sat, 13 Jan 2007 10:21:28 +0000

您好

我用ㄧ個例子來解釋

「用 real world 直觀的認知來 model，這有點危險」。

比如以 "汽車" 為例

"汽車" 在資產系統、或進銷存系統、或在某某系統

不一定都會被 model 成汽車

可能是 Item 或 Asset 或 anything else

也就是要看清楚 Problem Domain

(其實也就是您在本文的題旨)

會講出這樣的話

「用 real world 直觀的認知來 model，這有點危險」。

是看到有些初學者容易犯這樣的問題 (汽車不見得在業務需求裡都會被視為 "交通工具\")

但如果您就是認定敝人是以 Technical 的角度來看問題 (而非業務需求)

我想我也就是隨緣了

能在網上相遇自是有緣

如果我的文筆很容易造成您對我的誤解

That’s fine …

Have a nice year ….

GameBoy