OOP:使い回しとたらい回し？
このワークシートはMath by Codeの一部です。
GoFのデザインパタン、全23種類のうち21種類に触れてきました。
今回はGOFの残り２パタン、使い回しとたらい回しを扱います。
それって何でしょう？
１．フライ級は軽くするための使い回し
フライ級Flyweight:
細かいオブジェクトのNewを減らし、
「使い回し」で使用メモリを軽く（フライ級に）します。
細かいけれどパーツとして多数生成されがちなクラスというものがあります。
重複してパーツをNewしてインスタンス数をふやすと、使用メモリが増加しますね。
それを避けるために、同一のパーツは使い回しをしてメモリを軽くしよう。
たとえば、定積分ingegral(f,x,a,b)を図形的文字列CharFigsとして表示するとしたら、
∫^a_b f dx となるとします。この文字列のパーツがCharsだとする。
∫^0_100 f dx =∫^0_10 f dx+∫^10_100 f dx
つまり、
という[数式N]ではパーツCharsは リストm={∫,f,dx,0,1,=,+ }だけですね。
美しく繰り返す属性は文字フォントです。これらを並べたNの中では、
共有させる情報、内部の固有情報（intrinsic)としておけば、情報量がへります。
実際、上のgeogebraのMathオブジェクトもフォントの指定はできません。
しかし、共有させない、変えてよい情報（extrinsic)もありますね。
リストmの要素が数式Nの左から何番目に出てくるかはCharsの内部に閉じ込めるのではなく
外のCharFigsに出す（exにする）ものです。
このように使い回しをするには属性の内部(in)と外部(ex)を区別が必要になりますね。
２．責任分割つなぎはたらい回しか？
責任分割つなぎパタンChainOfResponsibility：
対応する責任を分割して複数の責任オブジェクトに分割して連結すれば、
その鎖を順次わたると要求するオブジェクトが見つかるかもしれません。
対応側は要求側に全面対応する必要がなく、責任と関係ない要求は答えずに次に回せるので、
対応する責任オブジェクト（Supportの子クラス）は責任が軽くて楽です。
要求する側は、たらい回しにあうかもれませんが、
責任体制が充実していれば、もし複数の要求がある場合、ワンストップサービスを受けることができるかもしれません。
実装イメージはデコレタパタンパタンで、要求者を受け入れてできる対応があればして出す、
厚化粧のインスタンスを作ればよいのではないでしょうか。
責任分割つなぎパタンはたらい回しパタンという悪名がありますが、
たらい回しをされて、なにもしてくれない方がいい場合もありますよ。
たとえば、入力のバリデーションは、会員登録画面を作るときは必要ですね。
「パスワードを半角英数字で英字と数字の両方があり12文字以上で、大文字を１つは含んでください。」
とメッセージがでます。
入力サポートクラスSupportは入力文字を引数にして、リターンはそのままです。
まずい入力にはメッセージを表示します。
１つのクラスですべてをまかなうとif～elifが長くなります。
そこで、責任分割をしましょう。
半角英字なしを見つける子クラス、
半角数字なしを見つける子クラス、
文字数が12未満を見つける子クラス、
Upperクラスの文字数が0であることを見つける子クラス、
それらが、互いのことは気にせず、バラバラに、
しかし連続してミス発見をサポートしてくれます。
このたらい回しで無事何もしてくれないと、
正しい入力だったことがわかります。
たらい回しでスルーされることが、正しいことの証明になるんですね。
＜実装例＞
# ChainOfResponsibility.py
class Support:
"""入力サポート（責任の鎖）の抽象クラス"""
def __init__(self):
self._next = None
def set_next(self, next_handler):
self._next = next_handler
return next_handler # 鎖を数珠繋ぎにしやすくするため自身を返す
def check(self, password: str) -> bool:
# 1. 自分の担当するエラーをチェックする
if self._has_error(password):
self._print_message()
return False # ミスを発見したのでここでストップ
# 2. 自分に問題がなければ、黙って次の門番にたらい回しする
if self._next is not None:
return self._next.check(password)
# 3. 最後の鎖まで誰も何もしてくれなかったら「合格」！
return True
def _has_error(self, password: str) -> bool: raise NotImplementedError()
def _print_message(self): raise NotImplementedError()
# ==========================================
# 各門番の実装（互いのことは気にせずバラバラに作る）
# ==========================================
class LengthCheck(Support):
"""文字数が12未満を見つける"""
def _has_error(self, password: str) -> bool: return len(password) < 12
def _print_message(self): print("エラー: パスワードは12文字以上で入力してください。")
class DigitCheck(Support):
"""半角数字なしを見つける"""
def _has_error(self, password: str) -> bool: return not any(c.isdigit() for c in password)
def _print_message(self): print("エラー: 数字を最低1文字は含んでください。")
class AlphaCheck(Support):
"""半角英字なしを見つける"""
def _has_error(self, password: str) -> bool: return not any(c.isalpha() for c in password)
def _print_message(self): print("エラー: 英字を最低1文字は含んでください。")
class UpperCheck(Support):
"""大文字の文字数が0であることを見つける"""
def _has_error(self, password: str) -> bool: return not any(c.isupper() for c in password)
def _print_message(self): print("エラー: 大文字を最低1文字は含んでください。")
# ==========================================
# 【作動テスト】
# ==========================================
print("=== Validation Chain: Start ===\n")
# 鎖を構築する（長さ ➔ 数字 ➔ 英字 ➔ 大文字）
gate = LengthCheck()
gate.set_next(DigitCheck()).set_next(AlphaCheck()).set_next(UpperCheck())
# 入力例1: 短すぎる入力
print("--- 入力例1: 'abc' ---")
if gate.check("abc"): print("結果: 登録成功！")
# 入力例2: 大文字だけを忘れた惜しい入力
print("\n--- 入力例2: 'gofpattern2026' ---")
if gate.check("gofpattern2026"): print("結果: 登録成功！")
# 入力例3: すべての門番を「たらい回し」された完璧な入力
print("\n--- 入力例3: 'GoFPattern2026' ---")
if gate.check("GoFPattern2026"):print("結果: 登録成功！")
[OUT]
=== Validation Chain: Start ===
--- 入力例1: 'abc' ---
エラー: パスワードは12文字以上で入力してください。
--- 入力例2: 'gofpattern2026' ---
エラー: 大文字を最低1文字は含んでください。
--- 入力例3: 'GoFPattern2026' ---
結果: 登録成功！
３．振り返り
＜振り返り＞
デザインパタンはあなたにとって、
後期ウィトゲンシュタインの哲学のように
思考のくせやゆがみを映し出す鏡と感じられたでしょうか。
デザインパタンは抽象的なだけあって、
それは多様な具体的な場面や状況にあてはめることができます。
極端な構造化をしているので、それが思考に刺激をもたらします。
そこは、数学・哲学に似ているところですね。
ただ、数学よりもさらに哲学に似ています。
哲学はそのままでは何も解決してくれませんから。
数学は何かしら、計算してくれたり、何かに使えたりします。
しかしデザインパタンはコードは作ったりしましたが、ただのサンプルであり
なんの強制力も力もありません。一般性もありません。
ただ、そこから見えてくる発想、感じられる構造化の特徴
それが少しでもあるという希望をもって載せています。
GOF本にも実装はいろいろできるでしょうけど。。。的なゆるーい感じの記述が多いですね。
サンプルコードがたとえば、javaでかかれていていると、
Javaのもとクラス名とインスタンス名などの冗長さやアクセス指定や型の厳密さなど、
java言語の重さと見た目の複雑さに圧倒されがちです。
テーマがGOF本のように迷路ゲームや図形エディタなど興味深いものであって、
その手前で挫折する可能性があります。
GOF本ではこのコードを動かすとこうなりますね。というような手取り足取りはありません。
結城本にはコードが動かせるCDROMがついているので、寄り添っている感が強いですね。
でも、しょせんJava言語です。なれている人はどうということはないでしょうけどね。
このGeogebraのページでかいた「Pythonで学ぶデザインパタン」は
Pythonなので、多くの人がコードにつまづく可能性は低くなります。
また、私はプログラミングの教師でもないし、数学の教授でもありません。
ただ、プログラミングも数学も好きだというだけの暇な人です。
だから、穴だらけの記述・表現ですが、商売につなげる気もないので、
体裁を無理やり整えることもしてません。
ただ、身近な例、GOF本の要約によるパタン紹介、Pythonコード、振り返り、直観的アプレット
できるだけ、この流れを目指しました。
とりあえず。このページを区切りとします。
しかし、もう次を考えています。
GOF本は時代背景からみてもOOPがさかんなときの本です。
しかし今は純粋関数型のパラダイムの言語や書き方がさかんになってます。
この続きはその方向でいきます。
つづく。