2013年7月14日 星期日

GRASP General Responsibility Assignment Software Patterns

這是回顧Applying UML and Patterns一書(chapter 16 or 17?)上面提到的設計原則
  • information expert
  • creator
  • high cohesion
  • low coupling
  • controller
Q. 誰該被分配某個operations?
A. information expert提示將operation交付予擁有資訊的類別,也就是賦予相對應的責任,哪個內別有資訊,便應當負起處理該資訊的任務

Q. 誰該建立某類的物件?
A. creator告訴我們擁有下列狀況的腳色或許應處理
  • B聚合(aggregate)有 A
  • B包含(contain)A
  • B record A
  • B closely use A
  • B have initialization information of A

Q. 將某個方法或者屬性分配給...
A. low coupling是個好的選擇,提升coupling儘量避免,除非他們的關聯性是必要的

Q. 如何保持複雜度在一定程度內?
A. high cohesion,適當的模組化,避免使得物件之間的互動很難理解、很難維護、很難reuse

Q. 誰該處理系統輸入事件? (metaphor)
A. 將處理訊息的責任指派給兩種概念的類別:

  • 代表整個系統或者子系統
  • 代表系統事件所屬的使用者情節

最後該說的,如同作者提到的CRC (class reponsibility collaborator cards)卡是個好工具

參考資料

沒有留言:

張貼留言