Something in Ours

Chapter 1 Welcome to Design Patterns: an introduction OO Basics: Abstraction Encapsulation Polymorphism Inheritance OO Principles: Encapsulate what varies. Favor composition over inheritence. Program to interfaces, not implementations. OO Patterns: Strategy - defined a family of algorithms, encapsulates each once, and makes them interchangeable. Strategy lets the algorithm vary independently from clients that use it. Chapter 2 Keeping your Objects in the know: the Observer Pattern OO Principles: Strive for loosely coupled designs between objects that interact. OO Patterns: Observer - defines a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically. Chapter 3 Decorating Objects: the Decorator Pattern OO Principles: Classes should be open for extension but closed for modification. OO Patterns: Decorator - Attach additional responsibilities to an objec...

根據 文件 ，Doctrine 有 Pessimistic Lock，又分為兩種： LockMode::PESSIMISTIC_WRITE：對應至 MySQL 的 Select FOR UPDATE LockMode::PESSIMISTIC_READ：對應至 MySQL 的 Select LOCK IN SHARE MODE 差別在於 LOCK IN SHARE MODE 會將在 row 的資料鎖定(row-level lock)，在非同一交易(Transaction)下，不給寫入，其他交易可以讀取， 且可以繼續 Select LOCK IN SHARE MODE 。而 FOR UPDATE 不僅鎖定該資料，在非同一交易下，不給寫入，其它交易可以讀取， 但不能 Select LOCK IN SHARE MODE 。MySQL 文件有更詳細的比較與情境使用的說明，參考 網址 。 現在問題是，我們要完全採用 ORM 來處理資料。Doctrine 的文件提到 EntityManager::find 可以採用 Pessimistic Lock， 但 find 是透過 id 來處理 。而其他 find 系列函數（包括：findAll, findBy, findOneBy）皆不支援 LockMode。 因此，勢必要有方法來「透過非 id 來使用 Pessimistic Lock」。透過查看原始碼，簡單的方法是有的，解法之範例如下： 19 public function depositAction() 20 { 21 22 $em = $this->getDoctrine()->getManager(); 23 24 $em->transactional(function ($em) { 25 $entityName = 'AcmeTrainingBundle:Account'; 26 $lockMode = LockMode::PESSIMISTIC_READ; 27 $orderBy = null; 28 $...

前由 我有全區的電話資料，問題在於我要依不同里別來製作出電話簿。結果如下圖： 單純採用合併列印無法達成我的需求。解決方法係用「功能變數」儲存上一個里別，與現在里別進行比較：若不同，則換頁。不過，這樣功能變數還蠻長的。最後，我還是採用 C# 來解決。 解決方案 用 C# 控制 WORD 中合併列印的「資料來源 Data Source」，給予不同里別的「sqlstatement」。迴圈處理不同的里別即可。但可預見其處理過程會很慢，不過還好，我可以不用在意它，有跑出結果即可。 程式碼 IList<string> areas = new List<string>() { "後壁", "侯伯", "嘉苳", "土溝", "嘉田", "嘉民", "菁豊", "崁頂", "後廍", "墨林", "菁寮", "新嘉", "頂長", "平安", "仕安", "竹新", "新東", "長安", "頂安", "福安", "烏樹" }; string root = @"D:\"; // 根目錄 string data = root + @"\data.docm"; // 資料檔（即資料來源） string template = root + @"\template.docx"; // 已設定好格式與合併欄位的 Word 檔 string output = @"d:\Final"; // 輸出之資料夾 object oMissing = System.Reflection.Missing.Va...

設計模式 建立型模式 結構型模式 行為型模式

表示一個作用於某物件結構中的各元素之操作。它使你可以在不改變各元素之類別的前提下，定義作用於這些元素的新操作。 適用於資料結構相對穩定的系統 它把資料結構和作用於結構上的操作之間的耦合解脫開，使得操作集合可以相對自由地演化。 其目的是要把處理從資料結構分離出來。 其缺點係不易增加新的資料結構

給定一個語言，定義它的文法的一種表示，並定義一個解釋器，解釋器使用該表示來解釋語言中的句子。 當有一個語言需要解譯執行，並且你可將該語言中的句子表示為一個抽象語法樹時，可使用解譯器模式。 基本架構圖 實例架構圖

運用共用技術有效地支援大量細粒度的物件。 享元模式Flyweight執行時所需的狀態是有內部的、也可能有外部的。內部狀態儲存於ConcreteFlyweight物件之中，而外部物件則應該考慮由用戶端物件儲存或計算。當調用Flyweight物件的操作時，將該狀態傳遞給它。 基本架構圖 實例架構圖

用一個仲介物件來封裝一系列的物件互動。仲介者使各物件不需要顯式地互相參考，從而使其耦合鬆散，而且可以獨立地改變它們之間的互動。 優點 Mediator的出現減少了各個Colleague的耦合，所以可以獨立改變和複用各個Colleague類別和Mediator 把物件協作進行了抽象，將中介作為一個獨立的概念並將其封裝在一個物件中，這樣焦點的物件就從物件各自本身的行為轉移到它們之間的互動上來，亦即站在一個更宏觀的角度去看待系統。 缺點 由於ConcreteMediator控制了集中化，於是就把互動複雜性變為了仲介者的複雜性，這就使得仲介者會變得比任何一個ConcreteColleague都複雜 一般應用於一組物件已定義良好，但是複雜的方式進行通訊的場合 基本架構圖 實例架構圖

使多個物件都有機會處理請求，從而避免的發送者和接收者之間的耦合關係。將這個物件連成一條鏈，並沿著這條鏈傳遞該請求，直到有一個物件處理它為止。 基本架構圖 實例架構圖

將一個請求封裝為一個物件，讓你可用不同的請求對客戶進行參數化；請求排隊或請求日誌，以及支援可取消的操作。 基本架構圖 實例架構圖

將抽象部份與它的實現部份分離，使它們都可以獨立地變化。 實現指的是抽象類別和它的衍生類別用來實現自己的物件。 實現系統可能有多角度分類，每一種分類都有可能變化，那麼就把這種多角度分離出來讓它們獨立變化，減少它們之間的耦合。 基本結構圖 實例結構圖

保證一個類別僅有一個實體，並提供一個存取它的全域訪問點

提供一種方法依序存取一個物件中各個元素，而又不暴露該物件的內部表示 .Net 的迭代器實現 IEnumerator 支援對非泛型集合的簡單迭代介面 public interface IEumerator { object Current { get; } bool MoveNext(); void Reset(); } IEnumerable公開枚舉數，該枚舉數支援在非泛型集合上進行簡單迭代。 public interface IEnumerable { IEumerator GetEnumerator(); }

將物件組合樹形結構以表示「部份-整體」的層次結構。組合模式使得用戶對單個物件和組合物件的使用具有一致性。 當發現需求中是表現部份與整體層次的結構時，以及你希望用戶可以忽略組合物件與單個的不同，統一地組合結構中的所有物件時，就應該考慮用組合模式。

將一個類別的介面轉換成客戶希望的另外一個介面。Adapter模式使得原本由於介面不相容而不能一起工作的那些類別可以一起工作。 在雙方都不太容易修改時，再使用轉接器模式轉接。

當一個物件的內在狀態改變時允許改變其行為，這個物件看起來像是改變了其類別。 主要解決的是，當控制一個物件狀態轉換的條件運算式過於複雜時，把狀態判斷邏輯表示不同狀態的一系列類別當中，可以把複雜的判斷邏輯簡化。

提供一個建立一系列相關或相互依賴物件的介面，而無須指定它們具體的類別。 用簡單工廠來改進抽象工廠

觀察者模式一種一對多的關係，讓多個觀察者物件同時監聽某主題物件。物件再狀態發生變化時，會通知觀察者物件，使他門能夠自動更新自己。 動機 將一個系統分割成一系列相互協作的類別有一個很不好的副作用，那就是需要維護相關物件間的一致性。我們不希望為了維持一致性而使各類別緊密耦合，這樣會給維護、擴展和重用都帶來不便。 一個物件的改變需要同時改變其他物件時。且它不知道到底有多少物件有待改變時，應該考慮使用觀察者模式。