No soy un gran fan del modelo C4.
Intenta conseguir una OOP ( Programación Orientada a Objetos ) antigua y simple, descomponiendo todo en los objetos componentes más pequeños posibles.
Al hacer esto, ignora los propósitos primarios de utilizar técnicas OOP en primer lugar:
- Abstracción de la complejidad
Esta es la parte más importante de la POO, ya que le permite hacer cosas realmente complejas, mucho más de lo que puede caber en su cabeza de una vez, y (en su mayoría) hacerlas bien.
- ¿Qué debo esperar de mi pasantía en Tecnología de la Información?
- ¿Merece la pena un título en tecnología de la información empresarial?
- ¿Cuáles son algunos recursos en línea para aprender sobre TI?
- ¿Es corrupto el sector de recursos humanos de TI en India?
- ¿Por qué cambiar una tecnología es tan difícil en TI?
El problema es que tiende a hacerlo en el límite equivocado. El límite más importante para lograr esto es la interfaz o el límite de la API.
Hacer cosas como evitar las interfaces de devolución de llamada, no hacer llamadas ascendentes a través de su capa de abstracción y así sucesivamente. Si solo realiza llamadas hacia abajo y lo hace en un límite de API, obtendrá la menor complejidad posible.
- Reutilización de componentes
Hacer un bazillion de componentes no es una manera de resolver un problema. Hacer el menor número de componentes útiles es.
Si tiene un componente, cuanto más intrínsecamente útil es, más probable es que sea reutilizado por la siguiente persona que lo sigue.
En otras palabras: la descomposición fractal de un problema en un enorme árbol de componentes no le ayudará a reutilizarse; También dañará seriamente el rendimiento de su aplicación para las aplicaciones que la utilizan.
Haga las cosas tan simples como sea necesario, pero no más simples.
- Sustitución / extensión de componentes
Esto a menudo se pasa por alto; también, con la misma frecuencia, se aplica mal en un proceso de desarrollo, haciendo que las cosas sean un infierno para el programador.
Está bien usar esto para, por ejemplo, extender un emulador de terminal para que ahora, en lugar de solo hablar a través de una interfaz en serie, ahora también pueda hablar a través de Telnet, porque reemplazó el componente de comunicaciones con uno que tiene la misma API.
Es una idea bastante horrible usar esto para probar y hacer crecer gradualmente un prototipo de un producto en un producto completo. Los programadores a menudo solo reescriben, en lugar de modificar, porque todos odian resolver un problema más de una vez; es su naturaleza
Ningún plan de batalla sobrevive al enfrentamiento con el enemigo; ninguna arquitectura de software sobrevive al compromiso con un gerente, una persona de marketing o un vendedor que desea que se agregue una función.
Hay otras características de la POO, algunas de ellas útiles, pero esas son las tres grandes.
No creo que C4 los maneje bien.
Creo que solo tiene que intentar usar el producto Números de Apple para ver una falla masiva atribuible a un enfoque C4 para resolver un problema de programación.
Cada dígito en la pantalla es un objeto. Se vuelve exponencialmente más lento cuanto más datos pones en la cosa. Es casi imposible agregar características. Los recálculos de la hoja de cálculo son muy, muy lentos.
Recomiendo evitarlo.