クラス、ジェネレータ、プロセッサは2つあります。前者は、メンバー属性として格納されているArrayListを生成します。後者はArrayListを処理します。オブジェクトまたはオブジェクトの属性を渡す
私のメインクラスは、各オブジェクトのインスタンスを生成し、適切なメソッドを呼び出します。
より良い方法は何ですか？
にジェネレータオブジェクトのArrayListのを渡しProcessorは、データがどこから来るか気にする理由を持っていますそれ以上のものが生成されるように要求しますか？そうでない場合は、できるだけ一般的な方法でデータを渡してください。 Iterable<T>,Collection<T>またはList<T>である。
あなたのコードが少なく密結合、およびテストが容易であることの方法は - ヘック、あなたも、あなたがProcessorをテストする前に、あなたのProcessorユニットテストに問題がある場合Generator、そして、彼らは可能性が高いです記述する必要はありませんProcessorのバグが原因で発生し、Generatorでは発生しません。
私は、その属性（メソッドを介して公開されていると仮定します）ではなく、ジェネレータを渡す傾向があります。
なぜですか？私はより高い抽象化層でインタフェースと結合を保つことを好む。属性ではなくオブジェクトを渡すことで、後の段階でジェネレータを変更し、リファクタリングするコードセクションを減らすことができます。
想像してみましょう - ある段階では、リスト属性だけでなく、おそらく他のものを渡すこともできます。より高いレベルのオブジェクトを渡すことによって、あなたのリファクタリングを制限することができます。
もちろん、これはすべてこのオブジェクトの使用状況がどれほど広がっているかによって異なります。属性リストを渡すことにした場合は、リスト自体を渡すか、変更不可能なコピーを渡してください。
私は変更不可能なコピーを渡しています。カプセル化を維持するほうがよいと思うので、私はいつもこれをやる傾向があります。それは合理的だと思いますか？ – retrodev
なぜこれらが1つのオブジェクトではないのだろうか。プロセッサがGeneratorの状態を変更した場合、そのメソッドはGeneratorの一部ではないのはなぜですか？そのようにカプセル化を改善する。ジェネレータのメソッドとのインターフェイスは、あなたに素晴らしい柔軟性を与えます。ジェネレータはプロセッサインタフェースを持つことができ、具体的なインスタンスを渡して必要に応じて実装を変更することができます。
オブジェクトは、状態と動作を一緒にしています。プロセッサーの構成はそれを遵守し、データに対して何が行われたのかを柔軟に変更できるようにします。あなたがメインでそれを呼び出すと、プロセッサに結果を渡す方法Generatorクラスで
List<YourType> getList()
を作成する必要があります設計の観点からはわずかな思考...
プロセッサはデータを操作し、それをファイルに保存します。リストとプロセッサをunmodifiableListとして渡すので、ジェネレータとプロセッサは別々の状態に保たれているため、ジェネレータの状態は実際には変更されません。 – retrodev
。
この場合、ジェネレータとプロセッサは独立しており、相互に「知っていない」ため、独立して変更できることに注意してください。さらに、メソッドはList（ArrayListではなく）を返します。したがって、インターフェイスはリストの実装にも依存しません。
最後の点です。リストはより安全になるようにパラメータ化されています（List<YourType>）。
これは私が最初に行った実装です。 – retrodev
ありがとうございます。その場合、GeneratorアクセサーがArrayListではなくリストを返すようにする必要がありますか？もしそうなら、私は宣言する必要がありますArrayListとしてプライベートリスト myList = new ArrayList ？ –
retrodev
@Laurence：おそらく、どちらにもそうです。ちょうど確認する - おそらくメンバフィールドは、ジェネレータまたはプロセッサのいずれかではなく、この第3クラスにありますか？なぜジェネレータ自体が生成したデータを保持する必要があるのか分かりません。 –
メンバーフィールドはGeneratorにあります。それは私にそれが論理的に所有されているようだった。 – retrodev