そのため、「グローバル設定」に似た基本設定クラスを拡張する設定クラスを使用しています。いくつかのサービスがあり、各サービスには、抽象基本設定クラスを拡張する独自の設定クラスがあります。抽象基本設定クラスは、サービス間で共有される設定に対応します。したがって、最初に以下の例で説明し、次に問題を定義します。
例:
abstract class BaseSettings {
protected $settingA;
protected $settingB;
}
class MyServiceSettings extends BaseSettings {
private $settingC;
public $settingD;
}
問題:
このようにReflectionClassインスタンスを作成するとします。
$reflect = new ReflectionClass($this);
..MyServiceSettingsクラスまたはBaseSettingsクラスのいずれかから(明らかに抽象クラスのインスタンスを持つことができないため)、$reflect->getProperties()
常にMyServiceSettingsとBaseSettingsの両方のプロパティを返します(実際に作業しているため、これは適切だと思います)単一の具体的なクラスで)
これで、抽象BaseClassを拡張して、どのプロパティがどこに移動するかを把握する(または抽象を削除してBaseClassのインスタンスを作成する)空のクラスを作成できると確信していますが、それはかなり厄介なように思われるので、疑問に思っています。おそらく、どのプロパティが親クラスに属し、どのプロパティが子クラスに属するかを判断するためのより洗練された方法がありますか?
なぜ私がこれを行っているのか興味がある場合は、最後に正常に完了した最後のアトミック操作から続行できるように、追加した回復機能の目的で設定を.jsonファイルにシリアル化します。なぜ私はそれをこのようにしなければならないのか-環境の制限。