
サービスコンポジション
クラス内に他オブジェクトを部品として持つ設計手法。
「車クラスがエンジンオブジェクトを持つ」ような関係で、依存度が低く部品ごとに完結しているのでメンテナンス性が高い。
メインオペレーターはlogicを持ち、logicはanalyzerやeditorを持つ。
self.logic.editor.hoge()のように、だれが持っている機能にアクセスしようとしているのかがわかりやすくなる。
# op_core.py
class LAZYUTILS_OT_CurveFlow(bpy.types.Operator):
def invoke(self, context, event):
self.logic = CurveFlowLogic()
self.logic.analyzer.analyze_all(logic, context)
def modal(self, context, event):
self.logic.editor.update_target(self.logic, context)
# logic/core.py
class CurveFlowLogic:
def __init__(self):
self.analyzer = CurveFlowAnalyzer()
self.editor = CurveFlowEditor()
# logic/analyzer.py
class CurveFlowAnalyzer:
def analyze_all(self, logic, context):
# logic/editor.py
class CurveFlowEditor:
def update_target(self, logic, context, skip_mesh_update=False):
サービス内の構造
- 機能の核になる(core)
- サービスにアクセスする時の窓口となる。
- 中身は使うプロパティをinit()で定義するだけ。
- 編集対象を解析する(analyzer)
- メッシュやカーブなどの必要な情報を一度に解析しておいて、編集で扱いやすくする
- 幾何計算を行う(geometry)
- 解析した内容を使って、編集に必要な計算を行う。
- 単純な計算を行う(math_utils)
- 幾何計算で使う。
- selfなどのデータに依存せずただ計算を行うだけ。
- 実際に編集を行う(editor)
- 実際のデータに対して移動や作成などを行う。