iT邦幫忙

design pattern相關文章
共有 491 則文章
鐵人賽 自我挑戰組 DAY 6
設計模式探索 系列 第 6

技術 [Day 6] 觀察者模式 (1)

RECAP 有了各種設計模式的定義,就可以用短短的名詞來代表背後的概念,幫助我們在設計程式時有效溝通,準確傳達想法;經由學習這些經過時間考驗與綜合眾工程師智慧的...

鐵人賽 Software Development DAY 11

技術 【DAY11】Factory模式 - 來當工廠老闆吧!

今天介紹的是工廠模式,因為會跟明天的 Abstract Factory 有點關係,所以先來說一下,這個工廠模式,相對我們前幾天談到的其他模式都還要單純很多,也很...

鐵人賽 Software Development DAY 10

技術 【DAY10】Bridge模式 - 矛盾的解釋

讓我們沿用上一篇轉接頭的例子,在之前我們都一直是以「螢幕」作為一端去跟電腦做連線,假設現在我們把範圍擴大,將螢幕做分類,可能有不同規格類型的螢幕會需要跟電腦做連...

鐵人賽 自我挑戰組 DAY 5
設計模式探索 系列 第 5

技術 [Day 5] 策略模式 (3)

集大成的UML 經過前幾天的內容,以上都了解後,應該也可以順利地組合出最終UML的樣子了:(參考原書以draw.io繪製)可以看到會變的部分被封裝了起來,其他行...

鐵人賽 Software Development DAY 9

技術 【DAY9】Strategy模式 - 強化我的轉接器

我們在昨天有留下一個問題,假設今天變成是 AVG的外接口想要去轉成 HDMI,那是不是就要再多一個 AvgToHdmiAdapter 的類別出來並且一樣去繼承...

鐵人賽 自我挑戰組 DAY 4
設計模式探索 系列 第 4

技術 [Day 4] 策略模式 (2)

第二個原則 接續昨天的問題,我們要來看如何更彈性的設計出這個架構!那要怎麼應用呢?書本提到了第二個原則: 針對"介面"而非"實作...

鐵人賽 自我挑戰組 DAY 3
設計模式探索 系列 第 3

技術 [Day 3] 策略模式 (1)

軟體開發的不變真理─改變 設計程式時,當我們收到需求之後,要做出來很容易,要做得好的上下限卻差很多。如果你能確保這軟體寫完用一次就不需要了,未來不支持更新,那你...

鐵人賽 Software Development DAY 8

技術 【DAY8】用『新』看物件導向的世界

前面兩天有提到 Facade 和 Adapter 兩種設計模式,裡面的範例程式碼內容基本上是環繞在三個物件導向中的基礎概念:物件、封裝、抽象類別。今天的主要目的...

鐵人賽 Software Development DAY 7

技術 【DAY7】Adapter模式 - 外接螢幕的故事

外接螢幕的故事 之前疫情嚴重時有居家工作一段時間,而公司的筆電是14吋,在家的話想當然就是要爽爽外接大螢幕嘛(竊笑)!於是我就跑去賣場買了一台27吋的螢幕,配合...

鐵人賽 Software Development DAY 6

技術 【DAY6】Facade模式 - 今晚...我想來點麥當勞(上)

今晚…我想來點…麥當勞 大家應該都有去麥當勞點餐過的經驗,如果今天我想來個二號餐(雙層牛肉吉士堡),不可能走進去跟做薯條的人說我要一份薯條,再去漢堡區說我要一份...

鐵人賽 Software Development DAY 23
玩轉C# 進階學習之旅 系列 第 23

技術 玩轉C#之【設計模式-Design Pattern】

小心設計模式別亂用 介紹 設計模式就是過去的人,根據常見的軟體設計的問題,提出的解決方案。設計模式總共有23種,根據情境分成三大類型,建立型、結構型、行為型。...

鐵人賽 自我挑戰組 DAY 2
設計模式探索 系列 第 2

技術 [Day 2] 前置準備─ OO與UML

前言 萬事起頭難,這兩天就先從最初的設計模式入門開始,開始感受設計模式的用處,並掌握設計模式的幾項大原則吧! 物件導向 Design Pattern充分使用OO...

鐵人賽 自我挑戰組 DAY 17

技術 [Dot Net Core] (延伸應用) 17. 為何使用 Dot Net Core 框架 - 解耦服務於 MicroService

在一些微服務的規劃中,微服務類似將單體系統切割成多個高內聚的獨立模組,且服務與服務間鬆耦合。 假設在單體系統,改了某個業務邏輯與相關的程式,卻於另外一個功能模...

鐵人賽 Software Development DAY 5

技術 【DAY5】學設計模式,WHY?

前面幾天提到物件導向範型以及基礎的UML圖,相信大家應該對物件導向有基本的認識了,所以話說回來,為什麼我們要學習設計模式(Design Pattern)呢? 來...

鐵人賽 Software Development DAY 4

達標好文 技術 【DAY4】UML (統一建模語言)

UML是一種建立程式模型的圖形語言,可以想像成是帶有語意的圖形記號,圖可以分成兩大類,一種是表達結構用的圖,而另一種是表達行為用的圖形,所有分類如下圖所示。...

鐵人賽 Software Development DAY 3

技術 【DAY3】什麼是物件導向範型?(下)

讓我們延續上一篇的例子~ 學生不僅僅是學生 假設現在的學生不僅僅是一般大學生了,還包含研究生,現在要他們交作業,但不同類型的學生要交的作業不同,做的事情也不一樣...

鐵人賽 Software Development DAY 2

技術 【DAY2】什麼是物件導向範型?(上)

範型定義 範型(paradigm),即為典型範例 - 標準結構化程式設計比較異同的方式,可以想像成一種程式設計風格。常見的範型還有:函數式程式設計、指令式程式設...

鐵人賽 自我挑戰組 DAY 12

技術 [Dot Net Core] (圖解系列) 12. 以最簡單方法驗證架構中 Resolved Singleton 特性

在上一節,透過描述我們看到controller class在被產生instance過程中,其中IActionInvokerFactory 會被Resolve成...

鐵人賽 Software Development DAY 1

技術 【DAY1】初心者前言

這是第一次參加IT鐵人賽,也是我剛入軟體業的第一年,對於物件導向以及程式架構也都還是懵懵懂懂,所以希望能夠藉由這次的參賽,讓我對於 OOP & Desi...

鐵人賽 自我挑戰組 DAY 1
設計模式探索 系列 第 1

技術 [Day 1] 深入淺出設計模式- 前言

前言 去年的鐵人賽挑戰leetcode連續刷題一個月(Leetcode刷題筆記),熟悉C++的基本語法與邏輯鍛鍊,今年則是希望可以趁這個機會來好好閱讀軟體設計的...

技術 Backend System in Microservice Architecture: Where Does data store?

Backend System in Microservice Architecture: Where Does data store? At recent ye...

技術 為什麼 CQRS - Why CQRS

為什麼 CQRS - Why CQRS CQRS (Command Query Responsibility Segregation) 命令查詢職責分離模式,在...

技術 【Day35】[演算法]-常見的演算法策略Algorithmic Patterns

分治法(Divide and conquer) 又稱分而治之法,是最常被使用的策略方式,原理是將一個難以直接解決的大問題,依據相同的概念分割成多個子問題,再各個...

鐵人賽 Software Development DAY 30

技術 IT鐵人DAY 30-學習物件導向與Design Pattern之心路歷程

  終於來到了最後一天,希望看完前29篇文章的人能夠把所學的知識內化,當寫程式的時候有碰到什麼問題,可以先想想看有什麼方法能夠優化現階段的程式,並且減少不必要的...

鐵人賽 Software Development DAY 30

技術 Observer 觀察者模式

今天要談到的觀察者模式也是很常見的一個模式,常出現在有兩個以上需要互相溝通的物件之間 問題 假設有個物件 A 想要獲得物件 B 的更新資訊,但實際上 A 不知道...

鐵人賽 Software Development DAY 29

技術 IT鐵人DAY 29-Template Method 模板模式

  今天要要介紹最後一個 Behavioral Patterns,也就是Template Method,我想大多數的人看到這個名字就可以約略的猜到這個模式是用來...

鐵人賽 Software Development DAY 29

技術 Command 命令模式

當一個請求 (request) 進入系統之後,通常我們就會立即的處理它。但如果我們不想這麼直接的去處理這些請求,而是先讓這些需求排隊、依序進入,甚至做一些預先處...

鐵人賽 Software Development DAY 30
Hey! Go Design Patterns 系列 第 30

技術 DAY 30:Strategy Pattern,選定不同的策略來執行

2023/04/05 更新: 為了避免本文章散落在不同網站,之後統一由部落格更新,再麻煩從部落格查看~ 什麼是 Strategy Pattern? 設計相...

鐵人賽 Software Development DAY 28

技術 IT鐵人DAY 28-Observer 觀察者模式

  今天要學習的是觀察者模式,它主要的作用是設定一個訂閱機制,當被訂閱的物件有發生事件時就會去通知所有訂閱的物件,現在讓我們來認識它吧! 問題情境與解析   ...

鐵人賽 Software Development DAY 28

技術 Chain of Responsibility 責任鏈模式

今天開始進入到 Behavioral design patterns,這一類的模式著重於物件之間的溝通與責任分配,就讓我們接下去一起看看吧 Chain of R...