Esiste un'euristica per determinare se un metodo o un campo appartiene a una classe?

Question

Esiste una buona regola empirica o un test che posso eseguire per determinare se un metodo o un campo appartiene a una classe? Come si può identificare quando un membro non appartiene?

Trovo che il mio singolo più grande ostacolo nel design orientato agli oggetti stia cercando di capire cosa va dove. Sembra che ci siano troppi casi in cui la risposta è: "potrebbe andare qui o lì".

Ecco un rapido esempio del tipo di cosa che sto lottando con:

Public Class ITDepartment 

    Private _sysadmins As List(Of Employee) 
    Private _developers As List(Of Employee) 

    // properties, public stuff... 

    Private Sub AddSkillToGroup(ByVal emps As List(Of Employee), ByVal skill As Skill) 
     For Each e As Employee In emps 
      e.AddSkill(skill) 
     Next 
    End Sub 

End Class 

L'oggetto ITDepartment gestisce i 2 gruppi di Employees ... ma dovrebbe sapere che Employees hanno abilità? Dovrebbe essere trasferito un metodo come AddSkillToGroup?

EDIT:

Sembra che il consenso finora è che l'ITDepartment non dovrebbe conoscere le competenze dei dipendenti. Suonerò un po 'l'avvocato del diavolo per illustrare dove entra in gioco la mia confusione.

ITDepartment è composto da due raccolte di dipendenti. Non dovrebbe essere in grado di delegare a tali elementi di raccolta? Il metodo AddSkill appartiene ancora alla classe Employee. L'ITDepartment sta semplicemente istruendo il proprio gruppo di dipendenti ad aggiungere un'abilità a ciascuno dei suoi membri.

Answer 1

Osservare i principi SOLID. Quelli ti daranno una guida su dove un metodo appartiene.

---

Modifica

"non dovrebbe [ITDepartment] in grado di delegare a tali elementi di raccolta?"

"[è esso] okay per la classe ITDepartment a" raggiungere attraverso "e delegare alla classe Employee tramite l'Elenco (Of Employee) che è composto da (come fa quando chiama e.AddSkill sopra). "

Sì.

La delega è come funziona la programmazione OO. Tu deleghi i dettagli alla Single Responsible Class. Delega l'implementazione in modo da poter dipendere dalle astrazioni e non dalle implementazioni.

BTW, AddSkillToGroup è privato, il che è fonte di confusione. Non nasconde un dettaglio di implementazione che ha qualche possibilità di cambiare. Non c'è motivo per questo di essere privato. [privato è spesso usato eccessivamente e usato in modo inappropriato. Molto, molto poco dovrebbe essere privato; e deve essere dichiarato privato solo se assolutamente necessario.]

Poiché l'implementazione è stata delegata al Dipendente, AddSkillToGroup non è un dettaglio di implementazione di questa classe.

Answer 2

Sarei incline a rendere List(Of Employee) nella sua classe a questo punto, in modo che possa avere il proprio metodo AddSkill().

Immagino tu decida dagli odori del codice. In particolare liste di argomenti troppo lunghe; raggiungendo dentro altri oggetti. Potresti anche provarlo e vedere se puoi rendere più private le cose di prima.

Cerca metodi o raccolte di metodi & membri che formano un sottogruppo coerente all'interno di una classe - sono pronti per il riposizionamento nella propria classe.