このワークシートは[url=https://www.geogebra.org/m/twxxx3yq]Math by Code[/url]の一部です。

今回はメディエータ、仲介者パタンだ。[br][br]合言葉は、困ったらは仏の相談役に丸投げしよう。[br][br]たとえば、A,B,Cが会社の同じ部署の同僚で仲が悪いとする。[br]Dはとなりの部署にいる人で利害関係はない。[br][br]価値観は十人十色だから、相性は様々だ。[br]たとえば、AさんはBさんの言動でムカつくことがよくある。[br]そういうときはAさんはCさんに八つ当たりする。[br]Cさんは鈍感なので怒らないが、気分のむらがありBさんに強くでることがよくある。[br]BさんはCさんに強く言われると反発して、言い返す。[br]言い返しても問題は解決しないので、Bさんのストレスはさらにたまる。[br]そのストレスでBさんの言動は荒くなり、Aさんをカッとさせる。[br]書くのも嫌になるA,B,Cの人間関係だ。[br]まとめると、C→B→A→Cの負のストレス連鎖がある。[br]ここに仏のDさんがいると少しは平和になる。[br]Dさんはみんなの不満を聞いてあげてもストレスがたまらない。[br]だから、よけいまわりの人はDに愚痴を言う。[br][br]この状況を改善するにはどうしたらよいだろうか。[br]Dさんが愚痴を聞くだけでなく、場の全体を察知して行動変容を促したらどうだろう。[br]DがAの相談をうけたら、Bに、AがBの言動で怒ることがあるようだと「伝える」。[br]DがBとCがもめている場面を見たら、Cが気分しだいの強い口調がBを傷つけたりすることをCに「伝える」。[br]BにはCに悪気がないけれど、気分屋だからいちいちかっとしない方がよいと「伝える」。[br][br]これをそのままプログラミングにするのはあまり意味がないので、ただのイメージの話としよう。[br][br]実際は、OOPプログラミングをして、画面にコントロールを貼り付けていくと、[br]条件分岐が複雑になることがよくある。[br]コントロールA,B,Cの振る舞いの条件分岐が複雑になりすぎたりする。[br]チェックボックスAがonならば、ドロップダウンリストBはリストXを表示し、テキスト入力Cは非表示にする。[br]AがoffならばBは非表示でテキスト入力Cを表示する。[br][br]ドロップダウンリストBのリストXで選択されたものがYならば、テキスト入力CにはYが入力されて表示される。[br]BのリストXで選択されたものがZならば、テキスト入力Cに空欄で入力待ちで表示される。[br][br]テキスト入力CにもしPが入力されるとチェックボックスAは非表示となる。[br][br]こんな相互依存を２つのオブジェクトの通信結果で書いたり、if文でそれぞれの振る舞いをそれぞれの責任で作ると[br]とても大変になる。[br][br]そこで、A,B,Cの状況をすべてDに通知して、Dが一括して、[br]A,B,Cにどうふるまえばよいかを指令すればよい。[br]コントロールたちは互いに会話をせずともことはスムーズに進むようになる可能性が高い。[br][br]このように、情報を局所かしてひそひそ解決するのでなく、[br]情報を大局的に一元的に管理するのがメディエータだね。[br][br]メディエータパタンとは、「調停という名の一元管理」。[br]調停者の手の平の上にのっかる同僚たち、部品たちという感じだね。[br]

[b][size=150]＜調停という名の一元管理を実装しよう＞[br][/size][/b][br][b][color=#0000ff]# ==========================================[br]# 【クラスMediator】仏のDさんの契約書[br]# ==========================================[br][/color][/b]class MediatorContract:[br][b]    """手の平に乗せる契約の仕方は、名前のサインと対象イベントだけでOK"""[br][/b]    def consult(self, component_name, event_type, value=None):[br]        raise NotImplementedError()[br][br][color=#0000ff][b]# ==========================================[br]# 【クラスControl or Colleague：画面の部品】互いに会話しない部品たち[br]# ==========================================[br][/b][/color]class ControlComponent:[br][b]    """部品同士は会話しない。分断されている"""[br][/b]    def __init__(self, name: str, mediator: MediatorContract):[br]        self.name = name[br]        self.mediator = mediator[br]        self.visible = True[br]        self.value = None[br][b]    """ユーザーの要求が来たら、自分の変化をDさんに伝えるだけ"""[br][/b]    def changed(self, event_type, value=None):[br]        self.value = value[br]        self.mediator.consult(self, event_type, value)[br][br][b][color=#0000ff]# ==========================================[br]# 【カスタマイズ】　ユーザが詳細すべてを実装する。[br]# ==========================================[br][/color][/b]class BuddhaD(MediatorContract):[br]    def __init__(self):[br]        # 調停する対象のオブジェクトたちを紐づける[br]        self.A = ControlComponent("CheckboxA", self)[br]        self.B = ControlComponent("DropdownB", self)[br]        self.C = ControlComponent("TextInputC", self)[br][br]    """【Dは「調停」という名のもとに、A,B,Cを手の平にのせて一元管理する】"""[br]    def consult(self, component, event_type, value=None):[br][br]        # 1. チェックボックスAが動いたとき[br]        if component.name == "CheckboxA" and event_type == "TOGGLE":[br]            if self.A.value == "ON":[br]                print("[Dさん調停] AさんがONになりましたね。BさんはリストXを表示してください。Cさんは出番待ちです。")[br]                self.B.visible = True[br]                self.B.value = "リストX表示中"[br]                self.C.visible = False[br]            elif self.A.value == "OFF":[br]                print("[Dさん調停] AさんがOFFになりました。Bさんは身を隠し、Cさん（テキスト入力）が表に出てください。")[br]                self.B.visible = False[br]                self.C.visible = True[br][br]        # 2. ドロップダウンリストBが動いたとき[br]        elif component.name == "DropdownB" and event_type == "SELECT":[br]            if self.B.value == "Y":[br]                print("[Dさん調停] Bさんで'Y'が選ばれました。Cさんの入力欄に'Y'を自動代入します。")[br]                self.C.value = "Y"[br]            elif self.B.value == "Z":[br]                print("[Dさん調停] Bさんで'Z'が選ばれました。Cさんは空欄にして入力待ちにしてください。")[br]                self.C.value = ""[br][br]        # 3. テキスト入力Cに文字が打ち込まれたとき[br]        elif component.name == "TextInputC" and event_type == "INPUT":[br]            if self.C.value == "P":[br]                print("[Dさん調停] Cさんに特異点'P'が入力されました！大局的判断により、Aさんを非表示にします。")[br]                self.A.visible = False[br][br]# 仏のDさん（場）が誕生。手の平にのる部品に略名をつける。[br]d_san = BuddhaD()[br]A=d_san.A[br]B=d_san.B[br]C=d_san.C[br][br]# ここから、仏のDさんの大活躍がスタート！[br][br]print("--- 1. ユーザーがチェックボックスAを『ON』にした ---")[br]A.changed("TOGGLE", "ON")[br]print(f" -> [その結果] Bの表示:{B.visible}, Cの表示:{C.visible}\n")[br][br]print("--- 2. ユーザーがドロップダウンBで『Y』を選択した ---")[br]B.changed("SELECT", "Y")[br]print(f" -> [その結果] Cの自動入力値: '{C.value}'\n")[br][br]print("--- 3. ユーザーがチェックボックスAを『OFF』にした ---")[br]A.changed("TOGGLE", "OFF")[br]print(f" -> [その結果] Bの表示:{B.visible}, Cの表示:{C.visible}\n")[br][br]print("--- 4. テキストCに、禁断の文字『P』が入力された ---")[br]C.changed("INPUT", "P")[br]print(f" -> [その結果] Aの表示:{A.visible}")[br][br][b][OUT][br]--- 1. ユーザーがチェックボックスAを『ON』にした ---[br][Dさん調停] AさんがONになりましたね。BさんはリストXを表示してください。Cさんは出番待ちです。[br] -> [その結果] Bの表示:True, Cの表示:False[br][br]--- 2. ユーザーがドロップダウンBで『Y』を選択した ---[br][Dさん調停] Bさんで'Y'が選ばれました。Cさんの入力欄に'Y'を自動代入します。[br] -> [その結果] Cの自動入力値: 'Y'[br][br]--- 3. ユーザーがチェックボックスAを『OFF』にした ---[br][Dさん調停] AさんがOFFになりました。Bさんは身を隠し、Cさん（テキスト入力）が表に出てください。[br] -> [その結果] Bの表示:False, Cの表示:True[br][br]--- 4. テキストCに、禁断の文字『P』が入力された ---[br][Dさん調停] Cさんに特異点'P'が入力されました！大局的判断により、Aさんを非表示にします。[br] -> [その結果] Aの表示:False[/b]

コントロール（部品）を画面に貼り付けるときは、[br]どうしても、１つ１つのコントロールに目がいき、[br]局所的な視点になりがちだ。[br][br]しかし、コントロールが連動することをコントロールの責任にする必要はない。[br][b]コントロールはもくもくと働き、ただ、仏様や場に報告すればよい。[br]コントロールどうしの「会話もなく、喧嘩もない。」[br][br]静寂と平和の世界だ。[br][/b][br]会話が大事とはいうけれども、どれだけ「大局的な視点での会話」が可能なのだろうか。[br][br]小市民的な人間は、自分も含めて、身近な人との会話で一喜一憂する。[br]もちろん、遠く離れた「有名人の活躍」を自分の活躍のように重ねて喜んだり、[br]「押し」の活動を応援して楽しんだりする日々も悪くない。[br]そうでもしないと、[br]社会の変化が速すぎて、劇的過ぎてついていけないストレスに飲まれかねないからね。[br][b]恐ろしい「会話のない労働、仏という名の一元管理」は物だから許される[/b]。[br][br]自由や会話が大事なはずだけれど、[br]民主主義や会話や自由が衝突して互いのエネルギーをそぎ落とすこともありうる。[br]国家だって自由なやりとりが理想だといわれていたが、独裁や障壁や専制の方が[br]管理がしやすいのだろうか。[br]そんな疑問を持ってしまうほど、平和で無駄のないシステムだと感じる。[br][br]「極端な例を見ると思考や感情が動く」という意味で、[br][b]デザインパタンは鏡なんだ[/b]と思う。[br]数学の感動と同じ種類の刺激だね。[br][br][color=#9900ff][u][b][size=150]課題：geogebraで調停という名の一元管理を見るためにはどうしたらよいでしょうか。[br][/size][/b][/u][/color][br]画面上に、ユーザーが操作できるコントロールをA,Bの２つ置きます。[br]Cは状態を表示するコントロールです。[br]AとBの会話をAとB自体に埋め込まなくても、[br]仏のDが外から一元管理してます。[br]AとBは思考も他のコントロールとの会話もしません。[br]Cは仏Dの操作結果を見ているだけの鏡です。オブザーバかもしれません。[br][br][code]A = Checkbox()[/code] [br][code]B = Slider(1, 3, 1)[/code][br]C = "表示中: A="+A+"B="+B [br]ボタンを貼り付けて、見出しを「仏のDに相談する」[br]スクリプトを[br]If(A==true,SetValue(B,2),SetValue(B,1))[br]If(B==3,setValue(A,false))[br]にします。[br]ユーザーへのメッセージを貼ります。[br]text1="仏Dの行動はこうです。\\[br]If(A==true,SetValue(B,2),SetValue(B,1))\\[br]If(B==3,setValue(A,false))\\[br]上から順に実行されるので、\\[br]仏でも2番目の願いは聞けません。"[br]にしてみましょう。[br]AとBが会話してないのに、DがAの状態からBを変えます。[br]しかし、上から順に実行しているので、[br][b]B=３でAがTrueになっていても、仏に相談するとAをfalseにはできません。[br][/b][br][b]仏様の限界[/b]でしょうか？[br][b]論理パズル[/b]みたくなってきましたね。[br][br]オブジェクトの状態が変化するたびに仏様が呼ばれるようにして、[br]Aの変化ならA変化のスクリプトを実行し、[br]Bの変化ならB変化のスクリプトを実行するという分岐文にしないといけません。[br][br]それが１つのスクリプトで可能になるためには、[br]Pythonでやったように、オブジェクトの登録が必要になりますね。[br]つまり、アプリが開いた瞬間に仏様のスクリプトは実行されます。[br]1.アプリ内のオブジェクトをスキャンしてリスト化します。[br]2.リスト化したオブジェクトに状態の変更があれば、そのオブジェクトが何かによって反応を変えるようにします。そうすると、上から順に実行するのではなく、変化したオブジェクトに合う条件文だけが[br]実行されるでしょう。[br][br]こうすれば、[b]仏Dのボタンを非表示にしても予想どうりに動く[/b]でしょう。[br]イベントに応じてスクリプトが実行される、[b]イベントドリブン[/b]ですね。[br][br]つまり、この論理パズルのように見えるバグが生じた原因は[br][b]geogebraのシステムにあるのではなく、[br]記述の仕方にある[/b]ことがわかりますね。[br][br]大がかりになるので、実装はしません。[br]でも、原因と対策がわかるというのは楽しいですね。[br][br]興味のある人は、[url=https://geogebra.github.io/docs/manual/ja/]日本語マニュアル[/url]や[b]API仕様[/b]（[code]registerUpdateListener[/code] ）あたりから[br]探索してみましょう。