發表文章

目前顯示的是有「設計模式」標籤的文章

Design Pattern_Skill_6_建造者模式(Builder Design Pattern)

圖片
最近在和同事合作過程,就時常會跟SD 合作。 SD主要工作會負責設計一些DB 的Schema  , 撰寫系統預期流程和規格書、畫面操作互動 SD通常就會向我們這些PG規劃和分配任務、負責監工等等 SD通常會跟院內User 一起討論瞭解需求後 在經過自己的統整、文件撰寫來和PG溝通User需要的是捨麼請幫忙開發 PG可能在開發階段只負責程式撰寫工作而不會cover到系統設計規劃 這之間的關係就好比 找多個工人施工蓋房子和一個監工分配工作任務的工頭一樣 這裡以生產產品為例 一個產品從製造、加工都會有不同製程步驟 如下是要取得待在生產線上工作的特定認證(必須精熟和落實會這些工法) 1 2 3 4 5 6 7 8 public interface IBuilder { void BuildPartA (); void BuildPartB (); void BuildPartC (); } 一個產品中會區分不同的組件在製造生產(需透過不同組件組合而成) 不同產品會有需要對應生產不同的組件 1 2 3 4 5 6 7 8 9 10 11 12 13 14 public class Product { private List< object > lsParts = new List< object >(); public void Add ( string part) { this .lsParts.Add(part); } public string ListParts () { return "Product Parts:" + string .Join( "," , lsParts.ToArray()) + "\n" ; } } 負責在產線中製造、加工的作業工程人員 會實踐具體的特定產品規格生產工法流程 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36...

Design Pattern_Skill_5_責任鏈模式(Chain of Responsibility Pattern)_經費申請加簽邏輯實踐

圖片
在公司當中通常 都會跑一些申請簽核單、跑公文 要申請經費之類的 可能會跑類似表單簽核的 這裡就以經費大小來模擬介紹一次CRP Hander : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 using System ; using System.Collections.Generic ; using System.Linq ; using System.Text ; using System.Threading.Tasks ; namespace ResponsibilityChainPattern { public abstract class Hander { public Hander successor; public void SetSuccessor (Hander successor) { this .successor = successor; } public abstract void HandleRequest (CostAndBudget costAndBudget); } } CostAndBudget : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 using System ; using System.Collections.Generic ; using System.Linq ; using System.Text ; using System.Threading.Tasks ; namespace ResponsibilityChainPattern { public class CostAndBudget { private string name; private int amount; public CostAndBudget ( string name, int amount) { ...

Design Pattern_Skill_4_簡單工廠模式(Simple Factory Pattern)

圖片
在軟體系統設計當中 創建型模式:主要是針對處理物件創建相關情況以某種方式控制物件實體化的設計模式 試圖就實際情況來切換較合適方法進行創建物件 主要核心思想是 將系統使用到的具體Class封裝起來 隱藏具體Class Object的建立與結合 創建型模式: (1)物件創建型模式:將物件實體化過程部分移至另一個物件中 (2)類別創建型模式:將其物件實體化過程移置子類中 在設計過程中時常會提到要對抽象(介面或抽象類)進行程式編碼設計 而不是對具體(實際物件)進行程式編碼設計 舉例要做一個比薩 就建立一個Pizza Class 做一個麵包則建立一個 Bread Class 一直透過new來實體化物件 這是典型的一個針對具體的設計 隨著時間流逝系統程式碼量倍增情況也影響到後期維護的複雜及工作量 不管後續要做捨麼都要創建新類別實在很麻煩 此時我們想到一種方法 有沒有可能我們設計一種Class是專門負責創建物件的 就好像一座工廠要做pizza或麵包 我們只要去調用該Factory class某一個方法透過傳指定參數來實作並回傳特定物件 此模式就是所謂的「簡單工廠設計模式」 ============================================================== 一家剛起步不久的Pizza店中的程式人員 負責幫忙開發pizza的系統 首先它知道pizza有如下工序 備料(準備起司絲、肉片)、 製作(稈麵團、加入蠔油)、 烘烤(統一30分鐘)、 完成(用紙箱裝盒外帶) 之後還有下訂單等業務 一開始推出口味有起司火腿、德國香腸、原味火腿口味的 所以他就直接寫了負責Pizza專屬工序的Class 對應三種不同口味的Class 還有負責訂單的Class 負責Pizza專屬工序的Class package OrignalApp ; /** * * @author chous */ public class Pizza { public void prepare (){ System . out . println ( "備料:準備起司絲、肉片" ); } public void make (){ ...

Design Pattern_Skill_3_觀察者模式(Observer Pattern)_電子郵件註冊及取消訂閱通知_老師課堂聯繫方式通知

圖片
新的學期一開始 一般第一堂學期初的課程 老師們都會做課程簡介跟公布自己的聯繫方式 讓同學有問題可以做溝通聯繫 此時同學們開始做筆記紀錄好老師的聯繫方式 但老師學期間某一天 突然聯繫方式又更改了!!!!! 可能有教職員系統更新.... 可能剛好老師換手機.... 諸如此類 一旦通知沒有到位 則可能導致學生無法聯繫到老師 我們怎麼實踐 老師電話號碼一更改所有學生的紀錄也都全自動更新呢? 這時類似的關係 我們會有一個學生及一個老師的類別 學生主要是用來描述某某....紀錄到的老師電話 老師則有電話號碼的資訊 Student Class 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 public class Student { private String _name= "" ; private String _phone = "" ; public Student (String strName) { this . _name = strName; } public String getName (){ return this . _name ; } public void setName (String strName) { this . _name = strName; } public String getPhone () { return _phone; } public void setPhone (String strPhone) { this . _phone = strPhone; } public void show () { System. out . println ( "Name:" +getName()+ "\nTeacher's phone number:" +getPhone()); } } Teacher Class...