…Helperまたは…Managerクラスを回避する方法

プロジェクトにはかなりの数のヘルパークラスがあります。これは悪いことだと読んだことがありますが、「ヘルパー」がサフィックスとして間違っていると思います。例を挙げましょう。

まず、Userクラスがあります。GetSuggestedFriends()ユーザーのための方法が必要です。提案された友達のリストをUserクラスから除外するためのロジックを保持したいので、肥大化しません。現在、コンストラクターでFriendshipHelperを受け取るがありUserます。友達候補を取得するためのロジックが含まれているので、を呼び出すことができますmyUser.FriendshipHelper.GetSuggestedFriends()。

元々FriendshipHelperは静的メソッドのみがあり、Userオブジェクトはそれぞれに渡されていました。今、クラスを最初から作成している場合は、それを呼び出すかもしれませんFriendshipManager-友達の追加や削除なども行います。

...Managerただし、クラスが悪いことも読みました。私はこのクラスを何と呼ぶべきですか？または、これは「不良コード」ですか？友達候補、現在の友達、友達の追加と削除のロジックはどこにあるべきですか？きっとすべてが巨大なUserクラスにいるわけではありませんか？

「ヘルパー」または「マネージャークラス」を回避する方法«

一般的に：優れた設計

まず、Userクラスがあります。ユーザー用のメソッドGetSuggestedFriends（）が必要です。

はい。A user は他のと関係がありusersます。そして、その関係はuser、たとえばのメソッドとして表現できますuser.isFriend(user2)。これはuserオブジェクトの責任です。さらに、別のオブジェクトに他の友達を探す手助けを求めます。あなたは委任責任のために友人を見つける別のオブジェクトには、それはだ、非常に細かいです。

現在、コンストラクタでUserを受け取るFriendshipHelperがあります。提案された友達を取得するためのロジックが含まれており、myUser.FriendshipHelper.GetSuggestedFriends（）を呼び出すことができます

それ自体は悪いことではありませんが、欠点があります。「ヘルパー」を1つで初期化するとuser、可能性がそのヘルパーに限定されますuser。

必要なのはオブジェクトです。これは、あらゆるユーザーの友達を見つけるのに役立ちます。したがって、一般的な方法は理にかなっています。userMatcher.findFriendsFor(user)これは、見返りに友人のコレクションを提供します（user）。

今、クラスを最初から作成している場合は、FriendshipManagerと呼ぶかもしれません。

あなたの問題は「ヘルパークラス」を書くことではなく、正しい名前を見つけることです。;）

また、友達の追加や削除なども行います。

それは間違ったデザインです。自分の例を挙げましょう：あなたのママはあなたの人生に友達を追加しますか、それとも自分で追加しますか？

もちろん、友達のコレクションはそれ自体の所有物であり、メソッドやuseruser.addFriend(user)user.removeFriend(user)

私はこのクラスを何と呼ぶべきですか？

前に述べたように、名前の問題のみがあり、「ヘルパー」は大丈夫です。しかし、各オブジェクトの責任についてもっと注意深く考える必要があります。

友達候補、現在の友達、友達の追加と削除のロジックはどこにあるべきですか？きっとすべてが巨大なUserクラスにあるわけではない

いいえ。これらは、人と出会い系機関がある実際の生活のように、1つの個別のオブジェクトが必要な2つのジョブです。

FriendshipService（非静的）GetSuggestedFriends(User)メソッドを持つクラスがあることをお勧めします。テストがより困難になるインターフェースを実装できないため、静的メソッドは避けてください。単一のユーザーに特に関連しないメソッドでFriendshipServiceを拡張したい場合があるため、コンストラクターにユーザーオブジェクトを追加しないでください。（たとえば、ユーザーのセットに友達を提案したり、何か他のものに基づいて友達を提案したりすることができます）

ユーザーはFriendshipService（単一の責任パターンのため）に気づいていない可能性が高い