ロギングのためにクラスをFrameworkA
消費するとします。ロギング ライブラリを別のもの (クラス)FrameworkA.StandardLogger
に置き換えたい。SuperLogger
それを可能にするために、インターフェースがあります:他のライブラリが実装しなければならないインターフェースをFrameworkA
提供します。FrameworkA.Logger
しかし、他のライブラリがそのインターフェースを実装していない場合はどうなるでしょうか? インターフェイスを気FrameworkA
にするほど人気のないフレームワークかもしれません。SuperLogger
考えられる解決策は次のとおりです。
- 標準化されたインターフェースを持っている (JSR、PSR などの標準によって定義されている)
- 書き込みアダプター
標準化されたインターフェースがなく、クラスに互換性がある場合に役に立たないアダプターを作成する手間を省きたい場合はどうすればよいでしょうか?
クラスがコントラクトを満たしていることを確認するための別のソリューションはありませんが、実行時にありませんか?
想像してみてください (疑似コードでの非常に単純な実装):
namespace FrameworkA;
interface Logger {
void log(message);
}
namespace SuperLoggingLibrary;
class SupperLogger {
void log(message) {
// ...
}
}
SupperLogger
Logger
Logger インターフェースを実装していれば互換性があります。しかし、 への「強い依存関係」を持つ代わりにFrameworkA.Logger
、そのパブリックな「インターフェース」(または署名) を実行時に検証できます。
// Something verify that SupperLogger implements Logger at run-time
Logger logger = new SupperLogger();
// setLogger() expect Logger, all works
myFrameworkAConfiguration.setLogger(logger);
偽のシナリオではLogger logger = new SupperLogger()
、クラスがインターフェイスと互換性がない場合は実行時に失敗すると予想されますが、互換性がある場合は成功します。
それはOOPで有効なことでしょうか? はいの場合、どの言語にも存在しますか? いいえの場合、なぜ有効でないのですか?
私の質問は、静的型付け言語 (Java など) または動的型付け言語 (PHP など) を表しています。
PHP & al の場合: 型チェックがない場合、インターフェイスを実装していなくても、必要なオブジェクトを使用できることはわかっていますが、オブジェクトがインターフェイスに準拠していることを実際にチェックするものに興味があります。