問題タブ [fluent-interface]

type::baseいくつかの一般的な機能と流暢なインターフェースを備えた基本（抽象）クラス（と呼びましょう）を構築したいと思います。私が直面している問題は、これらすべてのメソッドの戻り値の型です

これで、サブタイプを作成できます。たとえば、次のようになります。

これらのサブタイプを次のように使用すると、問題が発生します。

my_type の代わりに base を返すため、これはコンパイルされません。

私はただできることを知っています：

しかし、どうすれば実装できるかを考えていましたが、有効なアイデアが見つかりませんでした。何か提案はありますか?

流暢なインターフェイスは、多くのタスクにとって非常に便利だと思います。しかし、流暢なメソッドを混ぜたり、1 つのクラスでメソッドを変更したりすると、不安になります。

ほんの一例です（少し不自然ですが、ご容赦ください）：

文字列ユーティリティ クラスを想定すると、トリミングは連鎖に適しているようです。

他のメソッドは当然新しいオブジェクトを返します:

そして 3 番目のタイプがあり、それ自体で、オブジェクトを論理的に変更し、新しいものを返します。

各メソッドに最も明白なシグネチャを個別に使用すると、これらの 3 つの型になってしまいます。特に戻り値の型が mroe 以下であるため、どのクラスを使用するかについてはあまり直感的ではないのではないかと心配しています。

Str私はすでに不変にすることに決めていません- のようなメソッドSplitTokenはコア機能を提供するからです。私の主な問題は、流暢な方法を混合することです。

• そのインターフェースで流暢なメソッドを使用しないでください

• それらをサブインターフェースに移動します（以下を参照）

• 「1 つが流暢であれば、すべての変更方法も流暢である必要があります」?

• 流暢なメソッドに seocific プレフィックスを使用しますか?

• 心配するな？

• ???

サブインターフェースのアイデア:

私はこれについて未定です。余分な「流暢」があまり好きではありません-特にそれがC ++でのメソッド呼び出しであること

どう思いますか？

[編集] ここで「流暢」を使用しているのは、単一のインスタンスでメソッド呼び出しをチェーンするという基本的な意味であり、コードで英語の文を作成するという高度な意味ではありません。

メソッドチェーンは、結果が別のメソッドに対して呼び出されるようにするために、オブジェクト自体を返すオブジェクトメソッドの実践です。このような：

これは、読み取り可能なコード、または「流暢なインターフェース」を生成するため、良い習慣と見なされているようです。しかし、私には、代わりに、オブジェクト指向自体によって暗示されているオブジェクト呼び出し表記を壊しているように見えます。結果のコードは、オブジェクト指向コードが一般的に期待される方法である、前のメソッドの結果に対するアクションの実行を表していません。

この違いにより、「結果のオブジェクトを呼び出す」というドット表記に 2 つの異なる意味が生まれます: 連鎖のコンテキストでは、上記の例は、実際にはスケジュールを保存することを意図しているにもかかわらず、参加者オブジェクトを保存するものとして読み取られます。 getSchedule が受け取るオブジェクト。

ここでの違いは、呼び出されたメソッドが何かを返すと予想されるかどうかにあることを理解しています (その場合、チェーンのために呼び出されたオブジェクト自体が返されます)。しかし、これら 2 つのケースは、表記自体からは区別できず、呼び出されるメソッドのセマンティクスからのみ区別できます。メソッド チェーンを使用しない場合、メソッド呼び出しが前の呼び出しの結果に関連するもので動作することを常に知ることができます。チェーンを使用すると、この仮定が崩れ、実際のオブジェクトが何であるかを理解するためにチェーン全体を意味的に処理する必要があります。という本当にそうです。例えば：

最後の 2 つのメソッド呼び出しは getSocialStream の結果を参照し、その前のメソッド呼び出しは参加者を参照します。コンテキストが変化するチェーンを実際に記述するのは悪い習慣かもしれませんが (そうですか?)、それでも、似ているように見えるドット チェーンが実際に同じコンテキスト内に保持されているのか、それとも結果にのみ作用するのかを常に確認する必要があります。 .

私には、メソッド チェーンは表面的には読み取り可能なコードを生成するように見えますが、ドット表記の意味をオーバーロードすると、混乱がさらに大きくなるだけです。私は自分自身をプログラミングの第一人者とは考えていないので、間違いは私のせいだと思います。だから：私は何が欠けていますか？メソッドチェーンがどういうわけか間違っていることを理解していますか? メソッドの連鎖が特に良い場合と、特に悪い場合はありますか?

補足: この質問は、質問としてマスクされた意見の表明として読み取られる可能性があることを理解しています。しかし、そうではありません - 私は、連鎖がなぜ良い習慣であると考えられているのか、そしてそれが本来のオブジェクト指向の表記法を破ると考える上でどこが間違っているのかを心から理解したいと思っています。

私は、遊んでいるいくつかの単純な検証用のいくつかの流暢なインターフェースを作成している最中です。私が気づいたことの 1 つは、さまざまなオブジェクトが多数作成されていることです。

たとえば、次のステートメントが与えられます。

すべてのための '。' (最後のものを受け入れる) 私はオブジェクトを新しくしています。ここで流暢なインターフェースを使用していなければ、静的メソッドを使用していたでしょう。

私が疑問に思っているのは、この数のインスタンス オブジェクト (それらは非常に小さいオブジェクトであることに注意してください) を静的メソッドでの作業と比較して使用すると、パフォーマンスの実際の違いに気付く場所を誰かが知っているかどうかです。

乾杯アンソニー

作成したインターセプターを動作させようとしていますが、何らかの理由で、コンポーネントを要求したときにインターセプターがインスタンス化されていないようです。私はこのようなことをしています（これが完全にコンパイルされていない場合は許してください。しかし、あなたはアイデアを得る必要があります）：

インターセプターのコンストラクターにブレークポイントを設定しましたが、まったくインスタンス化されていないようです。

以前は、XML 構成を使用してインターセプターを登録していましたが、流暢なインターフェースを使用したいと思っています。

どんな助けでも大歓迎です！

私は自分のシステムに一連のルールのための流暢なインターフェースを実装しようとしてきました。私が達成しようとしているのはこれです

しかし、私が意図した条件付きのWhenを実装するのに問題があります。現在、このスニペットのようにWhen（）を2回呼び出す必要があります。

私のTicketRulesクラスは次のようになります。

ITicketRules

また、When句でAddTicketParametersのサブクラスをサポートする必要があります（おそらくその部分にジェネリックを使用しています）。私はすべて私のデザインに混乱していて、マーティン・ファウラーの記事が私をさらに混乱させているので、ここに投稿しています。

流暢なインターフェイスを使用して単純なダイアログボックス（およびその他のUI要素）を定義する例と経験を探しています。

（社内のプログラミング言語にカスタムダイアログボックスのサポートを追加する必要があるかもしれません。流暢なインターフェイスがそれを行うための最良の方法かもしれないと思います）

UIシステムは、回答に影響する場合はWinformsまたはWPFに基づいて構築されます。

インターフェイスが流暢でなく、質問を「ドラッグアンドドロップ」UIデザイナーの使用に依存しない「使いやすい（そして読む）API..」に変更した場合はどうなりますか。

結果はある程度流暢になると思います。

Textbox（「名前」）。Labelled（「個人名」）。列（1）

テキストボックス（「メモ」）。ラベル付き（「メモ」）。Multiline（4）。Column（1）.ToColumn（3）

ただし、インターフェイスは1行である必要はありません

この「データバインディングタイプを安全にし、リファクタリングをサポートする方法」は、データバインディングの流暢なインターフェイスの良い出発点になります。

関連する権限を持つユーザーがいます。ここに私が欲しいものがあります:

User を作成し、User.Permissions コレクションにアクセス許可を追加します。保存され、すべてが期待どおりに行われます。

次に、ユーザーを編集して権限を削除します。その後、新しいユーザー オブジェクトが作成され、権限コレクションは空になります。この新しいユーザー オブジェクトの識別子とバージョンが関連する値に設定され、ユーザー オブジェクトが更新されます。

ただし、既存の権限は削除されません。

そのため、NHibernate が常にアクセス許可コレクションを削除し、その中のすべてのアイテムを再挿入するようにしたいと考えています。

これを設定するにはどうすればよいですか？私は流暢なAPIを使用しています。

よろしく、エベン

メソッドチェーンを通じて、いくつかの小さな流暢なインターフェースを作成しました。通常、Web サービスやデータベースからデータを取得する多数のリポジトリを呼び出します。

流暢なインターフェースを使用する単体テスト方法についてはどうすればよいですか?

流暢なインターフェイスの個々のコンポーネントを単体テストできますが、上記の FindComputers メソッドを単体テストしたい場合はどうすればよいですか?

1. 流暢なインターフェースの具体的な実装を使用し、Repository クラスに期待値を記述します
2. 流暢なインターフェイス自体をモックし、それに期待を設定します
3. FindComputers() メソッドではなく、流暢なインターフェイス自体のみをテストします

簡単に維持できるアプローチを見つけたいと思います。