[Design] Data Validation

• 理論上應要前後端都檢查，這樣自然能防止有人故意要搞破壞，但會有實務上的考量。在後端每執行一件事情都是一個 loading，拖慢速度，因此也可能因為前端已檢查而省略後端部份，但只能在後端才能做的檢查，自然是不可省略。

• 對資料的任何處理(delete/add/update)，都應該用 post，以避免他人僅透過即能執行其功能。

• method的建立能以是有特地目的功能，還是僅執行固定的功能，而沒有特別意義的。

[Web] 新增資料處理

分頁會共用 session (Ref: [Web] session ID with browser)

所以顯示頁面時 把 Object(ex: Token) 放入 session 且將 Object 的 key 傳給頁面

model.put(ATTRIBUTE_TOKEN, token.getKey);
session.setAttribute(token.getKey(), token);

頁面 submit 時將 key 帶在路徑上

然後便能由 key 取出 session 中相對應的 token

藉此區別不同 tab 間的新增資料

[UML] Relationship

[一般化關係] (Generalization)

• 透過類別定義屬性和操作，所以日後針對同類別的一群物件，就可以使用相同的方式對待它們。
• 不過有時候，這些物件並不是全然相同，可能大部分的屬性和操作相同，但是少部分的屬性和操作卻不同。在這種情況下，類別之間的一般化關係就派上用場了。
• 在一般化的過程中，我們將特殊類別裡頭通用的屬性和操作記錄到一般類別裡，因此透過一般化關係，特殊類別可以繼承(Inheritance)一般類別裡的通用屬性與操作。
• 由於特殊類別透過繼承，可以直接重用(Reuse)一般類別裡的屬性、操作和方法，節省開發成本。
• 變動發生需要改版時，也只需要改版一般類別，節省維護成本。

[結合關係] (Association)

• 類別之間最常見的關係。
• 可以透過檢核下列兩項要件，判斷是否採用結合關係：
• 在企業領域的專業概念裡，兩種物件之間有一種固定不變且需要保存的靜態關係。
• 在資訊化時，系統會用到這些靜態關係，而且必須將它們存到資料庫。

[聚合關係] (Aggregation)

• 是一種特殊的結合關係。
• 繼承了結合關係的特質，而且還獨有「整體-部分」(Whole-Part) 的特質。
• 可以透過檢核下列三項要件，判斷是否採用聚合關係：
• 在企業領域的專業概念裡，兩種物件之間有一種固定不變且需要保存的靜態關係。(繼承自結合關係的要件)
• 在資訊化時，系統會用到這些靜態關係，而且必須將它們存到資料庫。(繼承自結合關係的要件)
• 在企業領域的專業概念裡，兩種物件之間有Whole-Part的靜態關係。(聚合關係獨有的要件)

[組合關係] (Composition)

• 是一種特殊的聚合關係。
• 繼承了結合關係，以及聚合關係的「整體-部分」(Whole-Part) 的特質，還獨有全然擁有Part物件的特質。(Existence-Part)
• 可以透過檢核下列四項要件，判斷是否採用組合關係：
• 在企業領域的專業概念裡，兩種物件之間有一種固定不變且需要保存的靜態關係。(繼承自結合關係的要件)
• 在資訊化時，系統會用到這些靜態關係，而且必須將它們存到資料庫。(繼承自結合關係的要件)
• 在企業領域的專業概念裡，兩種物件之間有Whole-Part的靜態關係。(繼承自聚合關係的要件)
• Part物件只能連結一個Whole物件，且Whole物件被註銷(Destroy)時，Part物件必須一塊被註銷。(組合關係獨有的要件)

Summary
Association -> Aggregation -> Composition


* Reference
- UML Blog: 1.4.6-一般化關係
- UML Blog: 1.4.7-結合關係
- UML Blog: 1.4.8-聚合關係
- UML Blog: 1.4.9-組合關係

[Java] Abstract Class Purpose

abstract 就是不允許被 new 出來直接用的東西。

[Design] SQL condition

若 A、B、C 都要限制條件 x

可以以外層條件來寫 A.x = B.x and A.x = C.x

這樣 value 只要寫一次就可以了

......

form A

join A.x = B.x and A.x = C.x

where A.x = 'value'

[Design] Object relationship

假設 A B C 間的關係如下:

A <-> (many-to-one) <-> B <-> (one-to-many) <-> C

但如果按照此關係，設 List在 B 並不符合實務

因為這樣當我們去找 A 相對的 B，B 便會找出其他我們不須要的 A

所以反過來置放。

還有，實際上可看見 A 和 C 沒有直接的對應關係。

[Design] Design Software

軟體開發不是光靠程式設計 | 專欄 | iThome online

* Coding只是開發過程中的一部份工作
把程式設計等同於軟體開發，當然是很大的誤解。除了程式設計之外，軟體開發中涉及更多的層面。而其中，是否擁有正確的軟體開發觀念，絕對影響到是否能更順利地開發出有品質的軟體。

* 你會需要有這麼一個版本讓所有的人（包括客戶、使用者、產品經理、出錢的大老闆）清楚看到一個可以運作的系統，他們會對系統應該要是什麼樣的面貌更有概念，才更知道軟體功能該如何調整。

* 許多有經驗的開發者會知道，可以設定一個遠大的目標，但是，要先做出一個功能不那麼強、但是足夠穩定、能夠正常運作的第一個版本，接著再以這個版本為基礎，持續地演化及改進。

* 在開發的時候，要讓需求、規格盡量保持不變，甚至在時間有限時、而期限又不允許更動時，還要適度將那些較不優先的功能自開發範圍中削除

[Design] 取資料方式

* 在撈取資料(SQL)欲新增一固定條件(a)時，可有以下幾種做法:

1. hard-code "a" 在 SQL 中。

2. 從資料庫中撈取 a 值。每次檔案更改都需重啟，所以如果僅在啟動時去load進來，那麼使用時會有錯，應該要有re-load機制或是使用前再去load。

- 放置在外部 property file

- 放置在 db table: 方便user修改


因為 a 算是個固定要加入的查詢條件，並不會變動，且不修改太多原本的程式，所以選擇使用 hard-code。

[Design] Validation on Business, Service, Web layer

對是否把校驗當作商業邏輯這個問題，存在著正和反兩種意見，而Spring提供的驗證模式(和資料綁定)的設計對這兩種意見都不排斥。特別是，校驗應該不應該被強制綁定在Web層，而且應該很容易本地化並且可以方便地加入新的驗證邏輯。基於上述的考慮，Spring提供了一個Validator介面。這是一個基礎的介面並且適用於應用程序的任何一個層面。



* Reference
- 5. Validation, Data Binding, and Type Conversion

[SQL] PK and FK

盡量使用 PK 當 FK

否則 join/物件連結 時會很慢