Head First OOAD Ch7 tips

Bring Order to Chaos

在上一個章節中學習到了如何將大問題開始分組切成小模組了
但還不知道到底要從哪一個模組開始進行設計,這確實是個值得關注的議題...

除了我們知道可以將細部切分成小塊來進行分析設計之外,還得了解到
到底是如何讓這些獨立出來的小模組交互合作運行的,我們需要一個架構(Architecture)
才能確立出完整的運作關係

Architecture
Architecture is your design structure, and highlights the most important parts of your app,
and the relationships between those parts.

好吧 那到底如何來開始進行呢? 回想一下第一章的OO Principle
1. Make sure your software does what the customer wants it to do.
2. Apply basic OO principles to add flexiblity.
3. Strive for a maintainable, resuable design.

課程內文中有提到一段話
All of these features are about functionality, they focus on what the system has to do,
not on what OO principles or design patterns you use to build the system.

# The things in your application that are really important are architecturally significant,
   and you should focus on them first.

看到這裡不免要想到一個問題，既然我們是要討論架構那意思就是說要看得是整體各個模組間
的交互關係,那又為何要單獨的深入的去看單一的小模組呢?
其實在這裡我們要看得是,因為如果對每個小模組都不是很清楚他的用途那就無法知道 到底該如何將不同的功能模組串起來使用,所以對每個小模組深入了解,將有助於我們熟悉哪一個模組
比較重要而可以先從他開始進行...

在面對"Architecture"時有三個關鍵因素要考量
1. 鳩靜...哪個東西是最接近系統本質的
    # The essence of a system is what that system is at its most basic level.
2. 釐清那些你搞不清楚的領域或名詞,而且月早越好因為那將反應features有多困難
3. Coding的部份把最困難的提早拿出來解

災難還沒結束 雖然我們花了點心力去找出哪些是有可能最需要先被考量處理的,
仍免不了一番爭論到底誰先誰後,其實這時候處理的原則就轉向了"風險評估@@"
找出風險最大的來先解決 免得到最後時間不夠的時候才發現事情很危及了!!

# Focus on one feature at a time to reduce risk in your project.
# Don't get distracted with features that won't help reduce risk.

UML圖解區
使用一條實線的箭頭來指向其他的class, 此時是可以表示來源端class有參考到目的端的class,
就算僅僅只是在method中有使用到也可..

# The point of architecture is to reduce risk, and to create the order.
   在進行系統設計架構階段時,先別急著太快的步入實做coding,只要先能確保切分出來的模組
   是對得就可以了-->sometimes the best way to write great code is to hold off on writing code
   as long as you can.