2012-08-23 5 views
8

¿Es un signo de mal diseño donde tienes muchas clases con solo 1 o 2 métodos en ellas?Mala OOP para tener muchas clases con solo 1 o 2 métodos

Estoy tratando de aprender el diseño OOP y he creado una pequeña aplicación (pequeña).

Ha terminado con bastantes clases implementando interfaces que contienen solo 1 o 2 métodos.

Se siente bien separado pero parece malo que las clases tengan muy pocos métodos.

Sé que cada situación será diferente, pero ¿es esto malo desde un punto de vista general?

Una pequeña parte de la aplicación determina los horarios para la alimentación de perros (cojo lo sé):

por lo que he tratado de implementar el patrón de estrategia aquí:

class DogFeedController 
{ 
    protected $strategy = null; 

    public function __construct(iDogFeedStrategy $strategy) { 
     $this->strategy = $strategy; 
    } 

    public function getFeedingSchedule() { 
     $morningFeeds = $this->strategy->generateMorningFeeds(); 
     $eveningFeeds = $this->strategy->generateEveningFeeds();  
    } 

} 


class GeneralFeedStrategy implements iDogFeedStrategy 
{ 
    public function generateMorningFeeds() { 
     //do stuff here 
    } 

    public function generateEveningFeeds() { 
     //do stuff here 
    } 
} 
+0

Realmente depende. Sería muy agradable ver algunos ejemplos concretos. –

+0

tengo una actualización con un pequeño ejemplo de la aplicación que resalta de lo que estoy hablando. –

+0

@ user1189880 ** no ** resalta nada :). Tener clases con una o dos funciones públicas es algo bueno. Pero no pueden ser largos (porque se volverán difíciles de comprender), de modo que, siempre que sea posible y necesario, extraiga cierta lógica repetida para funciones privadas. – dantuch

Respuesta

6

Tienes que medir por ti mismo si es demasiado. OOP es una excelente manera de separar la lógica de una manera significativa y real, pero también puede llegar a un punto en que afecta negativamente el mantenimiento, y en ese punto se está aplicando incorrectamente.

Piensa a dónde va la aplicación. ¿Siempre va a ser una aplicación pequeña? Si es así, no necesita crear muchas interfaces genéricas. Intenta combinarlos, y si solo una clase está implementando la interfaz, es posible que puedas eliminar la interfaz por completo.

Si cree que su aplicación va a crecer substancially, las interfaces en realidad podría ayudar a mantener y añadir características en el futuro. Por ejemplo, si creó una aplicación para administrar un lote de automóviles que solo tiene espacios de estacionamiento para automóviles, es posible que desee crear una interfaz genérica para automóviles si prevé crecer a diferentes tipos de vehículos (por ejemplo, las motocicletas solo ocupan la mitad de un espacio de estacionamiento). Dicho esto, no debe tratar de cubrir todos los cambios concebibles en los requisitos al inicio de un proyecto y hacer que el código sea demasiado abstracto. Medir el riesgo de cambio en los requisitos puede ayudarlo a predecir qué código debe abstraerse.

Si eres un ingeniero de software en un equipo, diseña tu diseño y muéstraselo a tus colegas para obtener sus opiniones también.

Por último, tenga cuidado de code smells.

3

Creo que la pregunta que debe hacerse tu mismo es ¿Es esta clase responsable de lo que está haciendo? Ser capaz de identificar y separar las responsabilidades es una piedra angular en OOP. Podría tener una clase Security con solo un método que cree una contraseña aleatoria, por ejemplo.

Creo (y esta es mi opinión) que si la contraseña aleatoria solo se utiliza en el registro, en lugar de crear un método privado de esa clase, separaría ese método en una nueva clase, Security, porque no No creo que sea una responsabilidad de la clase Register.

Además, dado que su aplicación es pequeña, podría ser perfectamente normal tener pocos métodos por clase.


Editar: Al ver su código podría hacer algunos consejos, pero tenga en cuenta que no puedo ver la imagen completa.

Si no lo has hecho, deberías leer acerca de MVC pattern, es posible que no tengas vistas en tu aplicación, pero separar los controladores de los modelos es una buena práctica.

Su DogFeedController parece ser un controlador, y GeneralFeedStrategy el modelo. Me gusta terminar el nombre de mis clases con lo que son. Por ejemplo, UserController, UserView y UserModel. Creo que esto aclara las cosas, pero de nuevo, esta es mi opinión.

No veo el sentido de tener iDogFeedStrategy pero, una vez más, no he visto toda la imagen. Los usos básicos de una interfaz son garantizar que un grupo de clases, sin importar cuán diferentes sean, tendrá la misma API y encapsulará los detalles de cada clase que implementa la interfaz.

+0

El controlador no es un controlador en el sentido de mvc. Tal vez una mala redacción por parte, tal vez gerente o generador sería una mejor palabra para describirlo. iDogFeedStrategy es parte del patrón de estrategia que estaba tratando de imimplement y GeneralFeedStrategy siendo el ejemplo concreto –

+0

@ user1189880 Ah ok, veo que sabe, entonces esta parte que usted está mostrando parece bien programada. Aunque todavía es difícil evaluarlo sin todo el código ... – eversor

0

Otro aspecto importante de la programación orientada a objetos, además de la separación de las preocupaciones es la cohesión de clase. La clase debería estar "tirando de su propio peso" en lugar de tener muchas otras cosas que llaman "getters" y hacer algo con la información. Cree interfaces si desea un comportamiento polimórfico o si planea ampliar su aplicación en el futuro. No cree interfaces solo por el bien de la separación. si las interfaces no están siendo implementadas por dos o más subclases, deshágase de ellas. (También puede usar interfaces para aplicar el principio de inversión de dependencia, para romper ciclos de dependencia)

Las decisiones de diseño en OOP siempre deben tomarse para abordar de forma consciente un problema específico. De lo contrario, mantenlo simple.

6

Desde un punto de vista general, tanto las clases que son demasiado grandes o por el contrario son demasiado pequeñas se consideran una mala práctica y se conocen como el llamado Código Olores. Los dos que me refiero son la gran clase (también conocido como Dios Objeto) y Clase Lazy (también conocido como Freeloader).

Estas son las definiciones de la Wikipedia y la Coding Horror:

gran clase: una clase que ha crecido demasiado grande.

clases grandes, al igual que los métodos de largo, son difíciles de leer, comprender y solucionar problemas. ¿La clase contiene demasiadas responsabilidades? ¿Se puede reestructurar la clase grande o dividirla en clases más pequeñas?

y

clase perezoso: una clase que hace muy poco.

Las clases deben hacer valer su peso. Cada clase adicional aumenta la complejidad de un proyecto. Si tiene una clase que no está haciendo lo suficiente para pagar por sí misma, ¿puede colapsarse o combinarse en otra clase?

Por otro lado, hay un principio para el diseño orientado a objetos llamado el interfaz Segregación Principio que establece que "Los clientes no deben ser forzados a depender de métodos que no utilizan". En su caso, las interfaces con menos métodos realmente se ajustan a este Principio.

Para resumir lo anterior, su diseño es más o menos correcta. Las interfaces con menos métodos son buenas para que las clases que implementan esas interfaces no tengan que implementar todos los métodos junto con los que no usan. En cuanto a las clases, creo que con el tiempo crecerán más. Solo recuerda que implementar una interfaz no significa que no puedes tener más métodos de los definidos en la interfaz implementada. Es decir, intenta poner más lógica allí.

Más sobre SÓLIDO, Principios de diseño orientados a objetos, se puede encontrar en el Wikipedia.

PS. Los olores de código son los síntomas de un mal diseño, y el SOLIDO es el tratamiento.

0

Prefiero un montón de objetos pequeños con relaciones complejas más de unos grandes objetos con relaciones sencillas ya que esto favorece la facilidad de mantenimiento y es más preparados para el cambio en el futuro.

Su diseño se ve muy bien para mí, teniendo en cuenta aún más que está empezando a programar ahora y principiantes siempre haces al revés.

Cuestiones relacionadas