Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Application Design 勉強会 #4
Search
Kazuki Chigita
July 17, 2019
Technology
0
240
Application Design 勉強会 #4
Application Design 勉強会 #4
Kazuki Chigita
July 17, 2019
Tweet
Share
More Decks by Kazuki Chigita
See All by Kazuki Chigita
Claude CodeでサクサクTestコードを移行しよう
chigichan24
2
640
Live Update notificationのつかいどころ
chigichan24
0
240
不具合調査とTest
chigichan24
1
400
Flutterと難読化
chigichan24
0
5.2k
Building Android and looking into the Android System
chigichan24
2
4.1k
DroidKaigiカンファレンスアプリの歴史からみるアプリアーキテクチャのこれまでとこれから
chigichan24
3
3.4k
継続的に機能開発を進めながら行うマルチモジュール化
chigichan24
2
6k
Application Design 勉強会 #12
chigichan24
0
83
Application Design 勉強会 #10
chigichan24
0
99
Other Decks in Technology
See All in Technology
Okta Identity Governanceで実現する最小権限の原則
demaecan
0
190
個人でデジタル庁の デザインシステムをVue.jsで 作っている話
nishiharatsubasa
3
5.2k
Amazon Athena で JSON・Parquet・Iceberg のデータを検索し、性能を比較してみた
shigeruoda
1
170
プレイドのユニークな技術とインターンのリアル
plaidtech
PRO
1
480
AIプロダクトのプロンプト実践テクニック / Practical Techniques for AI Product Prompts
saka2jp
0
120
CNCFの視点で捉えるPlatform Engineering - 最新動向と展望 / Platform Engineering from the CNCF Perspective
hhiroshell
0
140
Behind Postgres 18: The People, the Code, & the Invisible Work | Claire Giordano | PGConfEU 2025
clairegiordano
0
150
オブザーバビリティが育むシステム理解と好奇心
maruloop
3
1.5k
ViteとTypeScriptのProject Referencesで 大規模モノレポのUIカタログのリリースサイクルを高速化する
shuta13
3
220
「タコピーの原罪」から学ぶ間違った”支援” / the bad support of Takopii
piyonakajima
0
150
ハノーファーメッセ2025で見た生成AI活用ユースケース.pdf
hamadakoji
1
500
デザインとエンジニアリングの架け橋を目指す OPTiMのデザインシステム「nucleus」の軌跡と広げ方
optim
0
120
Featured
See All Featured
GitHub's CSS Performance
jonrohan
1032
470k
Fireside Chat
paigeccino
41
3.7k
The Invisible Side of Design
smashingmag
302
51k
The MySQL Ecosystem @ GitHub 2015
samlambert
251
13k
GraphQLとの向き合い方2022年版
quramy
49
14k
Building Better People: How to give real-time feedback that sticks.
wjessup
370
20k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
127
54k
Why You Should Never Use an ORM
jnunemaker
PRO
59
9.6k
Fashionably flexible responsive web design (full day workshop)
malarkey
407
66k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
667
130k
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
658
61k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
48
9.7k
Transcript
Application Design勉強会 13-15章 Wed Jul 17 Kazuki Chigita
はじめに • 第3部の意義 • デザインパターンを学ぶ.
今⽇話すこと • Commandパターン • ActiveObjectパターン • TemplateMethodパターン • Strategyパターン •
Facadeパターン • Mediatorパターン
今⽇話すこと • Commandパターン • ActiveObjectパターン • TemplateMethodパターン • Strategyパターン •
Facadeパターン • Mediatorパターン
Commandパターン • 以下のようなinterfaceを用意する. • 利用するときはCommandを実装する. • 何がうれしいの? • この構造にすれば,Commandの実装クラスの詳細を 知らずとも利用できる.
• do()をすれば全てのコマンドが操作できる.
Commandパターン • 以下のようなinterfaceを用意する. • 利用するときはCommandを実装する. • 何がうれしいの? • この構造にすれば,Commandの実装クラスの詳細を 知らずとも利用できる.
• do()をすれば全てのコマンドが操作できる. シンプルなCommandパターンでは メソッドは⼀つ
Commandパターン • 以下のようなinterfaceを用意する. • 利用するときはCommandを実装する. • 何がうれしいの? • この構造にすれば,Commandの実装クラスの詳細を 知らずとも利用できる.
• do()をすれば全てのコマンドが操作できる. シンプルなCommandパターンでは メソッドは⼀つ それぞれでdo()をoverrideする.
Commandパターン(例1) • Transactionでの利用 • 使う側は同様にTransactionを実装(override) • メリット1 : ビジネスロジックとチェック機構の分離 •
メリット2 : 一時保存 / 時間差実行の実現
Commandパターン(例1) • メリット1 : ビジネスロジックとチェック機構の分離 • validate() はGUI等からも使われる有効性の チェックが具体的な登録処理を含むのは危ない. •
validate()はデータベースの詳細を知ることがな いので,ここでも分離ができている. • メリット2 : 一時保存 / 時間差実行の実現 • validate()の後,すぐにexecute()を呼び出す 必要はない. • execute()だけバッチ処理的に時間差で実行しても なんの問題もない. • 分離することで,一時的に状態を保持しておく構造 ができている.
Commandパターン(例2) • Undo機構の実現 • Commnadの実装先でdo()の処理内容を記憶す る必要がある. • undo()はdo()に依存しているので抱き合わせ て実装を考える必要がある.
Commandパターンまとめ • 普通はクラスに多くのpublic methodをもたせ るがそうではなくごく少数に抑えることで, 見通しを良くする. • interfaceの中に複数のメソッドを入れても,そ の存在意味を分離させたり(Transactionの例), 抱き合わせたり(Undoの例)できる.
今⽇話すこと • Commandパターン • ActiveObjectパターン • TemplateMethodパターン • Strategyパターン •
Facadeパターン • Mediatorパターン
ActiveObjectパターン • Commandパターンの利用例 • イベント駆動型やマルチスレッドを実現するた めのパターン ActiveObjectEngine : Commandのリストを持ち, これらの実⾏を管理する
Command : Interface.Commandパターン. SleepCommand: Commandの実装クラス
ActiveObjectパターン
ActiveObjectパターン ActiveObjectEngine itsCommands SleepComand HogeComand (wakeupCommandとして持っていると仮定)
ActiveObjectパターン ActiveObjectEngine itsCommands SleepComand HogeComand (wakeupCommandとして持っていると仮定)
ActiveObjectパターン ActiveObjectEngine itsCommands SleepComand SleepTimeの間これを繰り返す. HogeComand (wakeupCommandとして持っていると仮定)
ActiveObjectパターン ActiveObjectEngine itsCommands SleepComand SleepTimeの間これを繰り返す. HogeComand (wakeupCommandとして持っていると仮定) SleepTimeが終わったらこっちが登録される.
ActiveObjectパターン ActiveObjectEngine itsCommands SleepComand SleepTimeの間これを繰り返す. HogeComand (wakeupCommandとして持っていると仮定) SleepTimeが終わったらこっちが登録される.
ActiveObjectパターン
ActiveObjectパターンまとめ • 本来はブロッキング処理等で処理を止めて, itsCommandsを複数のスレッドにわたしてあ げると簡易的なマルチスレッド処理に実現がで きる. • イベント駆動型の真髄はこういうパターンだ. • Commandパターンをうまく活用している例.
今⽇話すこと • Commandパターン • ActiveObjectパターン • TemplateMethodパターン • Strategyパターン •
Facadeパターン • Mediatorパターン
TemplateMethodパターン • 課題 : 似た処理がアチラコチラに出てくる. パターン化した処理がコピペで煩雑に使われて いる. • 解決法 •
共通化や概念化できる大きな枠としての処理を abstract class(抽象基本クラス)に持っていく. • 上の概念化されたクラスを継承先で具体的なクラス 実装を行う. • 例 : Bubble Sortをどう扱うか
TemplateMethodパターン • BubbleSorter という abstractクラスを作成し, ここに大枠の実装の処理を委ねる. • これを継承するクラスで詳細を実装することで 共通化を図る. BubbbleSorter
{abbstract} IntBubbbleSorter DoubleBubbble Sorter
None
TemplateMethodパターン • 問題点 • BubbleSorterという名前にしてることからも分かる 通り,swap(index: Int)や, outOfOrder(index: Int)は,他のアルゴリズム で利用できない.
• BubbleSortのための再利用性はあるが, 他アルゴリズムのために使うことができない.
今⽇話すこと • Commandパターン • ActiveObjectパターン • TemplateMethodパターン • Strategyパターン •
Facadeパターン • Mediatorパターン
Strategyパターン • 課題 : 似た処理がアチラコチラに出てくる. パターン化した処理がコピペで煩雑に使われて いる.(TemplateMethodパターンと同じ) • 解決法 •
汎用的な部分や概念的な部分を抽象クラスで実装せ ずに,Handleクラスのようなものに持っていく • 実装すべきものはinterfaceに切り出す • 例 : Bubble Sortをどう扱うか
None
None
Strategyパターン • 良い点 • TemplateMethodパターンの課題を解決している. • SortHandleを他のソートパターンでも利用できる • interfaceで切り出しているので, DIPと相性がいい.
• BubbleSortのみにとどまらない再利用性が高い. • 問題点 • 実装が少し多くなる • (こういうパターンはStrategyパターンで解決 するのが現状良さそう)
今⽇話すこと • Commandパターン • ActiveObjectパターン • TemplateMethodパターン • Strategyパターン •
Facadeパターン • Mediatorパターン
Facade & Mediator パターン • 課題 : クラス間の結合度を下げたい. • 解決方法
• Façade • 上から抑える(wrapする) • Mediator • 下から抑える(Mediatorにやってもらう)
Facade & Mediator パターン • 課題 : クラス間の結合度を下げたい. • 解決方法
• Façade • 上から抑える(wrapする) • Mediator • 下から抑える(Mediatorにやってもらう)
Facadeの場合 P224 図15-1より
Facadeの場合 P224 図15-1より 集約点を作る
Mediatorの場合
Mediatorの場合
使い分け • FacadeとMediatorの使い分け • 明示的に方針を示したいとき.集約点を作りたいと き→Façade • 非明示的に方針を課したいとき→Mediator