¿Existe una heurística para determinar si un método o campo pertenece a una clase?

¿Existe una buena regla general o prueba que pueda realizar para determinar si un método o campo pertenece a una clase? ¿Cómo se puede identificar cuándo un miembro no pertenece?¿Existe una heurística para determinar si un método o campo pertenece a una clase?

Encuentro que mi obstáculo más grande en el diseño orientado a objetos es tratar de averiguar qué ocurre. Parece que hay demasiados casos donde la respuesta es: "podría ir aquí o allí".

Aquí está un ejemplo rápido del tipo de cosa que estoy luchando 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

El objeto ITDepartment gestiona los 2 grupos de Employees ... pero debería saber que Employees tienen habilidades? ¿Debería reubicarse un método como AddSkillToGroup?

EDIT:

Parece que el consenso hasta ahora es que la ITDepartment no debe saber acerca de las habilidades de los empleados. Interpretaré un poco al abogado del Demonio para ilustrar dónde entra en juego mi confusión.

ITDepartment se compone de dos colecciones de empleados. ¿No debería poder delegar en esos artículos de colección? El método AddSkill todavía pertenece a la clase Employee. ITDepartment simplemente está instruyendo a su grupo de empleados para que agreguen una habilidad a cada uno de sus miembros.

Fuente

2009-02-25 Rob Sobers

¿Está preguntando SI debe delegar? La respuesta es siempre sí". ¿O estás preguntando CÓMO delegar? Si es así, por favor arregla tu pregunta. ¿O estás haciendo alguna otra pregunta sobre la delegación? –

Me pregunto si está bien que la clase de departamento de TI "alcance" y delegue en la clase de empleado a través de la lista (de empleado) de la que está compuesta (como hace cuando llama a e.AddSkill). –

Mire los principios SOLID. Esos le darán orientación sobre dónde pertenece un método.

Editar

"¿No debería [ITDepartment] ser capaz de delegar en los artículos de la colección?"

"[Está bien] para que la clase de departamento de TI" alcance "y delegue en la clase Empleado a través de la lista (de empleado) de la que está compuesta (como hace cuando llama a e.AddSkill anterior). "

Sí.

Delegación es cómo funciona la programación OO. Usted delega los detalles a la clase responsable única. Usted delega la implementación para que pueda depender de abstracciones, no de implementaciones.

BTW, AddSkillToGroup es privado, lo cual es confuso. No oculta un detalle de implementación que tiene alguna posibilidad de cambio. No hay razón para que esto sea privado. [privado a menudo se usa en exceso y se usa de manera inapropiada. Muy, muy poco debe ser privado; y solo debe declararse privada cuando sea absolutamente necesario.]

Dado que la implementación se ha delegado en Employee, AddSkillToGroup no es un detalle de implementación de esta clase.

Fuente

2009-02-25 16:09:03

Es privado porque es un detalle de implementación. Podría ser un método de "ayuda" para un método público llamado 'TrainEmployees()' que agrega la habilidad y otorga un certificado o algo. No entiendo por qué es extraño. –

@ vg1890: privado se ha usado en exceso. Esto no oculta ningún detalle de implementación que pueda cambiar e invalidar algún cliente. –

@ S.Lott: ¿no oculta a los clientes el hecho de que TrainEmployees() consiste en agregar una habilidad y evitar que llamen a AddSkill directamente? –

Me inclino a hacer List(Of Employee) en su propia clase en este punto, por lo que puede tener su propio método AddSkill().

Supongo que usted decide por el código de olores. En particular, listas de argumentos demasiado largas; alcanzando dentro de otros objetos. También puede intentarlo y ver si puede hacer más cosas privadas que antes.

Busque métodos o colecciones de métodos & miembros que forman un subgrupo coherente dentro de una clase: están listos para su reubicación en su propia clase.

Fuente

2009-02-25 16:22:06

Sí, lo que dijo. O elimine completamente esa función, ya que es muy pequeña, o cree una clase EmployeeCollection y agréguela a eso. Ciertamente no tiene nada que ver con la clase ITDepartment. – munificent

¿Existe una heurística para determinar si un método o campo pertenece a una clase?

Respuesta

Cuestiones relacionadas