Czy istnieje heurystyka, aby określić, czy dana metoda lub pole należy do klasy?

Question

Czy istnieje dobra zasada lub test, który mogę wykonać, aby określić, czy dana metoda lub pole należy do klasy? Jak rozpoznać, kiedy członek nie należy?

Uważam, że moja największa przeszkoda w projektowaniu obiektowym próbuje ustalić, co się dzieje. Wygląda na to, że jest zbyt wiele przypadków, w których odpowiedź brzmi: "może tu być lub".

Oto krótki przykład typu rzeczy mam zmaga się z:

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 

Przedmiotem ITDepartment zarządza 2 grupy Employees ... ale powinien wiedzieć, że Employees mieć umiejętności? Czy należy przesunąć metodę taką jak AddSkillToGroup?

EDIT:

Wydaje się, że zgoda co do tej pory jest to, że ITDepartment nie powinien wiedzieć o umiejętności pracowników. Będę grał adwokata diabła, aby zilustrować, gdzie moje zamieszanie wchodzi w grę.

ITD składa się z dwóch kolekcji Pracowników. Czy nie powinien móc przekazywać przedmiotów do kolekcji? Metoda AddSkill nadal należy do klasy Employee. ITDepartment po prostu instruuje swoją grupę pracowników, aby dodali umiejętności do każdego z jej członków.

Answer 1

Spójrz na zasady SOLID. Te dadzą ci wskazówki, gdzie należy metoda.

---

Edit

"nie powinien [ITDepartment] być w stanie przekazać tych elementów kolekcji?"

"[jest to OK, aby klasa ITDepartment mogła" dotrzeć przez "i przekazać do klasy Employee przez listę (pracownika), z której się składa (jak to robi, gdy wywołuje e.AddSkill powyżej). "

Tak.

Delegacja działa w ten sposób, że działa programowanie OO. Przekazujesz dane do pojedynczej klasy odpowiedzialnej. Delegujesz implementację, abyś mógł polegać na abstrakcjach, a nie implementacjach.

BTW, AddSkillToGroup jest prywatny, co jest mylące. Nie ukrywa szczegółów implementacji, które mają jakiekolwiek szanse na zmianę. Nie ma powodu, żeby to było prywatne. [Prywatne jest często nadużywane i używane niewłaściwie. Bardzo, bardzo mało powinno być prywatne; i powinno być zadeklarowane jako prywatne tylko wtedy, gdy jest to absolutnie konieczne.]

Od momentu delegacji wdrożenia do Pracownika, AddSkillToGroup nie jest szczegółem implementacji tej klasy.

Answer 2

Byłbym skłonny wprowadzić List(Of Employee) do własnej klasy w tym miejscu, aby mógł mieć własną metodę AddSkill().

Domyślam się, że pachniesz kodami. W szczególności zbyt długie listy argumentów; docieranie do innych obiektów. Możesz także spróbować i sprawdzić, czy możesz zrobić więcej rzeczy prywatnie niż wcześniej.

Zwróć uwagę na metody lub kolekcje metod, które tworzą spójną podgrupę w ramach klasy - są gotowe do przeniesienia do swojej klasy.