¿Es objetivo el SRP (principio de responsabilidad única)?

Considere dos diseñadores de UI que desean diseñar diseños "atractivos para el usuario". La "atracción del usuario" es un concepto que no es objetivo y solo reside en la mente de los diseñadores. Así, el diseñador A podría elegir, por ejemplo, el color rojo, mientras que el diseñador B elige el azul. El Diseñador A crea un diseño que es completamente diferente del diseñador B, y así sucesivamente.

Leí sobre SRP (Principio de responsabilidad única) y lo que entendí fue una especie de análisis subjetivo o desglose de responsabilidades que pueden variar de un diseñador OO a otro diseñador OO. Estoy en lo cierto? En otras palabras, ¿es posible tener dos excelentes analizadores y diseñadores orientados a objetos que presenten dos diseños diferentes para un sistema basado en el principio SRP?

Una buena pregunta y una que solía reflexionar a menudo.

Yo diría que no objetivo, no. Definitivamente subjetivo. La forma en que aborde la resolución de los problemas depende de su filosofía hacia ese tipo de problema. La ciencia nos muestra que puede haber muchas formas diferentes de resolver el mismo problema de manera efectiva. La ciencia también nos muestra que las personas en continentes separados pueden encontrar las mismas soluciones de forma independiente, por lo que algunas soluciones son más obvias que otras. En cualquier caso, juzgar las soluciones en términos de "mejor" depende de sus criterios.

Realmente, lo que uno podría ver como dos partes del mismo todo, otro podría verlo como dos conceptos totalmente separados. Uno ve esto todo el tiempo cuando observa cómo los encargados del mantenimiento de diferentes bibliotecas de código abordan el mismo problema. Y, sin embargo, ambas soluciones funcionan bien.

(PD. Editó esta respuesta ya que la pregunta final del OP hace lo contrario del título de la pregunta).

El principio en sí es objetivo, pero hay tantas formas diferentes de implementar algo que sigue el principio, que dos desarrolladores independientes casi siempre encontrarán diseños de sistemas bastante diferentes para la misma aplicación.

Incluso es probable que el mismo desarrollador que realiza el mismo diseño dos veces, todavía presente dos soluciones que difieran al menos parcialmente.

Para que un principio haga que los diseños del sistema se vean siempre iguales, tendría que cubrir todos los aspectos de las decisiones de diseño. El director de responsabilidad única solo cubre una pequeña parte de las decisiones de diseño involucradas en la realización de cualquier diseño de sistema.

La aplicación del principio es subjetiva. Sin embargo, "subjetivo" no equivale a "preferencia" de la misma manera que la estética.

Hay extremos obvios. Una clase con exactamente un método, con solo unas pocas líneas de código, que no llama a ninguna otra clase, definitivamente está siguiendo el SRP. Por otro lado, una clase con dos métodos, uno que contiene una implementación completa de correo electrónico a través de sockets sin procesar y otro que crea un formulario GUI, definitivamente no está siguiendo el SRP.

La estética es una analogía pobre. Una mejor analogía sería los conocidos conceptos informáticos de acoplamiento y cohesión . Ninguno de estos son atributos en blanco y negro, verdadero o falso. Sin embargo, son medibles, incluso si hay un elemento cualitativo. Si le muestra a un grupo de desarrolladores experimentados dos diseños separados para la misma característica, le darán lecturas similares sobre qué diseño tiene más acoplamiento y / o cohesión.

De hecho, el SRP es esencialmente solo cohesión funcional. Dice que las partes de algún módulo (por ejemplo, clase) deben agruparse porque todas contribuyen a realizar la misma función, y por ninguna otra razón. La "función" puede estar sujeta a interpretación: algunas personas pueden interpretar esto literalmente como una declaración de función única (o método o procedimiento) , otras pueden retroceder un poco y pensar en una función como "enviar correo electrónico" o "reproducir música" , pero todavía hay mucho espacio para maniobrar. "Gestionar cosas" no es una descripción funcional válida.

Hay una definición objetiva de la "responsabilidad" como una "razón para cambiar". En el momento de la programación, todas las razones para cambiar se encuentran en el futuro, por lo que el programador solo puede adivinar en función de su experiencia y conocimiento del dominio. Por lo tanto, analizar las responsabilidades es una especie de pronóstico, en parte subjetivo.

SRP es objetivo; las implementaciones son subjetivas

dos implementaciones con exactamente la misma funcionalidad pueden usar estructuras internas completamente diferentes, lo que da como resultado diferentes clases y métodos, y ambos pueden satisfacer SRP

si usan los mismos métodos y estados, y ambos están normalizados (mínimo / no redundante), en teoría terminarán con las mismas clases y métodos bajo SRP.

Pero no puedo probarlo. Todavía.