質問: date.someuniquevalue() 次に、swift拡張子を持つクラスのように機能する独自のdateクラスをインポートします。誰かがこれを行うことで成功しましたか、またはこのようなパターンから離れる理由があると思いますか?
回答: いいえ、サブクラス化にはswiftの拡張機能と同じ効果はありません。 _com.me.extensions.date_と_java.util.date_は異なるクラスです。既存の_java.util.date_インスタンスには、サブクラスで定義したメソッドがありません。対照的に、_extension date_は新しいクラスを作成しませんが、既存のクラスにメソッドを追加します。これらのメソッドは、すべてのインスタンスで使用できます。拡張機能は、動的言語(python、ruby、perl、javascript)でのモンキーパッチングに少し似ています。この違いは、拡張機能を認識しない他のパッケージでdateインスタンスが作成される場合に特に重要です。 someuniquevalue()メソッドを提供しない_java.util.date_を作成します。既存の型に機能を追加するためにswift、go、rust、scala、haskellなどで使用されている手法はjavaでも使用できますが、この言語は役に立ちません。すべてを手動で行う必要があります。特に、ほとんどのjava apiは、必要な拡張性をサポートするように設計されていません。javaでは、インスタンスをパラメーターとして受け取る静的メソッドを宣言することにより、新しいfinalメソッドを型に追加するのと同じ効果があります。これは、c#の拡張メソッドが機能する方法です。あなたの場合:_static int someuniquevalue(date self) { return self.something * self.somethingelse; } _date.someuniquevalue()の代わりに、これはsomeuniquevalue(date)として呼び出されますが、これは単なる構文です。 javaを使用すると、そのような関数を複数のファイルで使用する場合に_import static_を使用できます。ここでの大きな制限は、静的メソッドは動的ディスパッチ(別名仮想メソッド)と一緒に機能しないことです。使用する新しいメソッドを定義することはできますが、既存のメソッドをオーバーライドして誰もが自分のバージョンを使用できるようにすることはできません。インターフェイス/プロトコルを実装するためにクラスをメソッドで拡張する場合は、オブジェクトアダプターパターンを使用できます。_interface uniquelyvalued { int someuniquevalue(); } // extension date: uniquelyvalued { ... } class adaptdatetouniquelyvalued implements uniquelyvalued { private final date self; adaptdatetouniquelyvalued(date self) { this.self = self; } public date getdate() { return self; } @override public int someuniquevalue() { return self.something * self.somethingelse; } } _日付があるが、それをuniquelyvaluedオブジェクトとして使用したい場合は常に、それをアダプターでラップする必要があります:new adaptdatetouniquelyvalued(date).someuniquevalue()ラッピングは、インターフェイスタイプへのアップキャストとして解釈できます。拡張機能がファーストクラスでサポートされている言語では、ラッピングとアンラッピングが自動的に行われます。これは、対話するコードが具象クラスではなくインターフェースに依存している場合に正常に機能します(solidの依存関係逆転原理)。これは必ずしもそうではありません。代わりに静的メソッドを使用できても、メソッドチェーンを使用してfluent apiを提供したい場合は、ラッパーも適しています。アダプターの大きな欠点は、リフレクションまたはアノテーションを使用するつもりがない限り、アダプターの作成に多くの労力がかかることです。クラスをインターフェイスに適合させ、そのクラスが必要なすべてのメソッドをすでに提供している場合でも、インターフェイスの各メソッドをラップされたオブジェクトに明示的に転送する必要があります。インターフェイスタイプには、「タイプ消去」を実行するという一般的な問題もあります。アダプタを使用してオブジェクトをインターフェイスインスタンスに変換すると、元々はある種のオブジェクトであったという情報が失われます。 uniquelyvaluedインスタンスをアダプターにダウンキャストすることは安全ではありません。 apiを設計する場合、ジェネリックを広範囲に使用することにより、このような問題を最小限に抑えることができます。例えば。 fluent apiを定義するインターフェース_interface fluentaddition { fluentaddition plus(int x); int result(); } // class fluentmath implements fluentaddition<fluentmath> { ... } // new fluentmath().plus(1).plus(2).plus(3).result() _そのインターフェイスをサブクラス化してfluent apiに追加のメソッドを追加することはできません。add()への最初の呼び出しは、不必要に制約されます。ジェネリックスでは、代わりにインターフェイスを型制約として使用できます。_interface fluentaddition<self extends fluentaddition<self>> { self plus(int x); int result(); } // class fluentmath implements fluentaddition<fluentmath>, // fluentmultiplication<fluentmath> { ... } // new fluentmath().plus(1).plus(2).times(3).result() _このようなインターフェースは、タイプ情報をはるかに少なく破壊し、一部のオブジェクトをアダプターで一時的にラップすることを容易にします。アダプターパターンを含む新しい動作(オープン-クローズドプリンシプルの意味で)を使用して後で拡張できるようにシステムを設計するためのその他の手法については、「デザインパターン」で詳しく説明しています。再利用可能なオブジェクト指向ソフトウェアの要素」(ガンマ他).