Come evitare ... Helper o ... Classi di manager

How to avoid …Helper or …Manager classes«

In generale: per buon design

First, I have a User class. I need a method GetSuggestedFriends() for a user.

Sì. Un user ha una relazione con l'altro users . E la relazione potrebbe essere espressa come un metodo su user , ad es. %codice%. Questa è la responsabilità di user.isFriend(user2) -object. Inoltre, chiedi a un altro oggetto per di trovare altri amici . Delega la responsabilità per trovare amici su un altro oggetto e questo è abbastanza fine .

Right now, I have a FriendshipHelper which receives a User in its constructor. It contains the logic for getting suggested friends, and I can now call myUser.FriendshipHelper.GetSuggestedFriends()

Questo non è per sé cattivo, ma ha uno svantaggio: l'inizializzazione di "Helper" con un user limita le possibilità a quell'uno user .

Ciò di cui hai bisogno è un oggetto , che aiuta a trovare amici per qualsiasi utente. Quindi un metodo generico avrebbe senso: user che in return fornisce una collezione di possibili amici ( userMatcher.findFriendsFor(user) ).

If I was writing the class from scratch now, maybe I'd call it FriendshipManager

Il tuo problema non è scrivere "classi helper", è trovare i nomi giusti . ;)

it also does things like adding and removing friends.

Questo è un disegno errato . Prenditi ad esempio: La tua mamma aggiunge amici alla tua vita o li aggiungi da solo?

Naturalmente la collezione di amici è una proprietà di user stessa e quindi è il metodo user o user.addFriend(user)

What should I call this class?

Come detto prima: hai solo un problema di denominazione e i tuoi "aiutanti" sono ok . Ma devi riflettere più attentamente sulle responsabilità di ciascun oggetto.

Where should the logic for getting suggested friends, current friends, and adding and removing friends live? Surely not all in a giant User class

No. Questi sono due lavori per i quali hai bisogno di un oggetto separato , come nella vita reale dove hai persone e una agenzia di appuntamenti .

Suggerirei di avere una classe FriendshipService con un metodo (non statico) GetSuggestedFriends(User) . Evita metodi statici poiché non puoi implementare un'interfaccia che rende più difficile il test. Evita di aggiungere l'oggetto utente al costruttore, poiché potresti voler estendere il tuo FriendshipService con metodi non specificamente correlati a un singolo utente. (Ad esempio, potresti suggerire amici a un gruppo di utenti o suggerire amici in base a qualcos'altro)

Molto probabilmente un utente non dovrebbe conoscere FriendshipService (a causa del pattern di singola responsabilità)