第25個冬天

新的學期一開始 一般第一堂學期初的課程 老師們都會做課程簡介跟公布自己的聯繫方式 讓同學有問題可以做溝通聯繫 此時同學們開始做筆記紀錄好老師的聯繫方式 但老師學期間某一天 突然聯繫方式又更改了!!!!! 可能有教職員系統更新.... 可能剛好老師換手機.... 諸如此類 一旦通知沒有到位 則可能導致學生無法聯繫到老師 我們怎麼實踐 老師電話號碼一更改所有學生的紀錄也都全自動更新呢? 這時類似的關係 我們會有一個學生及一個老師的類別 學生主要是用來描述某某....紀錄到的老師電話 老師則有電話號碼的資訊 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

這次來探討策略模式 一時想不到捨麼好的開場..... 我們用一個遊戲場景來描述好了 你在一個遊戲中選擇了一個戰士角色然後你會在不同情況去更換武器裝備 這個時候腦海中好像浮現出了一連串的if  else if ...else if.... 程式碼 若於後期又有其他武器擴充.... 那你寫好的程式又要改一些東西 不過客戶需求是否有改變呢?  其實是在合理範圍中做修改 因此要想一些比較好的設計方案利於後續的擴充.... 而可以改變一要有捨麼就寫捨麼的寫程式習慣...... 所以我們可以將客戶需求往未來做延伸考量 當客戶目前只提說想要 槍、手榴彈、刀...等三樣武器時 應該想到之後可能還會有其他類似弓、長槍之類的武器擴充 那就可以把武器整個抽象概念拉出來訂製一個基底(Base)規格(Base Class) 因為我們不確定未來還有捨麼規格變化或添加 當戰士需要用槍來做攻擊時 就在內部呼叫槍的物件 透過呼叫fighting間接去掉用使用槍來戰鬥的策略 但這麼設計會存有捨麼問題?? 這樣有無符合開閉原則(對擴充開放,對修改封閉)嗎? 開放 -->OK 封閉 --> No!!!!  戰士的class很容易需要改變!! 其實刀、手榴彈、槍這些武器對於戰士而言通通都是一種戰鬥策略 因此他根本不care到底具體使用哪種因為他可隨時抽換!!!! 策略模式(Strategy Pattern) 代表著將 一系列演算過程或流程封裝在一起 且使它們 可以相互替換 讓算法獨立於使用它的用戶(物件)而獨立去做變化 通常具備三種角色來應付所謂的策略模式 (1)抽象策略類(介面) (Strategy ):定義所有支援特定策略算法的介面。 (2)具體策略類(Concrete Strategy):藉由Strategy介面來實作具體算法 (3)環境類(Context)(策略類擁有者):內部維護一個Strategy物件的參考。 可定義一介面來讓Strategy訪問其當中資料。 應用環節: 比方像是在設計一套商場收銀系統各種商品有不同種促銷方案 依照不同時段(中秋、過年)有滿多少打幾折等等 會一直不停變換 解決方案: Step1.定

What is pattern? In software engineering, a design pattern is a general repeatable solution to a commonly occurring problem in software design. A design pattern isn't a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations. 模式一詞主要包含 *一個特定環節、情況 *一個問題 一個解決方案 透過總結三個元素來達成可重複使用的設計方案 設計模式(Design Pattern):主要探討針對一些特定工程環節不斷出現的問題，加以描述該問題解決方案的核心思路。藉此來無數次使用已有的解決套路更可省去重複相同工作 描述軟體物件相互溝通的既定架構用以解決特定環節中的問題。 主要是針對一個 特定環節(境)問題 的一套和程式語言無關的 (C#,JAVA,VB.NET,C++...etc皆可實踐)解決思路方案 單例(子) 模式(Singleton Pattern): 確保一個Class只會有一個 唯一實體 ，並且提供一個全域訪問方法。 ==>有點類似像獨生子女的一胎化政策 應用環節: (1)一個系統跳窗不允許可以重複跳多個。(常見!!!!) 你有一個表單視窗一次只能填寫送出一個但是有人可以同時開啟多個時.... 這時同樣是小明送表單卻有好多個小明..... (2)一個樓層存在多台列印機，要來設計一個打印機管理程式。 我們會設計一個負責管理列印機的class用來處理列印相關任務協調 包含從列印佇列中提取文檔 此時每次都new 一個實體 會導致同一時間多個物件都在調用列印佇列提取的衝突 解決方案: Step1.首先將建構子用private修飾，屏蔽透過直接實體化來訪問該類構造與創立新實體。 Step2.使用static關鍵字來宣告一個靜態屬性(

想想當我們以前在使用國語辭典時若不透過部首、筆劃來查對應出現頁數時 此時一定是從第一頁慢慢翻直到找到目標為止 因此索引在日常生活中很常用到 包括以前常見的電話簿用姓名筆劃、住址來排 書本前面的章節用字母來排序等等 結構化查詢一般的運作 採用 Full-Scan 機制 或 循序搜尋(Sequential Search) -->未先排序 也就是 當你要在一萬筆資料群的資料表中查找到特定匹配條件的 單筆或多筆資料時 會 從頭掃描整張表一遍 直到查詢到目標為止。 想當然這種查詢是十分沒有效率的!! 所以在資料結構應用上使用不同演算做法 會有不同回饋!!! 舉例: 同樣一組數據序列 用不同查詢下所產生的比對次數就有明顯的差異 循序(線性)查詢 非循序(非線性)查詢 E.g. 二元(分/岔) 資料庫之索引 這裡我們拿一本書最後頭的索引 來做一個生活例子比擬 你會看到一些常看或市面上書籍 後面都會有依照可能是英文字母開頭做排序的 以中文字典的部分則可能是用  部首、注音、筆畫 去做查詢索引 https://www.prismnet.com/~hcexres/textbook/indexing.html http://gimilee.pixnet.net/blog/post/209620930-大推薦－全方位造詞造句大詞典 藉由  Index 我們可以更快速找到我們想要的目標開頭為X的字眼 在SQL Server這部分是採用 B-Tree(B型束狀結構) B樹(B-Tree)  在你瞭解這個名詞前 可能需要先有關於樹的一些先備知識 Tree資料結構專術語(行話)介紹: 1.節點(Node):每一項data(資料值) -->A ,B ,C......,L 2.樹根(Root):每一棵樹最上層之節點 --> A 3.子樹(Sub Tree):去除樹根(A)後 , 所剩之以B、C、D為樹根之三棵樹也就是「子樹」 4.邊(Edge):節點之間的連線。 5.樹葉(Leaf):下方無串接任一節點(最末端)。換言之，就是分支度為0的節點，又稱終端節點。 6.樹林(Forest):去除樹根後剩餘的部分(三個子樹)即 「樹林」 7.階

於前一篇大致上介紹到MVC核心理念 這裡要對於Model運算部分做一個加強示範 於上一篇示範練習比較強調在於Controller的溝通 這篇我們要來練習簡單四則運算中 別於以往的嵌入介面層設計我們把計算的流程定義於Model當中 於Controller中去呼叫做計算然後再更新顯示給View CalculatorModel.java 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 /* * To change this license header, choose License Headers in Project Properties. * To change this template file, choose Tools | Templates * and open the template in the editor. */ package com. cal . Model ; /** * * @author chous */ public class CalculatorModel { private int calculationVal; public void addTwoNums ( int firstNum, int secondNum){ calculationVal = firstNum + secondNum; } public int getCalculationValue (){ return calculationVal; } } CalculatorView.java 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 37 38 39 40 41 42 43 44 45 46 47

JAVA MVC架構實作 在一些現今程式應用中 很常聽到和使用到的MVC(Model-View-Controller) 最早於1978年的 特里夫·林斯高格  ( Trygve Reenskaug )  所提出的軟體工程三層架構 其主張介面層邏輯要跟業務層邏輯分離 不應該混在一塊 使程式各自類可以各司其職(符合單一職責原則) 利於後續程式增多後的維護 Model : 負責儲存及維護一些來自前端使用者介面資料的流程邏輯 (使用者輸入了資料後進行捨麼計算....) View : 舉凡使用者和前端介面互動的相關流程邏輯接歸屬於View來做控制 (捨麼時候要跳窗，當按下捨麼按鈕做....) Controller : 介於Model和View兩者之間的溝通橋樑 主要接收View使用者於前端介面的資料後再傳遞給Model並接收來自Model回傳結果 再丟還給View進行介面渲染(更新顯示)的流程。 這樣就不會於系統維護到後期時發生 因為過去都將Model  data處理邏輯部分的Code內嵌至View而造成的 因為後續有需要用多個不同的View要來顯示某些同一資料部分 而導致出現重複黏貼Model data code 處理的區塊 開發規格與工具 新增好專案後 建置好三個java package 資源package下存著一張400*200的底圖 針對View 新增一個繼承JFrame的可視化class 及設計面板 首先將預設新增的View JFrame中進入點程式移動至main中 於此的main區塊可先暫時註解掉(留著做針對該類中的 unit test也可以) 程式運行時會自動找main進入點於哪個class的java檔案去運行 針對View 類別 起初預設的程式碼 我們進行介面端的邏輯設計規劃 Defalt View.java 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 37 38 39 40 41 42 43 44 45