このワークシートは[url=https://www.geogebra.org/m/twxxx3yq]Math by Code[/url]の一部です。
前回は、[br][br]数を画面に表示するエディタの例を使って、サブクラスに生成の詳細をまかせる「下請け工場」FactoryMethodパタン、大量表示や種別の増加にもサブクラスを増加せずに対応できる「コピー屋さん」Prototypeパタンを学びました。[br][br]今回は[b]抽象契約、AbstractFactory[/b]です。[br]和訳すると抽象工場になりますが、抽象工場は物を作らないので工場とは言えません。[br]ただの作るものを[b]抽象的に定めた契約[/b]です。だから、[b]抽象契約[/b]としました。[br][br]どういうことでしょうか。[br]これが必要になる状況のお話しから始まります。[br][br]********[br][br]ユーザーが増えると、エディタへの要求も増えます。[br]最初は「数を画面に表示する」だけでしたが、[br]「演算記号」も画面に表示してほしいという声も聞こえます。[br][br]さらに、表示モードの要求も出ています。[br]通常は今まで通りの「テキスト」でいいけど、印刷用には「美しい分数をTeX(テフ)形式」で表示したいという声も聞こえてきます。[br][br]ここで大問題が発生します。[br]部品の種類(縦軸):数、演算記号が1種類から2種類に増える。[br]表示のモード(横軸):テキストモードかTeXモードかを選べる。[br]これらが2×2=4倍と、「かけ算」で増えていくのです。[br]もし普通の下請け工場(Factory Method)のままでこれに対応しようとすると、「テキスト用の数工場」「TeX用の数工場」「テキスト用の等式工場」……と、工場クラスが倍々ゲームで爆発してしまいます。[br][br]これをすべて画面工作員([code]GraphicTool[/code])に丸投げにしたらどうなるでしょうか。[br]学習させて、手作業で組み替えさせるにはコストが高すぎます。[br]かといって、かけ算で増える要求すべてをフレームワークの中で対応するバージョンアップは不可能です。[br][br][br][b]#ブラック企業が作ったフレームワークの画面工作員の働き方の例[br]class GraphicTool:[br] def on_mouse_click(self, canvas, current_mode, element_type):[br] # 画面工作員が、モードと種類の組み合わせ(掛け算)をすべて知っていなければならない[br] if current_mode == "Text":[br] if element_type == "Number":[br] element = TextNumber("2026")[br] elif element_type == "Operator":[br] element = TextOperator("+")[br] elif current_mode == "TeX":[br] if element_type == "Number":[br] element = TexNumber("2026")[br] elif element_type == "Operator":[br] element = TexOperator(r"\sum")[br] canvas.add(element)[br][/b][br]もちろん、ユーザーが働くわけではないから、そんなの知ったこっちゃないかもしれません。[br][br]しかし、こういうべタなフレームワークのバージョンアップをいちいちしているようでは、[br]フレームワークの更新にかからる手間もかかり、バグも増えるだろうし、[br]ユーザーがフレームワークを手に入れるための値段の高くなるかもしれません。[br]
そこで登場するのが抽象契約です。[br][br]工作員にインスタンスの種類と表示が変わるたびにそれにあわせて、画面を作り替えることから[br]脱却してもらいましょう。[br]それが、[b][size=150][color=#0000ff]抽象契約(AbstractFactory)[/color][/size][/b]です。[br]互いに関連したり依存しあうオブジェクト群を、[br]「その具象クラスを明確にせずに生成するためのインターフェースを提供する」とGOF本にはあります。[br][br]今回の例にあてはめると、[br]「どっちの表示方法かを明確にしないで部品を作るための契約クラスを作る」ことになるのではないでしょうか。[br]だから、いきなり2軸の両方では考えないことにします。[br][br]まずは、フレームワークは、部品メニューの契約と、契約書通りの作業の実行だけにすることにします。[br][br]そこで、急にTex形式の表示ではなく、テキスト形式の表示についての構造改革をしました。[br]それが次のコードです。[br][br][b][size=150]<フレームを軽くして、ユーザーと契約する>[br][/size][/b][br]# ==========================================[br]# 【クラスC】抽象契約(部品メニュー契約)[br]# ==========================================[br]class AbstractExpressionContract:[br] """【抽象契約】具体的な表示モードには関与せず、[br] 必要な部品のラインナップだけを規定する。"""[br] def create_number(self, value):[br] raise NotImplementedError("契約に従って、数を返す仕組みを作ってください")[br] def create_operator(self, symbol):[br] raise NotImplementedError("契約に従って、演算子を返す仕組みを作ってください")[br][br][br]# ==========================================[br]# 【クラスA】画面工作員(部品契約画面に情報を入力して実行ボタンを押すだけ)[br]# ==========================================[br]class GraphicTool:[br] def __init__(self, contract_component: AbstractExpressionContract):[br] # 外の工場から届く「部品契約画面」[br] self.contract = contract_component[br][br] def on_mouse_click(self, editor_canvas):[br] print("[GraphicTool],clicked", end="")[br] # 契約書に情報を入力して実行ボタンを押すだけ(カプセル化)。[br] editor_canvas.add(self.contract.create_number("20"))[br] editor_canvas.add(self.contract.create_operator("+"))[br] editor_canvas.add(self.contract.create_number("80"))[br] editor_canvas.add(self.contract.create_operator("="))[br] editor_canvas.add(self.contract.create_number("100"))[br][br]# エディタのキャンバス(擬似的な画面)[br]class Canvas:[br] def add(self, element):[br] print(f"", end="")[br] element.draw()[br][br]# ==========================================[br]# 【カスタマイズ】利用者が作ったコード[br]# ==========================================[br][br]#テキスト表示用契約工場 ---[br]class TextNumber:[br] def __init__(self, v): self.v = v[br] def draw(self): print(f" {self.v}", end="")[br][br]class TextOperator:[br] def __init__(self, s): self.s = s[br] def draw(self): print(f"{self.s}", end="")[br][br]class TextModeFactory(AbstractExpressionContract):[br] """契約を守る工場"""[br] def create_number(self, value): return TextNumber(value)[br] def create_operator(self, symbol): return TextOperator(symbol)[br][br]canvas = Canvas()[br][br]print("\n--- 1. 【テキストモード契約】で画面工作員を動かす ---")[br]text_contract = TextModeFactory() # テキスト用の工場(契約の具現化)[br]music_tool_text = GraphicTool(contract_component = text_contract)[br]music_tool_text.on_mouse_click(canvas)[br][b][OUT][br][br]--- 1. 【テキストモード契約】で画面工作員を動かす ---[br][GraphicTool],clicked 20+ 80= 100[br][/b][br]これで、画面工作員はただ、情報を入れるだけで、数式をテキストモードで画面に表示できました。[br][br][b][size=150]<Texモード対応>[br][/size][/b][br]こうなると、Texモード対応は簡単にできます。[br](部品メニュー契約)にあう部品と工場をユーザーが作ってくればよいのです。[br][br]# --- :TeX表示用の部品と、その契約を履行する工場 ---[br]class TexNumber:[br] def __init__(self, v): self.v = v[br] def draw(self): print(f"$${self.v}$$ ", end="")[br][br]class TexOperator:[br] def __init__(self, s): self.s = s[br] def draw(self): print(f"$$\\pm {self.s}$$", end="")[br][br]class TexModeFactory(AbstractExpressionContract):[br] """TeXモードの契約を果たす工場"""[br] def create_number(self, value): return TexNumber(value)[br] def create_operator(self, symbol): return TexOperator(symbol)[br]print("\n--- 2. 【TeXモード契約】へ一発切り替え ---")[br]tex_contract = TexModeFactory() # TeX用の工場へ差し替え[br]music_tool_tex = GraphicTool(contract_component = tex_contract)[br]music_tool_tex.on_mouse_click(canvas)[br]これだけを追加して、実行するだけです。[br][br][b][OUT][br][br]--- 1. 【テキストモード契約】で画面工作員を動かす ---[br][GraphicTool],clicked 20+ 80= 100[br]--- 2. 【TeXモード契約】へ一発切り替え ---[br][GraphicTool],clicked$$20$$ $$\pm +$$$$80$$ $$\pm =$$$$100$$ [br][/b][br]両方動きました。[br][br]このように、部品を抽象化して、作業を外注するフレームワークにすることで、[br]表示モードが増えても、簡単に対応できました。[br]もしも、モードがさらに明朝体指定表示、ゴシック体指定拡大表示など、…増えたとして、[br]ユーザーが欲しいものを付け足すだけで、同じフレームワークで対応できるということですね。
抽象的な部品契約のクラスと、その契約にあう部品が作れる工場で作った契約書を実行することで、[br]自社に工場のない、元請け会社は難局を乗り越えました。[br]それは、部品の増大にだけ自社対応をして、[br]表示対応はユーザーのカスタマイズという名の下請け工場化をしたからです。[br][br]下請け工場法、ファクトリメソッドで部品が増えると、[br]その数だけ工場が増えるという現象が起きました。[br]そこで、コピー屋さん、プロトタイプ法に切り替えることで、作成をコピー屋さんに投げ、実際は部品自身が自己クローンを作るという面白い解決策で、工場の増大を防ぎましたね。[br]今回は、表示方法の数だけ工場が増えますが、ユーザに合わせてユーザが作る工場なので、[br]問題ないでしょう。[br]それに、コピー屋さんのパタンと同様に、現場作業の工作員へのしわ寄せはありませんでした。[br]また、フレーワークは表示方法の増大に対して、びくともしません。[br]つまり、[b]社員も会社も軽量化しながら信頼性はゆるがないというWinWinの構造改革[/b]でしたね。[br][br]もちろん、部品の増大の要求、たとえば、分数部品、行列部品など、増えるでしょうが、数学ですから、[br]やたらと増えることはないでしょう。算数エディタであれば、分数部品を増やすくらいで対応できます。[br]だから、フレームワークのバージョンアップのたいした問題ではないでしょう。[br][br]GOF本では、部品の増大にも対応できるように、部品を数や文字列で「パラメータ化」するとかの案や、ユーザーが表示方法の増大ごとに工場を増やすのをおさえるために、コピー屋さんのパタンと合わせ技を使うということも書いてますが、これ以上はこのパターンに深入りしません。[br][br]完璧さを求め、有能性を誇示することが、[br]かえって学習者の疲労と混乱をまねくことがよくあるからです。[br][br]この抽象契約AbstractFactoryパタンの面白さは、[br][b][color=#0000ff][size=200]2軸構造を分解してから合成するという数学思考[br][/size][/color][/b]と共通する発想方法だと思いますが、どうでしょうか。[br][br]さて、最後に次の課題にとりくみましょう。[br][br]課題:抽象契約AbstractFactoryパタンをgeogebraで実感するにはどうしらたよいでしょうか。[br][br]アプレットの名前を「抽象契約」とします。[br]f={(1,2),(2,3),(3,4),(4,5),(5,6)}[br]a=checkbox[br]b=slider(1,5,1)[br]c=x(f(b)) #分子とします[br]d=y(f(b)) #分母とします[br]g=c/d #分数でも小数でも表示は未定です。ただの1つの値がgです。[br]ntext = "" + g #これで、ntextは小数を表すテキストになります。[br]Text1=If(a≟true,FractionText(g),ntext)[br]このテキストをボールドで、サイズを大きめに設定しましょう。[br]すると、チェックボックスのオンオフで表示の小数と分数のモードが変えられます。[br]与える情報gは、bを動かせば連動して変わります。[br]geogebraには、Tableテキストなどのコマンドがありますから、リスト表示をパラメータ化して[br]変更したりすることができます。[br]これって、抽象契約と同じ発想かもしれませんね。[br]さて、最後に次の課題にとりくみましょう。[br][br][color=#9900ff][b][u][size=150]課題:抽象契約AbstractFactoryパタンをgeogebraで実感するにはどうしらたよいでしょうか。[br][/size][/u][/b][/color][br]アプレットの名前を「抽象契約」とします。[br]f={(1,2),(2,3),(3,4),(4,5),(5,6)}[br]a=checkbox[br]b=slider(1,5,1)[br]c=x(f(b)) #分子とします[br]d=y(f(b)) #分母とします[br]g=c/d #分数でも小数でも表示は未定です。ただの1つの値がgです。[br]ntext = "" + g #これで、ntextは小数を表すテキストになります。[br]Text1=If(a≟true,FractionText(g),ntext)[br]このテキストをボールドで、サイズを大きめに設定しましょう。[br]すると、チェックボックスのオンオフで表示の小数と分数のモードが変えられます。[br]与える情報gは、bを動かせば連動して変わります。[br]geogebraには、Tableテキストなどのコマンドがありますから、リスト表示をパラメータ化して[br]変更したりすることができます。[br]これって、抽象契約と同じ発想かもしれませんね。