GoF デザインパターン 2009

GoFデザインパターン 2009
インフラ勉強会 2021-10-09 @miwarin

お題
● fukabori.fm で t_wada さんが言ってた
● 削除されたパターン・追加されたパターン

fukabori.fm で t_wada さんが言ってた
https://fukabori.fm/episode/49

「テスト駆動開発」著者Kent Beck 著／和田卓人訳
https://shop.ohmsha.co.jp/shopdetail/000000004967/
t_wada さんて？

「テスト書いてないとかお前それ〜」が私の代名詞になるまで。テスト駆動開発とともに歩んだキャリア
https://engineer-lab.findy-code.io/t-wada

● fukabofi.fm 49 の話題
○ オブジェクト指向プログラミングについての誤解が広まった
○ デザインパターンの狙い
○ デザインパターンと自動テストとリファクタリング
○ デザインパターンが更新された

● オブジェクト指向プログラミングについての誤解が広まった
○ 誤解「オブジェクト指向プログラミング＝継承を使いこなすこと」
○ 継承が深すぎると誰を変更すると何に影響があるのか把握できない。依存が深すぎて何が起
きるか分からない。もはやスパゲティコード

継承が深い図

● デザインパターンの狙い
○ 継承ではなく、委譲やコンポジションを使って実装する
■ 委譲: デリゲート
■ コンポジション: オブジェクトの組み合わせ
○ デザインパターンを再利用するのではなく、デザインパターンを利用する側を再利用する
■ 実装に対してではなく、インターフェースに対してプログラミングする
■ 実装がどうであれ、このように振る舞ってほしい

利用する側を再利用する
デザインパターン
クライアント
クライアント
デザインパターンを再利
用するのでなく
デザインパターン

● デザインパターンと自動テストとリファクタリング
○ プログラミング言語などの年代
■ 1983 C++ : C with ClassesからC++に名称を変更した
■ 1985 「The C++ Programming Language」
■ 1994 python 1.0
■ 1994 「Design Patterns」
■ 1996 Java (JDK 1.0)
■ 1996 ruby 1.0
■ 1999 「Refactoring」(リファクタリング)
■ 2000「Extreme Programming Explained(XPエクストリーム・プログラミング入門)
■ 2002「Test-Driven Development (テスト駆動開発入門)」
■ 2008 Hudson 1.200
■ 2011 Jenkins 1.396

● 自動テストとリファクタリングの影響
● あとから設計変更すればよさげ
● 実際にコードを書いてみて変更に強い設計を作っていく
● ここは変わるだろうと備えてデザインパターンで設計しておいたけど実際に
はそこは変化しなかった
● 現状との差異が生じたらリファクタリングする

● リファクタリングしてデザインパターンへ近づけていく
● リファクタリングのゴールがデザインパターン

Design Patterns 15 Years Later: An Interview with Erich Gamma, Richard Helm, and Ralph Johnson
https://www.informit.com/articles/article.aspx?p=1404056
● 2009年のGoF(Gang of Four) へのイン
タビュー
○ Erich Gamma
○ Richard Helm
○ Ralph Johnson
○ John Vlissides (故人)
● リファクタリングによってデザインパ
ターンに近づけていく
● プログラミング言語自体にデザインパ
ターンが実装されている場合もあるな
ら不要だよね

● 旧
○ 生成
○ 構造
○ 振る舞い
● 新
○ コア(よく使われるパターン。これだけでも覚えておくとリファクタリングが捗る)
○ 生成
○ ペリフェラル(コアではない)
○ そのほか
カテゴリが変更された

カテゴリが変更された

● 削除されたパターン
○ Singleton
○ Adapter
○ Bridge
○ Chain of responsibility
○ Memento
○ Observer
● 追加されたパターン
○ Dependency Injection
○ Type Object
○ Null Object
○ Extension Object
パターンも変更された

削除されたパターン
● Singleton
● Adapter
● Bridge
● Chain of responsibility
● Memento
● Observer

Singletonパターン
インスタンスを 1 つしか作ってはいけない
● メリット: 資源(データベースやファイルシステム)を管理するインスタンスをただ 1 つ提供する
● デメリット: ようするにグローバル変数なので、すべてのコードがこのシングルトンの実装を知って
いなければならない。結合度が高くなる

public class Singleton
{
private static Singleton theInstance = null;
private Singleton() { }
public static Singleton Instance()
{
if (theInstance == null)
theInstance = new Singleton();
return theInstance;
}
}
Singletonパターン
「アジャイルソフトウェア開発の奥義」p. 231

Adapterパターン
既存のクラスをラッピングしてインターフェースを追加する

interface ProductPrice{
public int getPrice();
}
class Product{
private int cost;
public int getCost(){
return cost;
}
}
class ProductAdapter implements ProductPrice{
private Product product = new Product();
public int getPrice(){
return product.getCost();
}
}
Adapterパターン
Adapter パターン
https://ja.wikipedia.org/wiki/Adapter_%E3%83%91%E3%82%BF%E3%83%BC%E3%83%B3
interface ProductPrice{
public int getPrice();
}
class Product{
private int cost;
public int getCost(){
return cost;
}
}
class ProductAdapter extends Product implements
ProductPrice{
public int getPrice(){
return this.getCost();
}
}
継承を使って実装委譲を使って実装

Bridgeパターン
抽象化と実装を分離する(?)

class DrawingAPI:
__metaclass__ = ABCMeta
@abstractmethod
def draw_circle(self, x, y, radius):
raise NotImplementedError(NOT_IMPLEMENTED)
class DrawingAPI1(DrawingAPI):
return f"API1.circle at {x}:{y} - radius: {radius}"
class Shape:
__metaclass__ = ABCMeta
drawing_api = None
def __init__(self, drawing_api):
self.drawing_api = drawing_api
@abstractmethod
def draw(self):
@abstractmethod
def resize_by_percentage(self, percent):
Bridgeパターン
Bridge pattern
https://en.wikipedia.org/wiki/Bridge_pattern

class CircleShape(Shape):
def __init__(self, x, y, radius, drawing_api):
self.x = x
self.y = y
self.radius = radius
super(CircleShape, self).__init__(drawing_api)
def draw(self):
return self.drawing_api.draw_circle(self.x, self.y, self.radius)
def resize_by_percentage(self, percent):
self.radius *= 1 + percent / 100
class BridgePattern:
@staticmethod
def test():
shapes = [
CircleShape(1.0, 2.0, 3.0, DrawingAPI1()),
]
for shape in shapes:
shape.resize_by_percentage(2.5)
print(shape.draw())
BridgePattern.test()
Bridgeパターン

Chain of responsibilityパターン
処理をするオブジェクトと、処理の順番を制御するオブジェクトを分離する

import java.util.*;
abstract class Logger {
public static final int ERROR = 3;
public static final int NOTICE = 5;
public static final int DEBUG = 7;
private final int mask;
protected Logger(int mask) { this.mask = mask; }
// The next element in the chain of responsibility
protected Logger next;
public Logger setNext(Logger l) {
next = l;
return this;
}
public void message(String msg, int priority) {
if (priority <= mask) {
writeMessage(msg);
if (next != null) {
next.message(msg, priority);
}
}
}
abstract protected void writeMessage(String msg);
}
Chain of Responsibility パターン
https://ja.wikipedia.org/wiki/Chain_of_Responsibility_%E3%83%91%E3%82%BF%E3%83%BC%E3%83%B3

class StdoutLogger extends Logger {
public StdoutLogger(int mask) { super(mask); }
@Override
protected void writeMessage(String msg) {
System.out.println("Writting to stdout: " + msg);
}
}
class EmailLogger extends Logger {
public EmailLogger(int mask) { super(mask); }
@Override
System.out.println("Sending via email: " + msg);
}
}
class StderrLogger extends Logger {
public StderrLogger(int mask) { super(mask); }
@Override
System.out.println("Sending to stderr: " + msg);
}
}

public class ChainOfResponsibilityExample {
public static void main(String[] args) {
// Build the chain of responsibility
final Logger l =
new StdoutLogger(Logger.DEBUG).setNext(
new EmailLogger(Logger.NOTICE).setNext(
new StderrLogger(Logger.ERROR)));
// Handled by StdoutLogger
l.message("Entering function y.", Logger.DEBUG);
// Handled by StdoutLogger and EmailLogger
l.message("Step1 completed.", Logger.NOTICE);
// Handled by all three loggers
l.message("An error has occurred.", Logger.ERROR);
}
}

Mementoパターン
オブジェクトを以前の状態に(ロールバックにより)戻す

class Originator
class Memento
def initialize(state)
@state = state.dup
end
def state
@state.dup
end
end
attr_accessor :state
def save_to_memento
Memento.new(@state)
end
def restore_from_memento(m)
@state = m.state
end
end
describe Originator do
before(:all) do
@caretaker = Caretaker.new
@originator = Originator.new
@originator.state = "State1"
end
it "should have original state" do
@originator.state.should == 'State1'
end
it "should update state" do
@originator.state = "State2"
@originator.state.should == 'State2'
end
it "should save memento" do
@caretaker << @originator.save_to_memento
@caretaker.size.should == 1
end
以下略
Mementoパターン
Memento パターン
https://ja.wikipedia.org/wiki/Memento_%E3%83%91%E3%82%BF%E3%83%BC%E3%83%B3

Observerパターン
1 対多の関係
オブジェクトの変化があったとき、依存するすべてのオブジェクトへ通知される
● サブジェクト: 通知するひと
● オブザーバー: 通知を受け取るひと
実装としては、サブジェクトに登録しておいたメソッドを順に呼び出すだけ。同期処理です。
非同期処理の場合は「イベント」や「メッセージ」などと呼んで区別することもあるらしい。

Observerパターン
Observer pattern
https://en.wikipedia.org/wiki/Observer_pattern
class Observable:
def __init__(self):
self._observers = []
def register_observer(self, observer):
self._observers.append(observer)
def notify_observers(self, *args, **kwargs):
for obs in self._observers:
obs.notify(self, *args, **kwargs)
class Observer:
def __init__(self, observable):
observable.register_observer(self)
def notify(self, observable, *args, **kwargs):
print("Got", args, kwargs, "From", observable)
subject = Observable()
observer = Observer(subject)
subject.notify_observers("test", kw="python")

追加されたパターン
● Dependency Injection
● Type Object
● Null Object
● Extension Object

Dependency Injectionパターン
あるオブジェクト(サービス)を別のオブジェクト(クライアント)に渡す

class Client
{
private $service;
public function __construct(Service $service)
{
$this->service = $service;
}
public function doSomething()
{
$this->service->doSomething();
}
}
class Service
{
{
}
}
class Client
{
private $service;
public function __construct()
{
$this->service = new Service();
}
{
$this->service->doSomething();
}
}
class Service
{
{
}
}
Dependency Injectionパターン
やはりあなた方のDependency Injectionはまちがっている。
http://blog.a-way-out.net/blog/2015/08/31/your-dependency-injection-is-wrong-as-I-expected/
DIパターン
DIパターンでない

Type Objectパターン
型を動的に作成する
どのような型が必要になるのか、前もって分からない場合に使う

Type Objectパターン
class TypeObject
def initialize(name, value)
@name = name
@value = value
end
def get(name)
return @value
end
end
def main(argv)
t1 = TypeObject.new("a", "AAAA")
t2 = TypeObject.new("b", "BBBB")
puts(t1.get("a"))
puts(t2.get("b"))
end
main(ARGV)

Null Objectパターン
何もしないオブジェクト
0 と 1 を同一視する
Null だったらこうする、という条件分岐をオブジェクトへ分離する

Null Objectパターン
Employee e = DB.getEmployee("Bob");
if(e != null && e.isTimeToPay(today))
e.pay()
Employee e = DB.getEmployee("Bob");
if(e.isTimeToPay(today))
e.pay()
「アジャイルソフトウェア開発の奥義」pp. 243-246
Null Objectパターンでない Null Objectパターン

Extension Objectパターン
既存のクラス階層構造に影響を与えずに機能を追加する

Extension Objectパターン
class BOM
def initialize
@ext ||= {}
end
def add(name, ext)
@ext[name] = ext
end
def get(name)
return @ext[name]
end
end
def toXML
return "XML"
end
def toCSV
return "CSV"
end
def main(argv)
bom = BOM.new
bom.add("XML", toXML)
bom.add("CSV", toCSV)
puts(bom.get("XML"))
puts(bom.get("CSV"))
end
main(ARGV)
例:
部品一覧を扱うクラスがある。このクラスに XML や
CSV へ出力する機能を追加したい。
toXML や toCSV というメソッドを追加する手もあるが、
単一責任の原則(SRP)に反する。

GoF デザインパターン 2009

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie GoF デザインパターン 2009

Ähnlich wie GoF デザインパターン 2009 (20)

Mehr von miwarin

Mehr von miwarin (9)

GoF デザインパターン 2009