Arquitectura de software: principios meta y SOLID para desarrolladores C#

1. Promo: Hola. Bienvenido al curso software, arquitecturas, materia y principios sólidos. Yo soy Pongamos una chispa K de lesión de lesiones park dot com, y te van a estar dejando para el curso. Empecé mi carrera. Un supuesto graduado Estudiantes que participan en concurso Microsoft Imagine Cop. Llevo trabajando con el Dr Left desde 2003. He sido arquitecto profesional en la implementación de software desde hace casi siete años, principalmente basado en la plataforma de red DOT. Me apasiona construir alcance y aplicaciones poderosas utilizando tecnologías modernas. Soy especialista certificado en aplicaciones de Windows en aplicaciones de comunicación de servicios por Microsoft. Y aquí está mi enfoque docente. Sin trama, sin despotricar, sin vencer al equipo de hielo aéreo su tiempo. El material del curso es de 16 aún completo. cubren constantes importantes completas. Particularmente importante. Los temas se cubren en profundidad para principiantes absolutos. Ofrezco mi ayuda en Skype absolutamente gratis si se solicita. Toma este curso y te fijarán sus cinco. Solar es un acrónimo, que significa S R. P o c p, L S P y D E F e. otros cinco Konitz Estos cinco crímenes a su vez representan principio de responsabilidad única . Abierto cerrado Principal Lisk de sustitución Principio en remolque. Enfrentar principio de segregación y dependencia. Invertir inferencia. En estas canchas, aprendes a volar sólidos y meta principios para que tu aplicación viva una vida larga, saludable. Significa que vas a aprender a escribir código de alta calidad, legible en el estándar y confiable. Mejora tus conocimientos en programas orientados a objetos. Entenderlos en los principios en los que, sobre el otro inicio principal de desarrollo basado. Entiendo los síntomas de los defectos de oro. Fundamentos aprendidos de principios sólidos. Aprende a detectar violaciones de principios sólidos y cómo solucionar los problemas. Conoce cómo se relacionan los metaprincipios y los principios de Sony y cómo encontrar el equilibrio entre. A pesar de que See Shop es una región muy cuenta con lenguaje, es muy común ver aplicaciones mal diseñadas e implementadas en el mundo real. lenguaje de programación por sí mismo no garantiza que las aplicaciones arquitectónicas sean geniales. Para diseñar y construir software mantenible, necesitamos entender los principios del desarrollo de software. El video, por supuesto, es exactamente acerca de cómo lograr un software limpio y mantenible que probablemente ya has lastimado con la siguiente declaración conocida mundial. La mayoría va bien a Sox, su curso es todo acerca de cómo producir código, que no apesta. Votar excusa de producir y tiempos bien diseñados y bien implementados es el requisito previo para que los otros desarrolladores te traten como un profesional decente. Este curso está dirigido a desarrolladores de nivel medio y alto. Fuera de curso. Alguna experiencia. Ver tienda se requiere. Si eres programador junior, entonces yo diría que hay que tener menos salud del Año del Mundo Real Experiencia en desarrollo empresarial. Si no sabes trabajar en estudio visual, este curso no es para ti. Y aún. Son abundantes los buenos ejemplos a lo largo del discurso para que aprendas tanto material práctico radical . Empezando con negocios sólidos. Vamos a ir más allá al asunto. Príncipe pasando por el sólido trae. También aprenderás sobre los asuntos relacionados. Entonces llegaremos al problema fuera de las contradicciones entre principios diferentes. Se aprende sobre las relaciones entre impresiones solares en impresiones metálicas en general, aprende este curso cinco principio sólido srp gossipy L S P. Hablo día. Estos son los principios sólidos. Aprenderás los problemas de fondo que se pueden resolver por principio particular. Verás las demostraciones en código, aprendes que relacionan presencia con cada principio aprendiendo que siendo tú además aprendiste lo que es inversión de inyección de dependencia del control. Veo contenedores cómo construir un simple contenedor RC. ¿ Y cuáles son las implicaciones arquitectónicas de la inyección de dependencia? Estos son los otros temas que aprendiste en este curso Seco. No te repitas. Principal mantiene principal. Mantenlo sencillo. Estúpido patio Nuevo principal U N va a necesitar calcetín principal Separación de preocupaciones Enfermos U. S. consulta de comando principios de separación la ley fuera del medidor y por principio de lista asombro, ocultación de información y encapsulación AP I Desarrollo Trae supongamos contradicciones entre contradicciones sólidas y Yarden entre OCP y jóvenes Qué es arquitectura y diseño conseguirás tonos son muy importantes para conocer información en rol y empezar a aprender el sólido y el metal principios de la construcción de sistemas de software. 2. Esbozo de 01: Hola. Este es el último para divertirse de spot ingeniero de hornear. Y en esta sección, vamos a aprender dónde están los principios. Nos referimos a los principios de los que vamos a hablar en esta sección en cuanto a los principios de la materia porque son las raíces de todos los demás principios más concretos adheridos a los que realmente estamos tratando de conformarnos con los principios de la materia. Empezaremos desde la secadora. No te repitas principio. Aprendes la definición de los olores más comunes de violar el principio seco. Después de eso, aprendiste las llaves o lo mantuviste simple. Principio estúpido. Aquí vamos a hablar de simplicidad y complejidad, complejidad accidental y esencial y cómo lograr la simplicidad. El siguiente meta principio del que vamos a hablar es el yo joven o no lo vas a necesitar principio. Está relacionado con el olor innecesario complejidad y se refiere a las anticipaciones fuera de las características comunes . Analizaremos los problemas prácticos a los que nos enfrentamos y qué otras consecuencias la implementación de características que realmente no necesitamos. Después de eso, vamos a hablar del principio de calcetín o separación de preocupaciones. Este principio subyace al incienso. Todos los principios sólidos. La separación de preocupaciones es muy importante para lograr aplicaciones bien mantenibles. Verás las formas más comunes de violar la separación de preocupaciones. Principio Comando principio de separación de consulta hace más fácil razonar sobre. En el código se discutirá el mínimo de Demeter, que es el principal conocimiento fuera de la lista. Por separado, hablaremos del principio fuera menos asombro usted. Después tocaremos el tema de la ocultación y encapsulación de la información. Por cierto, utilizaré la palabra principio en lugar de principio de materia en esta sección. Además, sólo por el bien de ahorrar algún tiempo en la próxima conferencia, aprende sobre el principio seco. Empecemos. 3. Introducción de 02: Hola, Este es Ingeniero Spark, y te estaré guiando por el curso antes de investigar cuáles son los principios sólidos y cómo aplicarlos correctamente. Tenemos que entender ¿por qué los necesitamos en absoluto? Entonces que los principales son todo sobre diseñar software pero ¿qué está diseñado? ¿ Cómo definir el software Design off? Robert C. Martin, en su libro A Child Principles, Patterns and Practices in C Shop, afirmó que el diseño fuera del software es el propio código fuente. Modern Folder escribió en su blawg que la arquitectura es la forma que va toma. ¿ Por qué esto es así que los ingenieros producen documentos, planos que especifican cómo construir un producto. Lo único que realmente especifica cómo funciona el software es el código fuente. Se puede decir que el código fuente es el producto, pero el producto es el programa en ejecución, no el código fuente en sí. Mira esto desde la siguiente perspectiva. ¿ Cuál es la entrada a fábrica fuera de placas de circuito? Diagramas especiales de electrónica en el caso fuera de desarrollo de software para Hare a Factory, que es compilador de oro, lo alimentamos por el código fuente. Un compilador construye software utilizando el código fuente, y esto lleva a pensamientos interesantes con respecto a los costos, modelar software de construcción y, dicen casas. Cuando construimos una casa, es mucho más barato crear un buen diseño por delante en lugar de reconstruir una casa entera. Si no nos gusta el resultado, simplemente no es factible reconstruir una casa cada vez. No nos gusta el resultado. Lo contrario podemos decir sobre el desarrollo de software. Podemos construir bine Aries en un minuto. términos generales, diseño inicial grande en caso de que fuera el desarrollo de software es mucho más caro que dibujar un boceto, construir el software y luego modificarlo en el camino. El proceso de desarrollo de software es algo único porque al realizar un diseño inicial grande , realidad no podemos garantizar que tomemos en cuenta todos los requisitos posibles. El software es la sustancia fluida, y los requisitos tienden a cambiar muy rápidamente porque fuera de tal fluido, naturaleza incierta fuera de los requisitos de software, necesitamos mantener constantemente el diseño tan limpio como podamos, diciendo limpio. Me refiero a esto mantenible como podamos para determinar donde el código fuente está limpio o no, necesitamos marcar fuera de la ciencia de los desarrolladores de putrefacción de diseñadores se refieren a dicha ciencia. Eso es olor de diseño. Podemos marcar cinco grandes diseños, olores, rigidez, rigidez, il ity francés, inmovilidad, viscosidad y complejidad innecesaria. Vamos a definirlos uno por uno. El software es región. Si el costo de hacer un solo cambio es muy alto, si algo muy simple tarda muchas horas en implementarse que el software es región. Para superar este problema, es posible que necesite rediseñar el software. El origen primario off rigidez es el alto acoplamiento entre módulos. Cuando los módulos están bien acoplados, entonces es muy difícil introducir cualquier cambio con facilidad. El más suave es frágil cuando los pequeños cambios en un módulo causan apariencia de caja en otros, a veces incluso módulos no relacionados. El olor también suele ser causado por relaciones mal diseñadas entre módulos, dedo del pie superar la fragilidad. Necesitas dependencias aisladas del dedo del pie. El software está en modelo cuando sus componentes no pueden ser reutilizados en otros sistemas. La mayoría de las veces, deberíamos poder extraer un componente sin demasiados esfuerzos y adaptarnos para usarlo en otro sistema y ¿qué se sorprende? Es muy probable que el olor sea causado por el acoplamiento apretado entre los componentes. Para superar este olor, necesitas desacoplar bien los componentes. El más suave es viscoso al agregar una sola característica evoca lidiar con toneladas de aspectos, entre ellos decir transporte, capa, marshalling de seguridad y esas cosas. En la práctica, también se puede detectar el olor observando corazón para realizar pollos, checkouts y fusiones. Y lo más probable es que la razón principal del olor sea el acoplamiento apretado entre los componentes. El más suave es innecesariamente complejo cuando los desarrolladores todo el tiempo están tratando de pronosticar el futuro. Anticipando los próximos cambios, introduciendo puntos excesivos de los desarrolladores de extensiones deben concentrarse en los requisitos actuales . Deberían construir la arquitectura flexible que pueda bandas para poder cumplir con nuevos requisitos. No se necesita rumbo. Puntos fuera extensión aún es una mala práctica lo que lleva a cualquiera de esas complejidad. ¿ Te diste cuenta de que casi todos los olores están relacionados con las dependencias de cama Manejo. La mayor diferencia entre los lenguajes orientados a objetos y no orientados a objetos es que otros lenguajes son capaces de aprovechar el apagón despacho dinámico Mediante el uso de funciones e interfaces virtuales , podemos invertir las dependencias en o idiomas. Cuando hacemos una llamada, no sabemos qué objeto manejará esa llamada. Esto se debe al polimorfismo o al despacho dinámico. Por lo que la clave para lograr una buena arquitectura es administrar bien las dependencias. Y aquí llegamos al punto en que estamos listos para hablar de principios sólidos. Los principios sólidos son cinco principios que pueden denominarse principios de gestión de la dependencia . Todo se trata de relaciones y operaciones entre objetos. En este volumen, vamos a sumergirnos profundamente en los principios sólidos. El acrónimo sólido fue introducido por primera vez por Robert Martin. A k tío Comprado Solid implica cinco principios fuera del desarrollo de software, SRP Principio de responsabilidad única. También estar abierto. Principio cerrado ls ser principio riesgo de sustitución. Hablo en cara principio de segregación y el principio de inversión de dependencia i p. Menú de estos principios se basan en la obra clásica de Bertrand Meyer. Vamos a discutir todos los principios uno por uno, mirando ejemplos de mal diseño y cómo solucionarlo. Aplicando un principio apropiado. También notaremos la diferencia entre las definiciones de Myers y Martin fuera de algunos principios. ¿ Qué es también importante para una comprensión profunda? Lo que también quiero enfatizar es que los principios sólidos no están vinculados a ninguna tecnología. Se pueden aplicar en cualquier lenguaje de programación en trabajo de por ejemplo. Otro punto es que sólido no es un objetivo por sí mismo. El caso es que el código totalmente sólido es un oxímoron. Es imposible escribir software, lo que confirma sólido en cada línea. Es imposible medir el nous sólido fuera de la base del código. Sólidos son los cinco principios que nos ayudan a crear un mejor software. Ellos implican una gran cantidad de filosofía, y se podría pensar que esto es malo. Bueno, puedes tratarlo como un piso, pero en realidad no lo es. Es muy importante sentir esta filosofía de diseñar más suave para convertirse en un mejor desarrollador. Y en este curso verás a todos los trade offs que enfrentan los desarrolladores aplicando principios sólidos . Sentirás la filosofía de diseñar software. De acuerdo, has aprendido los olores de diseño común y que aplicamos principios sólidos para eliminar ese olor. En la próxima conferencia, nos sumergiremos en principios sólidos, comenzando con esbozo fuera de la sección SRP. 4. Declaración de problemas de 03: el principio de responsabilidad única o un Sarpy en pocas palabras establece que todo objeto debe tener una sola responsabilidad, y que la responsabilidad debe estar completamente encapsulada por la clase. Esta definición está tomada de Wikipedia. Es muy difícil de entender. ¿ Qué significa? Por ejemplo, las primeras 2 preguntas que me vienen a la mente son cómo definir esas responsabilidades y cómo calcular el número fuera de responsabilidades de una determinada clase. Dichas definiciones no son muy útiles desde la perspectiva práctica. Robert Martin, un tío clave Bob, aclaró esta definición diciendo que nunca debería haber más de una razón para que una clase cambie. Suena mucho más claro, aunque es demasiado necesita más aclaraciones. Las responsabilidades de una clase pueden ser tratadas como cambio de acceso fuera. Podría ser más sencillo entenderlo como acceso a los requerimientos cambiantes, por ejemplo, en la clase implementa, registro y cobro por sí solo. Entonces tiene al menos dos responsabilidades. También podemos ver las responsabilidades de una clase desde la perspectiva fuera de sus usuarios cualquier a p I tenga sus usuarios. Estos usuarios son la fuente de cambios, entendiendo que podemos calcular cuántos exceso de cambio tiene un vaso. Por ejemplo, si la clase trata con una base de datos, entonces tenemos una x de cambios ya que DB Architect's son aquellos usuarios que pueden solicitar cambios . Si ese vidrio trata también de reportes de apio, entonces hay que exceder las escenas. Contadores son aquellos que pueden solicitar cambios a reportes. Al parecer, entre más responsabilidades tenga una clase, más probabilidades se va a cambiar. Entonces aplicando la SRB, queremos separar diferentes preocupaciones. Una clase debe hacer una cosa y hacerlo bien. Por cierto, se puede aplicar el mismo principio a nivel de módulos. Los módulos deben tener una sola responsabilidad lógica, por lo que el SRP se puede aplicar en diferentes niveles a nivel funcional, nivel de objeto y a nivel de módulo. En ocasiones encontramos violaciones de SRP a nivel de funciones fueron un factor fuera distintas responsabilidades a las gafas, y luego separamos las gafas por sus responsabilidades en diferentes módulos o una semblanza. Si lo desea discutimos el SRP, pero podría preguntarse cómo se ve el problema concreto en la vida real causado por la violación del SRP . Imagínese los problemas que son causados por la violación del SRP. Aquí tenemos una clase. Míralo ¿cuántas responsabilidades tiene? Veo al menos cuatro dependencias. Vamos a contarlos. El primer método, llamado cobro, es el responsable de interactuar con la terminal bancaria. Debe saber inicializar un dispositivo correctamente y enviarle un comando correspondiente. El siguiente método oro Crear Reporte sabe rallar un reporte sobre la transacción de pago . Sabe formatear todo el día a apropiadamente. Los informes suelen ser tan complejos que hay dos responsabilidades pueden estar ocultos. Una preocupación separada podría ser el proceso de creación de aeropuerto, y la segunda es el formato en sí. Si el proceso de creación de un objeto es demasiado complejo, entonces muy a menudo tratamos como una preocupación separada y nos volteamos del pie aislamos tales responsabilidades extrayendo la clase er de afecto, que conoce todos los detalles sobre la creación de informes. El tercer método, llamado Trae Report, sabe cómo lidiar con el controlador de impresoras y cómo enviarle comandos. Y por último, el método de pago seguro es responsable de interactuar con una base de datos. Para guardar todos los datos sobre una transacción de pago, muchas veces tenemos una responsabilidad oculta. En tales casos, podemos llamar a eso orquestación de responsabilidad. A menudo necesitamos algún objeto de alto nivel, que sepa integrar todas las responsabilidades juntas. Ahora imagina que necesitamos cambiar el pago, procesamiento y ahorro a una base de datos simultáneamente. Dos programadores diferentes son los responsables de estas dos partes diferentes del sistema. Desafortunadamente, estas dos partes diferentes recitan en la misma clase. En consecuencia, estos dos programadores necesitan cambiar la misma clase, y en ese entonces necesitarán fusionar sus cambios para terminar un check in. Aparte de este problema, tales gafas, que un camello? Ocho muchas responsabilidades son difíciles de entender. Tales gafas se convierten en una gran bola de barro. Algún día nadie entenderá qué demonios está pasando en ese vaso. Otro problema es que a veces necesitamos introducir cambios en una sola responsabilidad . Digamos que necesitamos cambiar el procesamiento de pagos porque varias responsabilidades re lado en las clases de objeto único que las representan también muy compiladas y redesplegadas. Hoy en día, este problema en la mayoría de los casos puede parecer no un problema en absoluto. Pero por ejemplo, si nos desarrollamos en C plus, entonces puede causar algunos problemas. Al final. El caso es que tal actitud descuidada ante la gestión de dependencias conduce a una compilación larga El tiempo C plus plus es mucho más difícil de compilar, por lo que este problema es muy importante En tales casos. Si hubiéramos aislado estas dependencias en diferentes módulos, habríamos necesitado volver a compilar bajo redeploy solo un módulo, el módulo, que ha sido cambiado así fue como arpías violaron responsabilidades. Empezar a KAL ocho entre sí. ¿ Qué significa que se emparejan? Lo que tenemos que esforzarnos por hacer es reunir todas las mismas responsabilidades juntas y separarnos unos de otros, aquellas que son diferentes. Cuando reunimos las mismas responsabilidades, tratamos de lograr la llamada alta cohesión. Cuando separamos responsabilidades diferentes, tratamos de lograr un bajo acoplamiento a nivel de funciones. Cohesión significa lo siguiente un conjunto de funciones y en cara se considera cohesivo. Cuando cada función está estrechamente relacionada con otra, acoplamiento indica cuán dependientes están los módulos en el funcionamiento interno uno al otro. Los módulos fuertemente acoplados se basan ampliamente en el estado específico uno al otro, compartiendo variables y muchos tipos. módulos ligeramente acoplados son bastante independientes. Tienen algunos ojos AP bien nombrados y comparten una cantidad limitada de descuento o ningún dato en absoluto. De acuerdo, veamos el problema de una violación de Sarpy en Visual Studio en otro ejemplo. 5. Demo del problema: esta conferencia se titula Ellis Be Violation Demo. Consideremos un ejemplo clásico de Phyllis P. Violación. Me encanta este ejemplo por dos razones. El 1er 1 es que en realidad demuestra la violación L S P, y esta razón es obvia. Y la segunda razón es que muestra que la programación orientada a objetos a menudo puede mapear directamente las relaciones entre los objetos en el mundo real en el mismo modelo fuera las relaciones entre ellos en código. Un gran número de desarrolladores piensan que al escribir código en lenguaje Hopi, están modelando problemas de dominio del mundo aéreo. Y en parte esto es cierto. Pero las relaciones del mundo real entre objetos a veces pueden ser motiles directamente en lenguaje opie . Aquí te dejamos una de las declaraciones esperanzadoras ingenuas gafas infantiles. Implementar es una relación con clases basadas. Por ejemplo, perro es un gato animal es un animal, por lo que podemos crear tres clases. Animal es la clase base, y los otros dos son herederos. Desafortunadamente, a veces este tipo de diseño no funciona como se esperaba, y lo verás en un minuto. Entonces, reflexionemos en código las relaciones entre dos nociones del mundo riel. Queremos implementar un rectángulo y cuadrado pudiendo calcular sus áreas. Seguro que estarás de acuerdo conmigo en que en la Plaza del Mundo real es un caso especial fuera de rectángulo . Es otros porque el cuadrado es un rectángulo con lados iguales. De acuerdo, pasemos a estudio visual. Vamos a crear un rectángulo y un cuadrado. Creé la clase de rectángulo, que tiene dos propiedades con y altura, y el cuadrado, que hereda de su clase de enredo. Por separado, crearé la clase, que se encarga de calcular las áreas de esas formas. Se ve bien. Desde el primer lado. Voy a fingir que soy cliente y quiero crear dos formas y calcular sus áreas. Para eso, implementaré el método principal donde sucederán todas las cosas que primero, solo crearé un rectángulo con igual a dos y ocultar igual a cinco. Después de eso, llamaré al método de ángulo correcto ST IC Cal y obtendré el resultado, y también envío el resultado a la consola. Ahora quiero crear un cuadrado. Espera un minuto. ¿ Qué demonios es esto? Cómo un cuadrado puede contener lados de diferente longitud. Ni siquiera voy a ejecutar el programa, ya que es obvio que algo anda mal aquí con una pila de cuadrado cuadrado permite establecer diferente longitud a anchura y altura. Este diseño viola claramente la lista de sustitución. Cuadrado principal no es sustituto hable para rectángulo implementa el en variante , que establece que el ancho y la altura podrían estar desactivados. Diferente Plaza de Tierra tiene que implementar otra en variante que establece que el ancho y altura tienen que ser iguales. Eso lo omito intencionalmente. En realidad también tienen que ser mayores o iguales a cero. Ahí hay otro problema es esconderse aquí. Lo más probable es que necesites crear métodos que tomen el rectángulo como parámetro e implementen alguna lógica empresarial. En caso de calcular la era, tal método podría verse así. Este método comprueba el tipo del parámetro aceptado y ejecuta el algoritmo de cálculo apropiado . ¿ Qué opinas? ¿ Es una buena manera de definir métodos en toda la base de código que tienen que trabajar con rectángulos? ¿ No te parece algo que hemos visto anteriormente? Sí, efecto, esto es una violación al principio abierto de cierre. Este método está abierto para su modificación. ¿ Qué pasará si introducimos una nueva forma? Correcto. Tendremos que modificar. Es por eso que afirmación este ejemplo de violación de Gillespie es una violación oculta fuera de OCP. En la próxima conferencia, veremos cómo solucionar este problema 6. 05 refactoring de un diseño mejor: Obviamente necesitamos hacer imposible el ajuste de diferente longitud fuera para que un cuadrado solucione el problema. Por ahora, las expectativas de los clientes de plazas están rotas. El aire, una clase de calculadora ahora demuestran que hay un problema fuera de los datos y el comportamiento separados . Los algoritmos de cálculo están separados de los vidrios rectángulo y cuadrados, que poseen los datos requeridos para los cálculos. El calculador de área no puede existir sin rectángulo y cuadrado. Entonces por qué el comportamiento se alejó del rectángulo y rectángulo cuadrado y cuadrado por ahora, obviamente carecen de cohesión para curar la enfermedad, donde siempre debe construir abstracciones adecuadas. Lo que queremos obstruir es la lógica empresarial de calcular el área. Cada forma tiene su propio algoritmo fuera de cálculo. El área. Es mucho mejor hacer que el comportamiento sea compartido en lugar de datos. Obstruyamos el método de cálculo del área introduciendo la interfaz en forma de I. Quiero que el rectángulo y el cuadrado hereden de la forma del ojo. Implementando sus propios algoritmos, Square ahora define su propia propiedad llamada longitud lateral. Ahora un cliente no puede hacer mal uso. Es un P I. Aquí hay un ejemplo de un cliente en caso de llamada de rectángulo para calcular área, Un cliente dará el área de un rectángulo, mientras que en caso de cuadrado, un cliente obtendrá el área de un cuadrado. El cliente puede establecer diferente longitud, ancho fuera y altura a un cuadrado. Genial. En la próxima conferencia, veremos otras formas de salir de ls ser violación. 7. 06 ejemplos de violaciones de SRP: aquí tenemos un método llamado Get Reppert en el cuerpo. Podemos ver que reúne algunos datos estadísticos, luego crea cadenas formateadas y las juntan. ¿ Cómo te parece? ¿ Este método viola SRP? Con este método claramente viola el SRP. Tiene dos responsabilidades. El 1er 1 recogiendo los datos estadísticos y el 2do 1 es formatear. Los programadores junior muy a menudo hace fuera de curso la responsabilidad de formateo con lógica empresarial . En ocasiones si estamos seguros para el 99% de que el formato nunca se cambiará y no interfiere con el otro frío. Podemos dejar tales ciudades de código s, pero lo más probable sería mejor al menos extraer el formato en un método separado. Echemos un vistazo a otro caso. Aquí tenemos el dispositivo de alarma de hallazgo. Escanea a través de puertos serie tratando de encontrar el dispositivo. Y si lo encuentra, establece un estado global mediante el establecimiento de la alarma se puede utilizar propiedad. ¿ Cómo te parece? ¿ Este método viola el SRP? Pero este método claramente viola el SRP. Hace es que la política o lógica empresarial con mecánica recuerden que la política de alto nivel debe desacoplarse de los detalles de bajo nivel podríamos re factorizarla introduciendo una clase especial la cual se encarga de interactuar con el estado global. Ese vidrio podría recibir notificaciones por eventos o cualquier otra forma apropiada. Echemos un vistazo al siguiente caso. Aquí tenemos el método llamado dibujar Rectángulo. Calcula dónde dibujar un rectángulo, luego toma un enfriador y dibuja el rectángulo sintiéndolo con ese color. ¿ Cómo te parece? ¿ Este método viola el SRP? Este caso es más complicado que los anteriores. Los ejemplos anteriores demuestran olores muy populares de violar el SRP. Es más difícil determinar sus responsabilidades aquí. El número de responsabilidades fácticas siempre depende de los usuarios, otros actores o usuarios que pudieran estar interesados en administrar el color. Si hay tales usuarios, entonces podría ser mejor separar la responsabilidad de escoger a una persona que llama. Una pregunta interesante separada es si la creación a menudo objeto es en sí misma una responsabilidad o no. No vamos a contestar esta pregunta en este apartado. Lo mantendremos para la sección sobre D. I. P. Al final, también quiero al menos algunas violaciones comunes de SRP primero, mezclando lógica e infraestructura cuando la lógica empresarial se mezcla con vistas o una persistencia. Capa un vaso o un módulo, atiende a diferentes capas, calcula ingresos y envía correos electrónicos, Bar dice XML y analiza los resultados antes de ir más allá. Yo sólo quiero escatimar a través de una función que me enfrenté en la práctica. Esta función tiene alrededor de 5000 líneas de largo. Consiste en off switch case, y si las declaraciones, se basa en ellas masivamente. Este es un ejemplo muy infernal andan extremo. Off SRP violación. Quería mostrarles este ejemplo sólo por diversión. La mayoría fuera de los desarrolladores no me creen cuando digo que he visto tal función. No existen tales funciones, y también existen desarrolladores que escriben tales funciones. Como pueden adivinar, en la próxima conferencia, quiero decir un par de palabras respecto a los patrones diseñados relacionados con el SRP. 8. Patrones de SRP: En ocasiones aplicamos el SRP al reflector aparte de un sistema, y terminamos con muchas clases pequeñas. Clientes fuera de tal A p. Puedo tener problemas para entender toda la parte del sistema porque necesitan entender sus relaciones entre todos esos vidrios de humo. No es tan malo como suena. Como ya he dicho, siempre hay un intercambio entre diferentes soluciones en tales casos. Por lo tanto, patrón de calcetín puede venir al rescate. Envuelve todos esos anteojos, simplemente delegándoles todas las responsabilidades a ellos. No hace de la fachada un violador de la SRP. La única responsabilidad fuera de tal fachada es juntar la funcionalidad requerida por el cliente . Puede parecer que viola este R P, ya que veremos las responsabilidades fuera de diferentes capas reflejadas en el FBI fuera de la fachada. Pero como dije, agregar la funcionalidad que permite resolver un solo problema de clientes no está mal. Simplifica el proceso de interacción con el sistema desde la perspectiva del cliente, y eso es todo. Nada más así. Existen dos millones de razones para usar la fachada. Proveer mejor para un cliente, un simple A p I para la interacción con un conjunto de objetos complejos y proveer para un cliente un FBI más limpio para la interacción con mal diseñado A P I. A veces es mucho más fácil desplegar si Assad, en lugar de una reescribir una parte mal diseñada fuera de un sistema. Y de esto se trata el segundo punto de la SRP es prospecto. Nos interesa el ejemplo, que demuestra la primera razón fuera usar mejor la fachada. Aquí se puede ver un diagrama, que demuestra un ejemplo de la fachada. Mejor. Aquí puedes ver que la clase de fachada de compra depende de todas las demás clases que contiene o, en otras palabras, envuelve todas estas clases. tienen por qué ser clases las entidades envueltas. Podrían ser interfaces también. Entonces imagínense que inicialmente un cliente dependía de todas estas gafas. Presentamos la fachada para simplificar el proceso de indirección con el sistema. Si un cliente depende del en la fachada, no tiene que interactuar directamente con muchas clases. Pasemos a estudio visual, donde mostraré este ejemplo en código. Aquí un ejemplo. Digamos que tenemos un cliente que utiliza nuestro sistema para vender bienes de la tienda en línea, por lo que el código de clientes se ve así. Crea un objeto de cliente utilizando el método ST Ik. Encontrar cliente pasando significa el cliente i d. Después de eso, crea una carga a través del IQ estatal. Encuentra método fuera de la clase de acciones, pasando en lo bueno i D. Luego se obtiene la información sobre la tarjeta de crédito del cliente, crea la pasarela bancaria y llama a la tarjeta de cargo pasando los parámetros requeridos. Apuesto a que tal proceso de indirección se ve como una burla efectivamente. Es nuestro deber simplemente archivar vidas de nuestros clientes para que podamos crear una fachada que oculte todos estos detalles procesando una compra que creé aquí. El Compra de la clase fachada, que expone un solo método. Este método requiere dos parámetros enteros y oculta todos los detalles dentro de su cuerpo. Ahora un cliente no tiene que saber de todas las gafas y cómo interactuar con ellas, qué métodos llamar. Lo único que el cliente debe saber es que puede simplemente genial si Assad y llamó a un método para lograr el objetivo. Eso es todo. Hay muchos patrones los cuales están relacionados con un decorador Sarpy y las recámaras compuestas también están muy estrechamente relacionadas con su Sarpy, acuerdo con la definición del patrón compuesto de cuaderno Banda de Cuatro permite componer objetos en estructuras de árboles para representar jerarquías parte enteras. Patrón compuesto. Echemos un vistazo. Tratar los objetos individuales y las composiciones fuera de los objetos de manera uniforme. De acuerdo con el mismo libro. El patrón decorador permite agregar el comportamiento a un objeto individual, ya sea estática o dinámicamente, sin afectar el comportamiento de otros objetos de la misma clase. El patrón decorador suele ser útil para adherirse al principio de responsabilidad única ya que permite dividir la funcionalidad entre clases con áreas de preocupación únicas. No vamos a discutir profundamente la presencia del diseño en este curso, así que solo puedo recomendarte algunas fuentes para que lo busquen para obtener una comprensión más profunda de los veteranos del diseño y su relación con principios sólidos. 9. Conclusión de 08: esta conferencia se titula Conclusión. El principal que discutimos a lo largo de esta sección fue el príncipe de segregación de interfaz o hablo en camisa, hay P tiene una definición sencilla. No se debe obligar a los clientes a depender de métodos que no utilicen. Por lo que esta definición implica que hay que esforzarse por las interfaces grandes, pequeñas, cohesivas y enfocadas. Por supuesto, diferentes clientes pueden usar sólo un subconjunto de los miembros del FBI de los que dependen. A menos que ese AP, empiezo a crecer transformándose en una interfaz muy gorda con miembros no relacionados entre sí , donde, cuando aparecen métodos similares pero diferentes para satisfacer los requerimientos de diferentes clientes . Una forma típica de violación que viste, era cuando una interfaz era demasiado amplia. Lo que llevó a algunos olores como implementador tiro no implementado excepción o los clientes tienen que ver toda la masa en la inteligencia pensando en lo que realmente necesitan usar como discutimos , hay varias formas de lidiar con hablo violaciones. En ocasiones basta con extraer una interfaz separada de una gorda y utilizarla cuando corresponda. En ocasiones hay que salir con una fachada que esconde irrelevante. Ap I miembros. En ocasiones necesitas aplicar un patrón de adaptador, especialmente si no eres dueño de la interfaz de grasa, y así no puedes modificar su código fuente. El apego inteligente al principio de segregación de interfaz hace que una aplicación sea más fácil mantener lo que es extremadamente valioso, sobre todo a largo plazo. Abusando hablo puedes terminar con tonos. Off to small interface es lo que los hace más difíciles de usar por clientes antiguos. Este es un olor conocido como anti hielo. Sea así llegamos al final de este apartado. Esa fue una investigación interesante. Pero hay otro principio que nos espera el principio de inversión de dependencia. El siguiente apartado está dedicado al D. I. P. Vamos directo a los negocios. 10. Esbozo de 01: Hola. Este es el último para divertirse de spot ingeniero de hornear. Y en esta sección, vamos a aprender dónde están los principios. Nos referimos a los principios de los que vamos a hablar en esta sección en cuanto a los principios de la materia porque son las raíces de todos los demás principios más concretos adheridos a los que realmente estamos tratando de conformarnos con los principios de la materia. Empezaremos desde la secadora. No te repitas principio. Aprendes la definición de los olores más comunes de violar el principio seco. Después de eso, aprendiste las llaves o lo mantuviste simple. Principio estúpido. Aquí vamos a hablar de simplicidad y complejidad, complejidad accidental y esencial y cómo lograr la simplicidad. El siguiente meta principio del que vamos a hablar es el yo joven o no lo vas a necesitar principio. Está relacionado con el olor innecesario complejidad y se refiere a las anticipaciones fuera de las características comunes . Analizaremos los problemas prácticos a los que nos enfrentamos y qué otras consecuencias la implementación de características que realmente no necesitamos. Después de eso, vamos a hablar del principio de calcetín o separación de preocupaciones. Este principio subyace al incienso. Todos los principios sólidos. La separación de preocupaciones es muy importante para lograr aplicaciones bien mantenibles. Verás las formas más comunes de violar la separación de preocupaciones. Principio Comando principio de separación de consulta hace más fácil razonar sobre. En el código se discutirá el mínimo de Demeter, que es el principal conocimiento fuera de la lista. Por separado, hablaremos del principio fuera menos asombro usted. Después tocaremos el tema de la ocultación y encapsulación de la información. Por cierto, utilizaré la palabra principio en lugar de principio de materia en esta sección. Además, sólo por el bien de ahorrar algún tiempo en la próxima conferencia, aprende sobre el principio seco. Empecemos. 11. Definición de OCP 02: esta conferencia se titula Declaración del Problema. El segundo principio del que vamos a hablar es el principio de cierre abierto. Si miramos a Wikipedia, veremos la siguiente definición. El principio de cierre abierto establece que las entidades de software, gafas, módulos, funciones etcétera deben estar abiertas para su extensión pero cerradas para su modificación. Lo que significa, en esencia, es que cuando necesitamos introducir un cambio, no debemos profundizar en el sistema y cambiar su comportamiento. Al cambiar esos extremos de clases, deberíamos poder introducir un cambio agregándote código no cambiando el software existente de este tipo, lo que permite cambios introduciendo nuevas clases en lugar de cambiar la fuente existente código está abierto para su extensión y cerrado para su modificación. Cómo cambiar el comportamiento sin cambiar la base de código. La respuesta es simple. Despacho dinámico o polen. Más tarifas podemos lograr muy flexibles, diseñadas aprovechando la programación orientada a objetos de poder off. En la práctica, significa que necesitamos depender de abstracciones más que de implementaciones concretas o directas , incluso ver tienda. Nos basaríamos en rostros y gafas abstractas. OK, pero ¿cuál es el problema con cambiar el código existente? ¿ Por qué necesitamos apegarnos al principio abierto, cercano en absoluto. El primer motivo es que hay una alta probabilidad de salir introduciendo caja durante el proceso de modificación . Es mucho más fácil entrar. Usa un bug, modificando algo que es complejo y ya existe. Planea introducir un error encabezando nuevo código. El segundo motivo es irrelevante, y casi siempre es relevante cuando se intenta modificar el comportamiento de un FBI, que ya está en uso por muchos clientes. El primer peligro aquí se utilizó para cambiar el comportamiento esperado por los clientes. Imagina que hay 1000 clientes de un método que devuelve 100 en caso de falla y que los clientes tengan alguna lógica de compensación para ese caso. Imagínese, entonces que modificó el comportamiento del método de cuál de esos 1000 clientes dependen. Las consecuencias son dramáticas. Yo rezaría por el desarrollador que decidió introducir tal cambio, que rompe el código de 1000 clientes. El segundo peligro es modificar las firmas del FBI. Dichas modificaciones rompen inmediatamente a todos los clientes dependientes. Créanme, los clientes no te agradecerán por tales modificaciones. Por cierto, romper cambios también puede causar efectos de onda porque puede existir cientos de clientes que dependen de otros clientes que dependen de tu código. Modificar el comportamiento comiendo tu código en realidad se ajusta a lo que piensan los clientes cuando piden nuevas características. Cuando los clientes piden una nueva característica, piensan que se agregarán características. No creen que los desarrolladores modifiquen nada. La idea podría parecer ridícula desde primera vista. Efectivamente. ¿ Eso es posible escribir Ir que nunca se modificará de nuevo? Fuera de curso. Esto no es posible en la práctica. Bueno, teóricamente, es posible escribir todo el código de esta manera, pero no es práctico en la programación. A menudo nos fijamos algunas metas ideales que se pueden lograr alguna vez, por ejemplo, que se esfuerzan por escribir correcta Golden. Teóricamente, podemos escribir código esa corrección apagado, que puede verificarse estáticamente. Desafortunadamente, en el 99% de los casos, tal proceso de desarrollo es tan caro que quiero está tope bull off invirtiendo tanto dinero, otro punto, lo cual es obvio. Pero necesito mencionar que es que absolutamente debemos modificar el código existente si contiene un error. Por lo que la fijación de espalda está bien desde el punto de vista del principio de cierre abierto. Demos un paso atrás y miremos en 1988 1988 es el año en que Bertrand Meyer describió OCP por primera vez, Meyer trató a OCP un poco diferente al tío Bob. OCP desde el punto de vista de Marius, era esencial, equivalente al patrón de variación protegido. El patrón de variación protectora significa que los siguientes identifican puntos fuera de variación prevista y crean una interfaz estable alrededor de ellos. Hablando aquí de una interfaz no necesitamos la tienda C en constructo facial. Terminar a Cara implica cualquier P. I. Una Clase tiene su propia interfaz, cual está representada por su público. A P I. Aquí podemos notar una sutil diferencia entre las definiciones de Marte y Martín. La definición de Myers es más sobre compatibilidad con versiones anteriores en el nivel A P R. Entonces si los cambios no rompen la compatibilidad hacia atrás, sin embargo, sippy es Matt. Cuándo exactamente podemos necesitar cambiar el comportamiento de cambiar la interfaz. Por ejemplo, cuando aparece un nuevo cliente, lo que requiere un comportamiento muy similar pero un poco diferente, el último punto que quiero abordar es el principio de elección única estrechamente relacionado con el principio de cierre abierto . Prefiero nombrar a este principio el principio de fuente única y usted entiende por qué en breve , Imaginemos el caso cuando necesitamos decidir qué implementador crear. Dependiendo de un argumento para resolver este tipo de problemas, muchas veces confiamos mejor en la fábrica. Aquí tienes un ejemplo. Como ven aquí, tenemos un método factorial que quita un parámetro de las bromas. Modelo de Nall en admiración. Dependiendo de ese parámetro, el método de factor crea una implementación correspondiente fuera de la interfaz de terminal I ban. ¿ Este método factorial viola el principio de cierre abierto? Por supuesto que sí. Si desplegamos una nueva implementación fuera de la interfaz del terminal del banco ocular, modificaremos este oro agregando en comunicado del Reino Unido, ¿Cómo podemos resolver el problema? Adhiriéndonos al principio de cierre abierto, podemos crear una fábrica de la fábrica terminal bancaria pero que creen ese factor de esta fábrica en algún lugar. Al final, necesitamos seleccionar la implementación adecuada y crear la instancia. Podemos resolver parcialmente el problema introduciendo un contenedor helado, pero esto solo moverá el problema. No resuelve el problema del todo si no estás familiarizado con la noción de inyección de dependencia y he visto contenedores como nota al margen, te recomendaría a los libros. El 1er 1 es de la Biblioteca Back Bob, que se nombra Mastering Inject for Dependence Injection y otro que es un bestseller absoluto escrito por Mark Semen Dependence Injection en dot net. Entonces el principal off single choice suena así. Siempre que el sistema de software debe soportar un set off alternativas, uno y sólo un módulo en el sistema debe conocer su lista exhaustiva. Sí, estamos violando a esos sippy al tener tal implementación del método factorial. Pero no hay sentido tratar de empujar el chismoso más allá por ningún medio. Debemos entender que en tales casos, todo lo que necesitamos es aislar tal responsabilidad en un solo módulo, y sólo ese módulo debe cambiarse en caso de introducir nuevas implementaciones. De acuerdo, veamos el problema de la violación chismosa y cómo solucionarlo en nuestro querido estudio visual . 12. Demo del problema de 03: esta conferencia se titula Hielo Ser Violación Dama uno. Quiero Mostrarte Caso Ariel de mi práctica, que estaba relacionado con el problema off in face segregation. He estado trabajando mucho con dispositivos, y una vez que enfrenté el siguiente caso antes de conceder, quiero decir que me gusta dar ejemplos a los estudiantes que reflejan todo el panorama del caso del mundo aéreo. Por lo que describiré todos los detalles relacionados con el problema porque creo que esto ayuda a entender mucho mejor el material. Por lo que en el nivel superior tenemos una aplicación monolítica WBF, que funciona en terminales de servicio puntuales. Esas terminales permiten a la gente comprar boletos en trenes suburbanos. Esa aplicación permite a los usuarios comprar boletos a través de tarjetas de crédito. De esta manera la aplicación tiene que trabajar con terminales bancarias. De alguna manera, por algunas razones de negocio, había varios modelos de terminales bancarias integrados para pasar terminales, por lo que todos ellos tuvieron que ser apoyados. No es directa la interpretación con terminales bancarias. Los productores de terminales Ban proporcionan sus propias aplicaciones a través de las cuales nuestra aplicación puede trabajar con sus terminales bancarias. Sus aplicaciones se implementan como vienen los servidores. Si no sabes qué es un servidor com solo piénsalo como un servicio ejecutable independiente . El diagrama refleja el flujo de operaciones. Echemos un vistazo al código. Ahí está el mínimo desnudo off operaciones, las cuales son apoyadas por cualquier posible terminal bancaria. Por eso definí la interfaz terminal de Eye Bank, que refleja el B I proporcionado por servicios que el Inter opera directamente con terminales bancarias . Ahora tengo tres implementaciones fuera de la interfaz terminal de banco ocular, Terminal Zap, terminal propia y terminal PDQ. me entró la implementación rial, ya que complicaría demasiado el ejemplo. Y no hay ningún significado para mostrarte las agallas y los detalles de bajo nivel. Y ahora describiré el problema que surgió. El caso es que las terminales bancarias son diferentes. El algunos terminal es una solución de caja negra la cual físicamente es una caja que por sí sola funciona con atrasos de tarjetas de crédito. Grandes lectores de tarjetas de identificación son aquellos dispositivos que aceptan tu tarjeta, leen el barato o una raya magnética y te dispensa la tarjeta de vuelta. Por lo que su propia terminal no expone tipo para Inter operando con lectores de tarjetas porque la aplicación de servicio automáticamente pone cosas viejas y accesorias Al mismo tiempo, las otras dos terminales bancarias, PDQ Terminal y Zap Terminal don no asuma la responsabilidad de Inter desfilar con lectores de tarjetas automáticamente. Por el contrario, delegan esta responsabilidad a un cliente, exponiendo un P I por inter desfilar con lectores de tarjetas. Por lo que en el primer caso, nuestra aplicación no necesita hacer nada en absoluto. En tanto que en los otros dos casos son aplicación tiene que mostrar una ventana para postular ingenieros de mantenimiento de terminales para proporcionar la capacidad de configurar correctamente los dispositivos terminales bancarios. Echemos un vistazo a la clase de modelo de vista, que es un presentador para esa ventana, que permite a los ingenieros de mantenimiento configurar los dispositivos de terminales bancarios. El ventanilla cuenta con cuatro botones, que permiten probar si el contacto o contacto con los lectores se encuentran en un determinado puerto. Y para encontrarlos escaneando a través de todos los puertos disponibles en el sistema, necesitamos pasar los lectores de tarjetas Comunicador de Tus Modelos, Constructor Independence, que es capaz de probar y buscar lectores de tarjetas en los puertos. Ahora pregúntate, ¿Qué harías para resolver el problema? Las formas directas de agregar para firmas de métodos justo en la terminal del banco de ojos? Hagámoslo y veamos lo que sucederá. De acuerdo, ya que tenemos tres implementador Z cuando se implementa el justo editar un Prime Members, - ¿eh ? Lo que vamos a hacer aquí el servicio de Terminal de Zona no proporciona en un grito por comunicarnos con los lectores de tarjetas aparentemente, necesitamos lanzar, no apoyados excepciones de los miembros implementados. ¿ No te recuerda algo este caso? ¿ Algo que hemos visto en la sección anterior? Fuera de curso. Esto es una violación fuera de la lista de principio de sustitución. Pero de lo que estamos hablando es del principal de segregación de interfaz, ¿no? Sí, lo estamos. El caso es que como les dije antes, todos los principios están relacionados entre sí. A veces tienen relaciones ocultas. En este caso particular, terminamos con su sabia violación como consecuencia, off ice sea violación si nos pegamos con la solución actual y requerimos la interfaz terminal ibon como parámetro fuera del comunicador de lectores de tarjetas de tu constructor de modelos. Un día alguien pasará el terminal de zona al constructor, y luego el usuario obtendrá una excepción después de hacer clic en el botón de prueba o búsqueda en la ventana. Entonces si queremos evitar eventos tan desafortunados, necesitamos reconocer el hecho de que la interfaz del coronel del banco de ojos es demasiado gorda. Contiene excesivos miembros AP I. OK, en la próxima conferencia, vamos a reflexionar rápidamente el problema. 13. 04 refactoring para un diseño mejor: en la conferencia anterior se concluyeron que el ojo Banco coronel interfaz es demasiado gordo, el pesebre y doble señor. La técnica de factoring, que generalmente se aplicará para adherirse al SP, es que creamos interfaces pequeñas y aisladas que representan responsabilidades concretas bien definidas. En este caso particular, necesitamos segregar la responsabilidad que concierne al Inter operando con lectores de tarjetas . Entonces lo haré yo. Ahora. Deberíamos implementar esta nueva interfaz de nuestros dos modelos fuera de Terminal Bancaria, que en realidad puede interoperar con lectores de tarjetas. PDQ Terminal ya implementan esta interfaz y terminal zip también. Genial. Ahora podemos requerir los lectores de tarjetas i Cable comunitario en cara en los modelos de vista. Constructor. Genial. Ya no hay posibilidad de que alguien pase una instancia inapropiada que no pueda funcionar con lectores de tarjetas. Y por cierto, ahora es mucho más comprensible qué miembros primos usar aquí. Dado que aquí tenemos una interfaz de un propósito, esta visión como cliente fuera de la interfaz no debe ser molestado por excesivos miembros AP I del terminal Eye Bank pensando en su papel. Ahora todo está parado en sus estantes. Al jugar el SP, logramos el bajo acoplamiento entre métodos que son diferentes por su significado, y así logramos una alta cohesión entre ellos en interfaces segregadas. En la próxima conferencia, veremos otro caso de violación feisty. 14. Patrones de OCP de 05 OCP: Esta conferencia se titula O. C. B. Patrones relacionados. Los dos patrones diseñados comúnmente para adherirse a la plantilla, método y estrategia de O. C. P. R. plantilla, C. P. R. Maldición Plett Método y estrategia son los llamados patrones de diseño conductual. El método de plantilla es un veterano del que aún no hemos discutido. El patrón de método de plantilla es útil en tales escenarios cuando hay un algoritmo, y alguna pequeña parte de ese algoritmo puede muy de nuevo antes. Define patrón de método de plantilla s definir este esqueleto menudo algoritmo en una operación aplazando algunos pasos a sub gafas. Método de plantilla. Vamos a subclases redefinir ciertos pasos, a menudo algoritmo sin cambiar la estructura de los algoritmos. Echemos un vistazo al ejemplo sencillo en código. Aquí tienes una clase basada en abstracto que define el algoritmo de transacciones de procesamiento fuera . El algoritmo consta de tres pasos. Retirar dinero, calcular bono y enviar saludos. Después de eso, tenemos que herederos que implementan ese algoritmo. Este patrón permite declarar un algoritmo en la clase base, creando un punto de extensión, ya que podemos implementar tantas implementaciones fuera de ese algoritmo como queramos. El template mejor y se puede implementar con una implementación predeterminada fuera de pasos algorítmicos en la clase padre eliminando la palabra G abstracta de la declaración de clase y haciendo métodos virtualmente en lugar de abstracto. En realidad, podemos codificar una implementación predeterminada, manteniendo la clase padre abstracta simplemente convirtiendo los métodos algorítmicos intra virtuales en lugar de abstracto. No estamos obligados a quitar el AB asegurado de la declaración de clase para tener una implementación por defecto . El patrón de método de plantilla crea un punto de extensión para implementar diversos algoritmos. Es así como puedes apegarte a los chismes. En tales casos. Echemos un vistazo al diagrama del patrón de estrategia. Este diagrama demuestra cómo podemos implementar un clasificador con un patrón de estrategia. El clasificador toma la estrategia una interfaz que define el método de ordenación. Hay tres implementaciones fuera de esa interfaz. El 1er 1 implementa la clasificación de burbujas, la segunda clasificación rápida y la última una clasificación de selección. El código de clientes usará el sort y deberá decidir qué estrategias quiere usar para realizar la clasificación. No vamos a buscar un ting ejemplos en código, ya que ya hemos visto cómo podríamos usar el patrón de estrategia para apagar implementaciones, puedo operar con efectivo o puedo pagar por una tarjeta de crédito en caras en este R. Sección P. Entonces aquí está la definición del patrón de estrategia. El patrón de estrategia permite en algoritmos el comportamiento para ser seleccionado en tiempo de ejecución. El patrón de estrategia define una familia fuera de algoritmos, encapsula cada algoritmo y hace que los algoritmos intercambiables dentro de esa familia. Por lo que a menudo tenemos dos formas de definir obstrucciones. En Si shop, podemos confiar ya sea en clases absurdas o en interfaces, cómo elegir entre ellas. Las interfaces están hechas de piedra. Se pueden cambiar fácilmente sin romper a los clientes existentes al mismo tiempo en caras. Una razón extensible por Un cliente de Cline's puede extender un enlace a cara por métodos de extensión. Y por cierto, si un cliente quiere implementar una interfaz en una clase que ya hereda de otra clase, cliente puede hacerlo fácilmente. Un cliente no podía hacer eso con una clase abstracta. En cambio, a menudo interactúan. Dado que la herencia múltiple en la tienda C se amortiza, cualquier clase puede implementar sus muchas interfaces como quiera, por lo que inventar y la interfaz es más flexible desde la perspectiva del cliente. Desafortunadamente, una interfaz es más regente. Desde la perspectiva de los desarrolladores, se puede cambiar fácilmente, y no soporta ningún tipo de reutilización. Las clases abstractas apoyan la reutilización. Soportan encapsulación, y se pueden extender fácilmente sin romper los clientes existentes. En consecuencia, una clase abstracta es flexible desde la perspectiva de los desarrolladores y al mismo tiempo, más región desde la perspectiva del cliente, ya que la herencia múltiple se amortiza. Con todo lo dicho, podemos concluir la interesante regla del pulgar utilizada gafas abstractas para construir ojos AP internos y utilizar interfaces para proporcionar puntos externos de extensión. Recuerda, esto no es un dogma. Esta es una regla del pulgar recordar, por ejemplo, que Basile proporciona yo colección. Yo menos notifico propiedad cambiada y apaga otras interfaces. Esto se hace así porque amplían la capacidad desde la perspectiva del cliente, es más importante en estos casos. En la conferencia donde hicimos su factoring, dije que una clase de Napster con varias implementaciones conduce a una situación en la que es difícil agregar nuevas operaciones, ya que tendrás que implementarlas en cada clase. Hay otro problema. ¿ Y si queremos brindar una oportunidad a nuestros clientes para definir operaciones por su cuenta ? En tal caso, puede que te interese aplicar el patrón diseñado por el visitante. Mira el diagrama. El patrón del visitante es bastante difícil de entender, sobre todo con sólo mirar un diagrama. En resumen, el patrón de visitante permite definir una operación que se puede realizar en cualquier clase fuera de una determinada jerarquía sin modificar clases fuera de esa jerarquía. Veamos un ejemplo en estudio visual. La última vez que salimos con el siguiente diseño, extraímos la interfaz de dispositivos I para abstraer la forma en que operan los dispositivos. Aquí tenemos el método fino. Después de eso, creamos para implementador ir dispensador Cube for y Bill dispensador E C D. M. Digamos que queremos agregar operaciones en el lado del cliente, y el cliente no tiene acceso a la interfaz del dispositivo ocular. Para eso, aplicaremos el patrón de visitante antes de implementar mejor eso. Vamos a crear aquí una propiedad portuaria y la misma en el gallinero dispensador de monedas. Por ahora, podemos implementar las visas o patrón. Bueno, eso es genial que yo dispositivo interfaz de visitante, que expone métodos de visita para todos los modelos de dispositivos. Ahora podemos implementar la clase base para que los dispositivos pasen sus instancias al visitante. Ahora quiero agregar un nuevo comando para eso. Al principio tuve la clase de visitante de comando close que implementa la nueva característica por no usar fuera de este visitante. También crearía un método de extensión en la clase de dispositivo como este. Ahora el abrigo de los clientes puede usar fácilmente el nuevo comando de ropa en cualquier dispositivo, - y ahora todo funciona bien. Este es un patrón muy potente, que te permite idear un diseño flexible. Si esperas la extensión de tipos de lo más probable, sería mejor seguir con una jerarquía clásica. Se nos ocurrió realizar la primera o fábrica. Por el contrario, si esperas que la jerarquía no sea volátil y las operaciones van a ser implementadas por los clientes, entonces el patrón de visitante es el camino a seguir. Agregar nuevos tipos al visitante puede ser problemático en la próxima conferencia. Resumamos lo que aprendimos sobre el OCP e intentamos describir brevemente los olores comunes de violación de OCP 15. 06 Smells comunes de la violación de la OCP: el olor más común off chismoso violación es la aparición fuera de muchas ramas condicionales , ya sea con if else o con declaraciones de caso switch. Generalmente, usted tiene tres enfoques comunes para adherirse al edificio S a p secuencias de manejo con delegados, que son naturalmente las implementaciones fuera del patrón de cadena de responsabilidad. Busca la cadena de recámara de responsabilidad. El espectro está casi integrado con eventos en la plataforma dot net, por lo que lo usamos cuando necesitamos pasar un mensaje y manejarlo por varios manejadores. El encadenamiento de responsabilidad proporciona la forma de implementar eso de una manera poco acoplada . De lo contrario, puede terminar con objetos acoplados. Otra forma es confiar en una herencia clásica con un patrón de método de plantilla, o implementar un patrón de visitante. Si necesita proporcionar la capacidad para que un cliente defina las operaciones, la última forma es confiar en una composición en lugar de en la herencia. Lo más probable es que confíes mejor en la estrategia para implementar una composición. Recuerde que la composición es generalmente más preferida que la herencia clásica. De acuerdo, en la próxima conferencia, vamos a resumir lo aprendido en esta sección 16. Conclusión de 07: Esta conferencia se titula Conclusión. El principio de cierre abierto es todo sobre cambios. Siguiendo OCP, puedes lograr cada diseño flexible que esté listo para introducir nuevas características sin dolor. Para lograr el diseño flexible, debe estar abierto para la extensión y cerrado para una modificación, lo que las partes del sistema que cambian con mayor frecuencia tienen que ser aisladas. Una cosa muy importante es que necesitamos aislar una responsabilidad de crear objetos en un solo módulo y Onley ese módulo debe cambiarse en caso de introducir nuevas implementaciones. Este principio se denomina principio de elección única. Has aprendido que puedes adherir al OCP aprovechando las clases abstractas de power off para interfaces. Los patrones diseñados más comunes que aplicamos para adherir al LCP son la plantilla, método y estrategia. Has aprendido que una interfaz es más flexible desde el punto de vista del cliente. Si bien una búsqueda abstracta es más flexible de los desarrolladores apuntan a ti. También hemos aprendido que no tenemos a nuestra disposición ninguna herramienta mágica que nos permita protegernos de todos los posibles cambios por completo, y no significa que debamos empezar a crear toneladas de extensiones, puntos anticipando cambios en el futuro en toda la base de código. Para superar el problema, estamos tratando de utilizar el llamado diseño gile. Enhorabuena. Has llegado al final de la sección OCP en el siguiente apartado. Vamos a ver la lista de principio de sustitución, aparentemente el príncipe más difícil de entender entre principios sólidos. 17. Esbozo de 01: Hola. Este es el último para divertirse de spot ingeniero de hornear. Y en esta sección, vamos a aprender dónde están los principios. Nos referimos a los principios de los que vamos a hablar en esta sección en cuanto a los principios de la materia porque son las raíces de todos los demás principios más concretos adheridos a los que realmente estamos tratando de conformarnos con los principios de la materia. Empezaremos desde la secadora. No te repitas principio. Aprendes la definición de los olores más comunes de violar el principio seco. Después de eso, aprendiste las llaves o lo mantuviste simple. Principio estúpido. Aquí vamos a hablar de simplicidad y complejidad, complejidad accidental y esencial y cómo lograr la simplicidad. El siguiente meta principio del que vamos a hablar es el yo joven o no lo vas a necesitar principio. Está relacionado con el olor innecesario complejidad y se refiere a las anticipaciones fuera de las características comunes . Analizaremos los problemas prácticos a los que nos enfrentamos y qué otras consecuencias la implementación de características que realmente no necesitamos. Después de eso, vamos a hablar del principio de calcetín o separación de preocupaciones. Este principio subyace al incienso. Todos los principios sólidos. La separación de preocupaciones es muy importante para lograr aplicaciones bien mantenibles. Verás las formas más comunes de violar la separación de preocupaciones. Principio Comando principio de separación de consulta hace más fácil razonar sobre. En el código se discutirá el mínimo de Demeter, que es el principal conocimiento fuera de la lista. Por separado, hablaremos del principio fuera menos asombro usted. Después tocaremos el tema de la ocultación y encapsulación de la información. Por cierto, utilizaré la palabra principio en lugar de principio de materia en esta sección. Además, sólo por el bien de ahorrar algún tiempo en la próxima conferencia, aprende sobre el principio seco. Empecemos. 18. Definición de LSP 02: esta conferencia se titula Declaración del Problema. La definición oficial de Barbara Liska fuera de la lista de substitución principal suena así si s es un subtipo off team que los objetos fuera de tipo T pueden ser reemplazados por objetos fuera de tipo s sin romper el programa. No es muy difícil entender lo que significa esta definición, pero citaré la definición fuera de L S P del libro de Tío Bob. Principios ágiles, Patrones y Prácticas en C agudo Por si acaso encontramos ahí la siguiente definición fuera la lista de principio de sustitución la lista de principio de sustitución establece que los subtipos deben ser sustituidos ble por su base tipos. Por cierto, Barbara Lisk off es una científica que describió este principio en 1988. El trabajo original fue escrito en Grecia y fue muy difícil de entender y aplicar programación orientada a objetos en la práctica. Tratemos de aclarar qué era lo que significaba para los desarrolladores en la práctica. ¿ Qué significa ser sustituido ble por una clase? Vamos a fingir que tenemos un cliente que usa el FBI fuera de la interfaz sea que haya dos. Se implementa por clases A y C Clase C puede considerarse Sustituto hable de Clase A si el cliente no observa ninguna diferencia usando la Clase C en lugar de A. Desde la perspectiva del cliente, un cliente no debe experimentar comportamiento diferente utilizando diferentes herederos de la misma clase base o una interfaz. En realidad, la L S P está fuertemente relacionada con sus lenguajes orientados a objetos. Permítanos usar la herencia. Si el ser de Glenn hereda de un, entonces podemos usar B S A. Pero podemos usar un SB. De esta manera, los clientes off a pueden usar tanto A como B aunque no sepan nada sobre ser. Esto es básico fuera del polimorfismo. A pesar de esto es básico desarrolladores todo el tiempo. Violo la lógica fuera de tal relación, por cierto, como comentario, quiero recordarles que no es necesario tener un mecanismo como la herencia para modelar tales relaciones entre objetos. En lenguajes mecanografiados dinámicamente, utilizamos la llamada mecanografía oscura. Si un pájaro nada como un pato, charlatra como un pato. Entonces llamé a anuncio un pato. Es por eso que el término tipificación de pato apareció dinámicamente. idiomas mecanografiados no saben si se nos permite llamar a un determinado método o no. El tiempo de ejecución comprueba. Si un objeto puede responder a un mensaje diciendo un mensaje, me refiero a una llamada al método, ya que en lenguajes de tipo dinámicamente, es mejor decir Enviar un mensaje en lugar de llamar a un método. Volvamos al tema principal. Existen dos formas de romper la capacidad sustitutiva. Violar contrato y violar variantes de co varianza o control. Para un número significativo de desarrolladores, no está claro ¿qué significa? Por lo que requiere de la aclaración adicional. Sin entender, estos conceptos fundamentales no podrán diseñar tipos que no violen su discurso . o temprano, te toparás con los horribles problemas causados por, oh violación de velocidad. Entonces mantengan a los pacientes y empecemos con contratos en la próxima conferencia. 19. 03 contratos: Esta conferencia se titula Contratos. Programación a Contratos fue elaborada por Burton Meyer en su libro clásico, Construcción de Software Orientado a Objetos. Describió las ventajas de la programación a los contratos. Incluso salió con todo el nuevo lenguaje llamado Eiffel, que se construyó con la programación a los contratos en mente. Entonces, ¿cuál es el contrato? Muchos desarrolladores hace las nociones fuera de una interfaz y el contrato. El comunicado se vuelve más convincente con el hecho de que en WC, si tratamos las interfaces y los contratos por igual en W. C. F. Un contrato de servicios sólo puede ser representado por una interfaz en el mundo real, incluido el mundo real. Fuera de la programación, los contratos tienen alguna carga útil semántica. Por lo general, determinan algún tipo de relaciones entre las personas, escribe objetos y así sucesivamente en caras no tienen ninguna carga útil semántica. No determinan nada más que las firmas, pero las firmas no llevan ninguna carga útil semántica significativa. Una interfaz representa sólo una forma. De esta manera, las interfaces no son contratos. Aquí un ejemplo de contrato proporcionado por Christophe Kulina. En este contrato se dice que cuando se agrega un artículo al cobro, contabilizan las propiedades incriminadas por uno. Además, este contrato está bloqueado para todos los subtipos. Por lo que un contrato fuera de un método constituye fuera de las siguientes partes. Valores o tipos de entrada aceptables e inaceptables y sus significados. Devolver valores o tipos y sus significados. Condición de error y excepción, valores o tipos que pueden una cura y sus significados, efectos secundarios, condiciones previas, condiciones postales. Y en la varianza desde la perspectiva del aprendizaje, nos interesan mayormente las condiciones previas, las condiciones puestos y en la varianza por las condiciones. Off una función es el conjunto de requisitos. Una función se aplica a los parámetros de entrada y a veces al estado del objeto al que pertenece esa función. Tengo un ejemplo sencillo de mi propia práctica. Atiende fuera de curso, simplificado y presentado en una forma fuera de un esqueleto por el bien de la simplicidad. Aquí tenemos dos modelos diferentes de terminales bancarias. Ambos modelos derivan de la interfaz terminal del banco ocular, que define la operación de pago del proceso. Estos terminales comparten cantidad significativa de lógica empresarial, y tienen interfaces muy similares, lo que los desarrolladores decidieron unirse a ellos introduciendo esa interfaz de terminal bancaria. Desafortunadamente, ambas terminales tienen sus propias pasarelas de pago con diferentes interfaces. Uno requiere un i d único para ser generado por el cliente, mientras que otro no para hacer que los desarrolladores universales de A P. I. I.simplemente lanzaron un solo método con dos parámetros. La implementación fuera de la primera terminal simplemente ignora el segundo parámetro, mientras que el segundo comprueba el único I D. Y si es ahora o espacio adecuado, arroja la excepción argumento. Un cliente, que trabajó con la primera terminal, no espera tal comportamiento trabajando con el 2do 1 Esto sucede porque el segundo heredero fortalece las condiciones previas. El primer terminal acepta el único I D, que puede ser igual a cualquier valor. No se aplicaron restricciones. El corolario es que un cliente tiene que estar al tanto del comportamiento diferente de estas terminales Ben . Aquellos clientes que trabajaron con la primera terminal no esperarían ninguna excepción. Trabajando con el 2do 1 pasando ahora como un i d único La jerarquía no sólo viola su WASPy fortaleciendo las precondiciones, sino que además viola van a una velocidad al debilitar las condiciones postales la primera terminal regresa El resultado código off tipo que termina lo que significa que el código de respuesta es igual o mayor que cero? En el segundo caso, el código de resultado puede ser menor que cero fuera de curso. En el segundo caso, la lógica interna de la pasarela de pago, mi garantía de que devuelve sólo códigos que son iguales o mayores que cero pero pretenden que no proporciona tales garantías. Desarrolladores querían implementar la interfaz universal, por lo que definieron el pago del proceso. Se trata de un método que devuelve un entero. Aquí vemos que el primer terminal devuelve un extremo tú, pero tiene que echarlo punta del pie para satisfacer la interfaz Muy a menudo. En tales casos, los clientes están al tanto de las garantías que brinda uno de los implementadores. Por ejemplo, en este caso, el método dice explícitamente en comandos que la respuesta de retorno siempre es positiva. El segundo terminal debilita las condiciones de los puestos en comparación con la primera terminal. Es por eso que los desarrolladores tuvieron que definir el método de pago de proceso con el tipo de retorno de ensayo entero . Intentan hacer que una interfaz universal falle porque los clientes tienen que conocer los detalles internos . Al final, saben que el primer modelo realmente garantiza que regresa. Códigos positivos, a pesar de la firma no lo refleja. El concepto general es que al debilitar las condiciones de los puestos, los herederos amplían el posible resultado de una función. consecuencia, Enconsecuencia, los clientes enfrentan situaciones inesperadas o al final tienen que entender diferentes casos y tratarlos de una manera específica puedes escribir contratos en la plataforma dot net en tienda C con una biblioteca especial llamada código contratos. No es de extrañar uso de contratos de código, se pueda aprovechar el apagado de la verificación de código declarado sobre la corrección debido a algunos problemas prácticos y problemas relacionados con la mala implementación fuera de la biblioteca de contratos de código. No es un enfoque muy popular. actualidad, por ejemplo, los llamados contratos funcionan muy lentos en grandes soluciones. Y esta es sólo una de las razones por las que esta biblioteca está fuera del alcance de las partituras. Entonces si te interesan los contratos de código, solo puedes Google por ello. Otro problema que quiero demostrar está relacionado con la violación off en varianza en un ejemplo clásico en la próxima conferencia. 20. Demo del problema: esta conferencia se titula Ellis Be Violation Demo. Consideremos un ejemplo clásico de Phyllis P. Violación. Me encanta este ejemplo por dos razones. El 1er 1 es que en realidad demuestra la violación L S P, y esta razón es obvia. Y la segunda razón es que muestra que la programación orientada a objetos a menudo puede mapear directamente las relaciones entre los objetos en el mundo real en el mismo modelo fuera las relaciones entre ellos en código. Un gran número de desarrolladores piensan que al escribir código en lenguaje Hopi, están modelando problemas de dominio del mundo aéreo. Y en parte esto es cierto. Pero las relaciones del mundo real entre objetos a veces pueden ser motiles directamente en lenguaje opie . Aquí te dejamos una de las declaraciones esperanzadoras ingenuas gafas infantiles. Implementar es una relación con clases basadas. Por ejemplo, perro es un gato animal es un animal, por lo que podemos crear tres clases. Animal es la clase base, y los otros dos son herederos. Desafortunadamente, a veces este tipo de diseño no funciona como se esperaba, y lo verás en un minuto. Entonces, reflexionemos en código las relaciones entre dos nociones del mundo riel. Queremos implementar un rectángulo y cuadrado pudiendo calcular sus áreas. Seguro que estarás de acuerdo conmigo en que en la Plaza del Mundo real es un caso especial fuera de rectángulo . Es otros porque el cuadrado es un rectángulo con lados iguales. De acuerdo, pasemos a estudio visual. Vamos a crear un rectángulo y un cuadrado. Creé la clase de rectángulo, que tiene dos propiedades con y altura, y el cuadrado, que hereda de su clase de enredo. Por separado, crearé la clase, que se encarga de calcular las áreas de esas formas. Se ve bien. Desde el primer lado. Voy a fingir que soy cliente y quiero crear dos formas y calcular sus áreas. Para eso, implementaré el método principal donde sucederán todas las cosas que primero, solo crearé un rectángulo con igual a dos y ocultar igual a cinco. Después de eso, llamaré al método de ángulo correcto ST IC Cal y obtendré el resultado, y también envío el resultado a la consola. Ahora quiero crear un cuadrado. Espera un minuto. ¿ Qué demonios es esto? Cómo un cuadrado puede contener lados de diferente longitud. Ni siquiera voy a ejecutar el programa, ya que es obvio que algo anda mal aquí con una pila de cuadrado cuadrado permite establecer diferente longitud a anchura y altura. Este diseño viola claramente la lista de sustitución. Cuadrado principal no es sustituto hable para rectángulo implementa el en variante , que establece que el ancho y la altura podrían estar desactivados. Diferente Plaza de Tierra tiene que implementar otra en variante que establece que el ancho y altura tienen que ser iguales. Eso lo omito intencionalmente. En realidad también tienen que ser mayores o iguales a cero. Ahí hay otro problema es esconderse aquí. Lo más probable es que necesites crear métodos que tomen el rectángulo como parámetro e implementen alguna lógica empresarial. En caso de calcular la era, tal método podría verse así. Este método comprueba el tipo del parámetro aceptado y ejecuta el algoritmo de cálculo apropiado . ¿ Qué opinas? ¿ Es una buena manera de definir métodos en toda la base de código que tienen que trabajar con rectángulos? ¿ No te parece algo que hemos visto anteriormente? Sí, efecto, esto es una violación al principio abierto de cierre. Este método está abierto para su modificación. ¿ Qué pasará si introducimos una nueva forma? Correcto. Tendremos que modificar. Es por eso que afirmación este ejemplo de violación de Gillespie es una violación oculta fuera de OCP. En la próxima conferencia, veremos cómo solucionar este problema 21. 05 refactoring de un diseño mejor: Obviamente necesitamos hacer imposible el ajuste de diferente longitud fuera para que un cuadrado solucione el problema. Por ahora, las expectativas de los clientes de plazas están rotas. El aire, una clase de calculadora ahora demuestran que hay un problema fuera de los datos y el comportamiento separados . Los algoritmos de cálculo están separados de los vidrios rectángulo y cuadrados, que poseen los datos requeridos para los cálculos. El calculador de área no puede existir sin rectángulo y cuadrado. Entonces por qué el comportamiento se alejó del rectángulo y rectángulo cuadrado y cuadrado por ahora, obviamente carecen de cohesión para curar la enfermedad, donde siempre debe construir abstracciones adecuadas. Lo que queremos obstruir es la lógica empresarial de calcular el área. Cada forma tiene su propio algoritmo fuera de cálculo. El área. Es mucho mejor hacer que el comportamiento sea compartido en lugar de datos. Obstruyamos el método de cálculo del área introduciendo la interfaz en forma de I. Quiero que el rectángulo y el cuadrado hereden de la forma del ojo. Implementando sus propios algoritmos, Square ahora define su propia propiedad llamada longitud lateral. Ahora un cliente no puede hacer mal uso. Es un P I. Aquí hay un ejemplo de un cliente en caso de llamada de rectángulo para calcular área, Un cliente dará el área de un rectángulo, mientras que en caso de cuadrado, un cliente obtendrá el área de un cuadrado. El cliente puede establecer diferente longitud, ancho fuera y altura a un cuadrado. Genial. En la próxima conferencia, veremos otras formas de salir de ls ser violación. 22. 06 ejemplos de violaciones de LSP: esta conferencia se titula Más Ejemplos Off L S P violación. Nos meten la discusión de un tema muy importante. Varianza La varianza es un concepto muy complicado. Por lo que vamos a dedo solo tocar este tema. A pesar de que está relacionado con la varianza L S P es la noción que describe el cumplimiento de los tipos . Se ramifica a dos nociones, coherencia y contrarvarianza. Suponiendo que el tipo A enlató el elenco al tipo B Tipo X es variante co en caso X off a enlatado el elenco dos x off b, por ejemplo. Tomo prestado stream can porque a mi bar off object este fragmento de oro muestra que s se llama Aaron también. Ah, aquí hay un ejemplo sencillo que demostró el problema off casting como humano tendría la siguiente jerarquía de clases el animal de cristal base y los herederos perro y gato y una nave implementación genérica fuera de pila. El siguiente código no compilará en C tienda c sharp d proc ochos esto para evitar la posibilidad de escribir el siguiente código estamos tratando aquí de agregar gatos a perros A raise in C shop are co variant por razones históricas. Por lo que se compilará el siguiente código y se detectará la violación fuera de la L S P Onley en el tiempo de ejecución. Habrá una excepción. Partiendo de C tienda para interfaces genéricas. Permitir variantes a través de palabras clave especiales de entrada y salida clases genéricas. Al mismo tiempo, no permitas variantes. La palabra clave out garantiza que dentro de la implementación fuera de esa interfaz, un parámetro genérico sólo se puede utilizar en las sentencias return. Resuelve el problema que hemos visto con agregar un gato a una pila de perros. Esto se puede expresar como en el siguiente fragmento. Incluso la clase de pila del ejemplo anterior implementa esta interfaz de lo que el siguiente código compilará y será absolutamente correcto. Por el contrario, podemos usar la palabra clave in para asegurar que el parámetro genérico sólo se utilice como entrada. Aquí está el fragmento de código, que demostró la idea si el cristal de pila implementa esta interfaz de lo que el siguiente código compilará y será absolutamente correcto. Otro ejemplo que quiero mostrarte viene de la Basile off the dot net framework. También es bien conocido ejemplo de la violación de SP. Existe una interfaz genérica llamada colección I, a menudo definida en el BCL. El stop deriva de lo innumerable del té, y define los siguientes métodos. Agregar claro. Contiene copia, también. Quitar. Ahí hay vieja clase aérea cirujano llamada solo lectura Colección fuera del equipo, que deriva de la colección I de equipo. Sí, puedes adivinar por el nombre fuera de la colección de solo lectura fuera de T. Implementa una colección que no se puede cambiar después de la inicialización al mismo tiempo, solo lectura colección Off T deriva de la colección I de té. Qué significa que debe soportar todas las operaciones definidas en ese padre, una interfaz genérica. Una segunda secuencia, la colección de solo lectura tiene que implementar, agregar métodos claros y eliminar de alguna manera pero cómo se supone que los implementen, tomando en cuenta que estas operaciones se encuentran dip localizadas para realizar en una lectura de solo colección fuera de curso, no hay forma significativa de resolver este problema. Por lo que ahí sólo la colección sólo lanza. No están apoyados. Excepción de esos métodos de modificación. Claramente viola el principio de lista de sustitución, ya que los clientes que trabajan con mi colección de té no esperan tal comportamiento. Y esto es lógico porque otras implementaciones fuera de yo colección de té, como una lista de té no tirar no se apoya excepción. Simplemente trabajan se espera de una clase que expone los métodos de modificación. Lanzar, excepción no compatible es un fuerte olor off l S P violación. Otro olor que indica la violación L S P se demuestra al aparecer fuera demasiados lanzamientos abajo en la base de código. Si un cliente está comprobando constantemente los tipos reales de clases o interfaces basadas, automáticamente significa que un cliente está preocupado por diferentes implementadores. Zobaie. Alguna razón significa que un clan conoce algunos detalles internos sobre la construcción de la jerarquía de objetos . El olor es una consecuencia de la violación SP Un ejemplo de tal olor que has visto en la conferencia donde discutimos las relaciones entre cuadrado y rectángulo. El fragmento de código en la diapositiva también demuestra este problema. Los costos a la baja no siempre son la indicación fuera de las violaciones de SP. Se permite bajar un tipo. Si estás absolutamente seguro del tipo, necesitas bajar para considerar el siguiente ejemplo. Por ejemplo, si estamos absolutamente seguros de que esta función se llama sólo con un I d off a un cliente privilegiado , entonces podemos bajar libremente el objeto devuelto del repositorio y realizar una operación este tipo de downcast, por así decirlo, recuerda al compilador que el tipo rial es cliente privilegiado. En la próxima conferencia, marcaremos algunos olores comunes que indican que los analistas sean violación. 23. Smells comunes de la violación de LSP: esta conferencia se titula Common Sells Off LS Ser Violación. Resumamos qué olores comunes podemos enfrentar con los que indican que Bayliss sea violación. En primer lugar, si un método arroja entonces la excepción no apoyada de su cuerpo y otra noción, que describe este caso es la noción off llamada herencia rechazada. El significado es que la búsqueda infantil hereda algo, pero no sabe qué hacer con el heredado y lo rechaza lanzando excepciones que no soportadas. Otra forma del mismo legado rechazado es cuando un método tiene una inter implementación. Este es el mismo caso. La única diferencia es que un método rechaza legar no tan vehementemente, y otras preocupaciones de olor hacia abajo arroja hacia abajo moldes significan que un cliente tiene que conocer detalles internos de la obstrucción. Depende de. Estos son algunos consejos para conformarse con l S B. Intenta tener en tu mente el principio tell don't ask, lo que significa, en esencia, que el código de clientes debería poder simplemente pasar mensajes sin pensar en ningún detalles internos fuera del colaborador. Idealmente, no se debe molestar a los clientes comprobando ninguna condición. Recuerde que l S P violación es a menudo secuencia econ off OCP o SP violación. Hablaremos del principio de segregación de interfaz en el siguiente apartado, así que solo toma en cuenta por ahora ese hecho En tales casos, arreglar la causa raíz conduce a una corrección automática de la violación L S P. Si tienes dos clases que comparten alguna lógica y no son sustitutos Hable, entonces piensa en crear una nueva clase base para esas dos gafas. Después heredar esas dos clases de una clase base y asegurarse de que su sustituto hable la nueva clase base. En la próxima conferencia, sacaremos una conclusión. 24. Conclusión de 08: esta conferencia se titula Conclusión. El principal que discutimos a lo largo de esta sección fue el príncipe de segregación de interfaz o hablo en camisa, hay P tiene una definición sencilla. No se debe obligar a los clientes a depender de métodos que no utilicen. Por lo que esta definición implica que hay que esforzarse por las interfaces grandes, pequeñas, cohesivas y enfocadas. Por supuesto, diferentes clientes pueden usar sólo un subconjunto de los miembros del FBI de los que dependen. A menos que ese AP, empiezo a crecer transformándose en una interfaz muy gorda con miembros no relacionados entre sí , donde, cuando aparecen métodos similares pero diferentes para satisfacer los requerimientos de diferentes clientes . Una forma típica de violación que viste, era cuando una interfaz era demasiado amplia. Lo que llevó a algunos olores como implementador tiro no implementado excepción o los clientes tienen que ver toda la masa en la inteligencia pensando en lo que realmente necesitan usar como discutimos , hay varias formas de lidiar con hablo violaciones. En ocasiones basta con extraer una interfaz separada de una gorda y utilizarla cuando corresponda. En ocasiones hay que salir con una fachada que esconde irrelevante. Ap I miembros. En ocasiones necesitas aplicar un patrón de adaptador, especialmente si no eres dueño de la interfaz de grasa, y así no puedes modificar su código fuente. El apego inteligente al principio de segregación de interfaz hace que una aplicación sea más fácil mantener lo que es extremadamente valioso, sobre todo a largo plazo. Abusando hablo puedes terminar con tonos. Off to small interface es lo que los hace más difíciles de usar por clientes antiguos. Este es un olor conocido como anti hielo. Sea así llegamos al final de este apartado. Esa fue una investigación interesante. Pero hay otro principio que nos espera el principio de inversión de dependencia. El siguiente apartado está dedicado al D. I. P. Vamos directo a los negocios. 25. Esbozo de 01: Hola. Este es el último para divertirse de spot ingeniero de hornear. Y en esta sección, vamos a aprender dónde están los principios. Nos referimos a los principios de los que vamos a hablar en esta sección en cuanto a los principios de la materia porque son las raíces de todos los demás principios más concretos adheridos a los que realmente estamos tratando de conformarnos con los principios de la materia. Empezaremos desde la secadora. No te repitas principio. Aprendes la definición de los olores más comunes de violar el principio seco. Después de eso, aprendiste las llaves o lo mantuviste simple. Principio estúpido. Aquí vamos a hablar de simplicidad y complejidad, complejidad accidental y esencial y cómo lograr la simplicidad. El siguiente meta principio del que vamos a hablar es el yo joven o no lo vas a necesitar principio. Está relacionado con el olor innecesario complejidad y se refiere a las anticipaciones fuera de las características comunes . Analizaremos los problemas prácticos a los que nos enfrentamos y qué otras consecuencias la implementación de características que realmente no necesitamos. Después de eso, vamos a hablar del principio de calcetín o separación de preocupaciones. Este principio subyace al incienso. Todos los principios sólidos. La separación de preocupaciones es muy importante para lograr aplicaciones bien mantenibles. Verás las formas más comunes de violar la separación de preocupaciones. Principio Comando principio de separación de consulta hace más fácil razonar sobre. En el código se discutirá el mínimo de Demeter, que es el principal conocimiento fuera de la lista. Por separado, hablaremos del principio fuera menos asombro usted. Después tocaremos el tema de la ocultación y encapsulación de la información. Por cierto, utilizaré la palabra principio en lugar de principio de materia en esta sección. Además, sólo por el bien de ahorrar algún tiempo en la próxima conferencia, aprende sobre el principio seco. Empecemos. 26. Definición de ISP 02: esta conferencia se titula Declaración del Problema. Antes de dar una definición, quiero decir un par de guerras sobre lo que queremos decir aquí. Por la interfaz de palabras. Fuera de curso. Into Face es una palabra clave reservada en tienda C, que permite declarar un non. Dicha construcción define a un FBI como forma, cual tiene que ser implementada por herederos de esa interfaz. Al mismo tiempo, no es necesario implementar una interfaz para exponer una interfaz. A lo que quiero decir es que las gafas que no implementan ninguna interfaz tienen su propia interfaz se compone de miembros públicamente visibles. El conjunto de miembros públicos de un vidrio representa la interfaz de esa clase. Por lo que en pocas palabras, y la interfaz es lo que los clientes ven y usan una gran definición simple apagado. El principio de segregación de interfaz se dio en el libro. Ya te has enterado en la cárcel principios, patrones y prácticas en tienda C. Entonces la definición es la interfaz. El principio de segregación establece que no se debe obligar a los clientes a depender de métodos que no utilicen. Una simple conclusión que podemos sacar de esta definición es que debes preferir interfaces pequeñas cohesivas a interfaces gordas por si acaso. Te recordaré que cohesivo significa que sólo los miembros de P I están lógicamente relacionados entre sí . Siempre es útil mirar una imagen, que ilustra el problema. Y, por supuesto, esta también es una oportunidad para divertirse un poco. Mira esta ilustración. Este monstruo hallazgo quiere comer. Y por eso dice que si requiero comida, entonces significa que quiero comer algo de comida, no candelabro ligero ni cubiertos de diseño. Esto obviamente implica que si tienes una interfaz pública llamada, requiero comida, sería tonto tener métodos como almorzar aviones o matar personaje expuesto por la interfaz. Aquí te dejamos una interesante nota histórica sobre el que hablo. Estoy bastante seguro de que I Speed se usó por primera vez hace mucho antes de Robert Martin, pero la primera formulación pública pertenece Toa Robert C. Martin, a k Tío Bob. Se aplicó ahí, habla primera vez, bien consultando para Xerox. Xerox había creado un nuevo sistema de impresoras que podía realizar una variedad de tareas como grapado y el fax. El software para ese sistema fue creado desde cero. A medida que el software crecía, hacer modificaciones se hacía cada vez más difícil para que incluso el cambio más pequeño tomara un ciclo de redespliegue, a menudo nuestro, lo que hacía casi imposible el desarrollo. El ciclo de redespliegue tardó tanto tiempo porque en ese momento no había trabajo de shopper ver . Estos lenguajes compilaron muy rápido lo que no podemos decir de C plus, por ejemplo, un mal diseño de un programa C plus plus puede llevar a un tiempo significativo de elación de compilación. Las consecuencias son dramáticas. Volvamos a la historia. El problema de diseño era que casi todas las tareas utilizaban una sola clase de empleo. Siempre que se necesitara realizar un trabajo de traer o un trabajo de grapado, se hizo una llamada a la clase de empleo. Esto dio como resultado el cristal de hecho, con multitudes off método específico a una variedad de clientes diferentes. Debido a estos diseños, un trabajo básico sabría de todos los métodos fuera del trabajo de impresión, pesar de que no les sirvió para resolver el problema. Al tío Bob se le ocurrió una idea que se llama a la cara principio de segregación. hoy, tío Bo creó y necesita enfrentar capa entre el cristal de trabajo y sus clientes, utilizando el principio de inversión de dependencia del que vamos a hablar en la siguiente sección en lugar de tener un vaso de trabajo grande, se creó una interfaz de trabajo básico o una interfaz de trabajo de impresión que sería utilizada por las clases de grapas o de impresión, respectivamente. Quitando métodos fuera del cristal de trabajo. Por ello se creó uno en cara para cada tipo de empleo, cuales fueron implementados todos por la clase laboral así en la segregación facial. violaciones principales dan como resultado clases que dependen de cosas que no necesitan, incrementando el acoplamiento y reduciendo la flexibilidad y manteniendo la capacidad. En la siguiente conferencia, miramos más de cerca el problema off hielo Violación P. 27. Demo del problema de 03: esta conferencia se titula Hielo Ser Violación Dama uno. Quiero Mostrarte Caso Ariel de mi práctica, que estaba relacionado con el problema off in face segregation. He estado trabajando mucho con dispositivos, y una vez que enfrenté el siguiente caso antes de conceder, quiero decir que me gusta dar ejemplos a los estudiantes que reflejan todo el panorama del caso del mundo aéreo. Por lo que describiré todos los detalles relacionados con el problema porque creo que esto ayuda a entender mucho mejor el material. Por lo que en el nivel superior tenemos una aplicación monolítica WBF, que funciona en terminales de servicio puntuales. Esas terminales permiten a la gente comprar boletos en trenes suburbanos. Esa aplicación permite a los usuarios comprar boletos a través de tarjetas de crédito. De esta manera la aplicación tiene que trabajar con terminales bancarias. De alguna manera, por algunas razones de negocio, había varios modelos de terminales bancarias integrados para pasar terminales, por lo que todos ellos tuvieron que ser apoyados. No es directa la interpretación con terminales bancarias. Los productores de terminales Ban proporcionan sus propias aplicaciones a través de las cuales nuestra aplicación puede trabajar con sus terminales bancarias. Sus aplicaciones se implementan como vienen los servidores. Si no sabes qué es un servidor com solo piénsalo como un servicio ejecutable independiente . El diagrama refleja el flujo de operaciones. Echemos un vistazo al código. Ahí está el mínimo desnudo off operaciones, las cuales son apoyadas por cualquier posible terminal bancaria. Por eso definí la interfaz terminal de Eye Bank, que refleja el B I proporcionado por servicios que el Inter opera directamente con terminales bancarias . Ahora tengo tres implementaciones fuera de la interfaz terminal de banco ocular, Terminal Zap, terminal propia y terminal PDQ. me entró la implementación rial, ya que complicaría demasiado el ejemplo. Y no hay ningún significado para mostrarte las agallas y los detalles de bajo nivel. Y ahora describiré el problema que surgió. El caso es que las terminales bancarias son diferentes. El algunos terminal es una solución de caja negra la cual físicamente es una caja que por sí sola funciona con atrasos de tarjetas de crédito. Grandes lectores de tarjetas de identificación son aquellos dispositivos que aceptan tu tarjeta, leen el barato o una raya magnética y te dispensa la tarjeta de vuelta. Por lo que su propia terminal no expone tipo para Inter operando con lectores de tarjetas porque la aplicación de servicio automáticamente pone cosas viejas y accesorias Al mismo tiempo, las otras dos terminales bancarias, PDQ Terminal y Zap Terminal don no asuma la responsabilidad de Inter desfilar con lectores de tarjetas automáticamente. Por el contrario, delegan esta responsabilidad a un cliente, exponiendo un P I por inter desfilar con lectores de tarjetas. Por lo que en el primer caso, nuestra aplicación no necesita hacer nada en absoluto. En tanto que en los otros dos casos son aplicación tiene que mostrar una ventana para postular ingenieros de mantenimiento de terminales para proporcionar la capacidad de configurar correctamente los dispositivos terminales bancarios. Echemos un vistazo a la clase de modelo de vista, que es un presentador para esa ventana, que permite a los ingenieros de mantenimiento configurar los dispositivos de terminales bancarios. El ventanilla cuenta con cuatro botones, que permiten probar si el contacto o contacto con los lectores se encuentran en un determinado puerto. Y para encontrarlos escaneando a través de todos los puertos disponibles en el sistema, necesitamos pasar los lectores de tarjetas Comunicador de Tus Modelos, Constructor Independence, que es capaz de probar y buscar lectores de tarjetas en los puertos. Ahora pregúntate, ¿Qué harías para resolver el problema? Las formas directas de agregar para firmas de métodos justo en la terminal del banco de ojos? Hagámoslo y veamos lo que sucederá. De acuerdo, ya que tenemos tres implementador Z cuando se implementa el justo editar un Prime Members, - ¿eh ? Lo que vamos a hacer aquí el servicio de Terminal de Zona no proporciona en un grito por comunicarnos con los lectores de tarjetas aparentemente, necesitamos lanzar, no apoyados excepciones de los miembros implementados. ¿ No te recuerda algo este caso? ¿ Algo que hemos visto en la sección anterior? Fuera de curso. Esto es una violación fuera de la lista de principio de sustitución. Pero de lo que estamos hablando es del principal de segregación de interfaz, ¿no? Sí, lo estamos. El caso es que como les dije antes, todos los principios están relacionados entre sí. A veces tienen relaciones ocultas. En este caso particular, terminamos con su sabia violación como consecuencia, off ice sea violación si nos pegamos con la solución actual y requerimos la interfaz terminal ibon como parámetro fuera del comunicador de lectores de tarjetas de tu constructor de modelos. Un día alguien pasará el terminal de zona al constructor, y luego el usuario obtendrá una excepción después de hacer clic en el botón de prueba o búsqueda en la ventana. Entonces si queremos evitar eventos tan desafortunados, necesitamos reconocer el hecho de que la interfaz del coronel del banco de ojos es demasiado gorda. Contiene excesivos miembros AP I. OK, en la próxima conferencia, vamos a reflexionar rápidamente el problema. 28. 04 refactoring para un diseño mejor: en la conferencia anterior se concluyeron que el ojo Banco coronel interfaz es demasiado gordo, el pesebre y doble señor. La técnica de factoring, que generalmente se aplicará para adherirse al SP, es que creamos interfaces pequeñas y aisladas que representan responsabilidades concretas bien definidas. En este caso particular, necesitamos segregar la responsabilidad que concierne al Inter operando con lectores de tarjetas . Entonces lo haré yo. Ahora. Deberíamos implementar esta nueva interfaz de nuestros dos modelos fuera de Terminal Bancaria, que en realidad puede interoperar con lectores de tarjetas. PDQ Terminal ya implementan esta interfaz y terminal zip también. Genial. Ahora podemos requerir los lectores de tarjetas i Cable comunitario en cara en los modelos de vista. Constructor. Genial. Ya no hay posibilidad de que alguien pase una instancia inapropiada que no pueda funcionar con lectores de tarjetas. Y por cierto, ahora es mucho más comprensible qué miembros primos usar aquí. Dado que aquí tenemos una interfaz de un propósito, esta visión como cliente fuera de la interfaz no debe ser molestado por excesivos miembros AP I del terminal Eye Bank pensando en su papel. Ahora todo está parado en sus estantes. Al jugar el SP, logramos el bajo acoplamiento entre métodos que son diferentes por su significado, y así logramos una alta cohesión entre ellos en interfaces segregadas. En la próxima conferencia, veremos otro caso de violación feisty. 29. Demo del problema: En el caso anterior, el implementador a menudo se interconecta demasiado de usted. Usó algo que no debería saber. Por eso no pudo implementar a algunos miembros de manera adecuada. Por lo que la existencia de un problema ha sido evidente Lloreda a nivel apagado en cara implementador. Muy a menudo el problema va más profundo. Cuando el problema se muestra en Lee a nivel de cliente implementador, considere el siguiente ejemplo. Tengo una clase de configuración aquí la cual se implementa s ordenar un singleton. Es constructor está cerrado y solo se puede crear por el método inicializado. Se utiliza para serializar es un archivo de configuración XML. No es de extrañar, tendría una clase que utiliza esta app config. Aquí tenemos el vidrio de reporte que implementa alguna lógica empresarial fuera de generación de informes. Actualmente depende directamente del cristal de conflicto. Debido a eso, no podemos escribir fácilmente una prueba unitaria para la clase de reporte. Lo que solo puede hacer es escribir una prueba de integración que se ocupa del archivo de configuración XML, configurándolo correctamente. Lo que podemos hacer es obstruir la clase de configuración pero introduciendo una interfaz, extrayamos una interfaz y extraeré a todos los miembros públicos. Ahora podemos solicitar que esta interfaz se pase en el constructor fuera del informe Grado de clase . Ahora podemos escribir una prueba sindical. ¿ Qué tiene de malo esta prueba? Siento todas las propiedades, incluso aquellas que no son requeridas por la lógica interna del informe. Vidrio. Podrías preguntarme por qué. De hecho dije todas las propiedades que podía establecer sólo las que se requieren en parte su derecho. Esto resolvería el problema de exceso de oro. Pero imagina que hay toneladas de propiedades como en el archivo de configuración de World real. Algunos de ellos incluso tienen nombres similares escribiendo una unidad mejor. ¿ Estarías tan seguro de que estableces todas las propiedades requeridas por la misión bajo prueba? No, no lo harías. Constantemente verás toda esa masa en la inteligencia preguntándote si esa clase requiere que se diga eso u otra propiedad. El único modo de deshacerse de la masa y hacer el código claro y más limpio es aplicar el principio de segregación de interfaz para resolver el problema. Aplicaremos el hablo en la próxima conferencia 30. 06 refactoring para un diseño mejor: para curar la enfermedad. Deberíamos. Cigarrillo dio la interfaz de configuración. El informe. vidrio debe conocer sólo la parte de la configuración relacionada con la generación de informes. Vamos a extraer esa parte en interfaz separada y solicitamos esta interfaz al pasado en los informes Glass Constructor. Ahora la clase de reporte está al tanto sólo aquellas cosas que son relevantes para los reportes. Lógica empresarial. Implementemos ahora la prueba unitaria. Genial. Ahora no necesitamos pensar en Forell y cosas que esta prueba es simple, limpia y comprensible. En la próxima conferencia, aprenderemos el olor común Baste P violaciones. Qué arreglas podemos aplicar y cuáles son los patrones de diseño relacionados con el hablo ¿Tenemos a nuestra disposición? 31. Olores de 07 comunes, Fixes, y patrones relacionados: esta conferencia se titula Common Sells Fixes Finalizar patrones relacionados. Entonces hablemos de olores comunes, que indican que tu frío violó el principio de segregación de interfaz. En el primer ejemplo, has visto un olor que era similar a la violación off. El listado de principio de sustitución al que podemos referirnos este olor es degenerar la implementación en métodos faciales. Si un método que o bien monta un método de un cristal base o implementa un método heredado de una interfaz arroja una excepción, más probable es que no se implemente una excepción o simplemente no haga nada. A lo que se le llama implementación degenerativa que indica que me velocidad se puede violar. Esto es lógico, ya que hay una muy alta probabilidad de que un cliente fuera de tal vidrio no quiera saber esa matemática lo y no quiera usarlo al mismo tiempo. Esto es un indicio de violación de velocidad de tipo. Visto tal búsqueda no puede actuar como una sustitución del cristal base o una interfaz. En ocasiones en tales casos, hubo violación es la causa raíz fuera del problema. Pero a menudo su causa es la violación del hielo. Sea así debes estudiar tu caso particular y averiguar qué causa el problema. Otro olor, que has visto en la segunda demo, puede describirse como el caso cuando el llamado de un cliente hace referencia a una clase pero solo usa una pequeña porción fuera. Es un P I. Obviamente indica que hay un haitiano local entre esas gafas. Esto debería sugerirte que algo anda mal aquí, y necesitas detener la investigación del problema. A menudo encontrarás que el problema se esconde detrás de las dos gordas en las caras. Para solucionar el problema, hay que segregar adecuadamente dicha interfaz. Otro sub caso aquí es que cuando ves una interfaz gorda pero no la tienes, puedes cambiar la interfaz porque no puedes modificar su código fuente. En ese caso, podría ser útil aplicar si Assad mejor. Ya has visto la aplicación fuera de este patrón en la sección SRP. En el caso de violación feisty, utilizamos fachada para estrechar el ancho de los vasos gordos, p I. Si tienes una interfaz gorda y es una P, no es compatible con una interfaz del lado del cliente. Cuando intentas usarlo, entonces es posible que encuentres que también existe la posibilidad de aplicar mejor el adaptador. En primer lugar, veamos el patrón del adaptador. Generalmente, ¿qué es un patrón de Deborah? De acuerdo con el libro Banda de Cuatro Patrón Adjunto se pretende convertir la interfaz un cristal en nada para enfrentar a los clientes. Esperar adaptador permite que las gafas funcionen juntas que no podrían de otra manera. Debido a interfaces incompatibles, esta diapositiva demuestra que se puede aplicar un caso de un adaptador. Imagina que al principio tener al cliente, que depende de la interfaz de combate. Del otro lado, tenemos a la Clase Mago, que expone a tres miembros incompatibles con la interfaz de combate. Si queremos utilizar el Asistente a través de la interfaz de combate, necesitamos introducir un adaptador de asistente, que implementa la interfaz de combate y utiliza internamente el Asistente. Se lo adapta en nuestro caso, cuando hablamos de ellos para enfrentar el principio de segregación. No tenemos un problema clásico cuando el adaptador se suele aplicar porque no tratamos con incompatibles en caras. En nuestro caso, las interfaces no son incompatibles. Uno es demasiado gordo para otro. No obstante, la recámara adaptadora también se puede aplicar en nuestro caso también. Echemos un vistazo al código y estudio visual, que demuestra este caso fuera aplicando el patrón adaptador con el fin de adherirse al yo hablo. No salí con un caso real, así que solo te mostraré un ejemplo completamente sintético. Aquí está el caso. Al principio se ve que tenemos la interfaz Eye Wide, que define cuatro métodos A, B, C y D. Los clientes Cold quiere ver solo los métodos A y B. Para aplicar el patrón adjunto, nosotros puede definir una interfaz I estrecha separada, que define en los métodos A y B. El adaptador en sí va a implementar que yo estrecha interfaz mientras acepta la interfaz de ancho del ojo . Instancia en el constructor como la implementación fuera del adaptador de métodos A y B solo delega la responsabilidad a la interfaz de todo el ojo. Instancia, el oro de los clientes ahora puede confiar en la interfaz estrecha A. Tomando la instancia en el constructor. Podemos pasar en la instancia del adaptador, y el cliente obtendrá el acceso solo dos métodos A y B. Así es como se puede aplicar el patrón del adaptador para adherirse al hielo estar Hay otro caso complicado relacionado con el patrón del adaptador. Digamos que tenemos un monedero de clase Pascua, que es utilizado directamente por muchos clientes. Y ahora digamos que los nuevos clientes requieren de un nuevo método en el monedero Semana Santa, y sólo dependerán de ese método. Entonces podemos hacer lo siguiente Ahora. Los clientes antiguos pueden usar el por hermana como usaban antes, y no verán el nuevo método. Si bien los nuevos clientes verán solo que tú método esta implementación fuera de la interfaz se llama Implementación Explícita. Se puede llamar a dicho método sólo a través de la interfaz, por lo que se compilará el siguiente código de clientes. Volvamos a las diapositivas. El modo general de arreglar un problema con una interfaz gorda es crear, y hay interfaz con sólo métodos absolutamente requeridos en ella. Después haz que la interfaz de la Fed implemente tu nueva interfaz y luego usa esa nueva interfaz en el código del cliente, que no necesita saber sobre miembros de AP I irrelevantes fuera de una interfaz gorda. Esto es exactamente lo que hicimos en la segunda fila, factorizando a Dama mientras arreglaba el problema con la configuración. Y el último punto aquí que quiero abordar es que no deberías estrellar todas tus interfaces en un solo método en caras solo porque esto hará imposible la violación de hielo P. Se Blinder afecta las técnicas de Oring sólo cuando sientes que hay un papá técnico se detuvo a aparecer aquí y allá o si un papá técnico aún no ha empezado a propagarse. Pero sabes con certeza que lo hará si no arreglas la violación de hielo P. El último consejo que quiero decir sobre se refiere a la gestión de dependencias a nivel binario. Entonces lo profundo es que es mejor siempre que sea posible mantener la interfaz dentro del ensamblado del cliente . Hace más fácil cambiar la interfaz. Si algo anda mal, un cliente podrá cambiar la interfaz exactamente como quiere en lugar de desplegar cualquier adaptador. Está bien, eso es genial. Hemos llegado al final de la sección. En la próxima conferencia, concluiremos lo que has aprendido en este apartado. 32. Conclusión de 08: esta conferencia se titula Conclusión. El principal que discutimos a lo largo de esta sección fue el príncipe de segregación de interfaz o hablo en camisa, hay P tiene una definición sencilla. No se debe obligar a los clientes a depender de métodos que no utilicen. Por lo que esta definición implica que hay que esforzarse por las interfaces grandes, pequeñas, cohesivas y enfocadas. Por supuesto, diferentes clientes pueden usar sólo un subconjunto de los miembros del FBI de los que dependen. A menos que ese AP, empiezo a crecer transformándose en una interfaz muy gorda con miembros no relacionados entre sí , donde, cuando aparecen métodos similares pero diferentes para satisfacer los requerimientos de diferentes clientes . Una forma típica de violación que viste, era cuando una interfaz era demasiado amplia. Lo que llevó a algunos olores como implementador tiro no implementado excepción o los clientes tienen que ver toda la masa en la inteligencia pensando en lo que realmente necesitan usar como discutimos , hay varias formas de lidiar con hablo violaciones. En ocasiones basta con extraer una interfaz separada de una gorda y utilizarla cuando corresponda. En ocasiones hay que salir con una fachada que esconde irrelevante. Ap I miembros. En ocasiones necesitas aplicar un patrón de adaptador, especialmente si no eres dueño de la interfaz de grasa, y así no puedes modificar su código fuente. El apego inteligente al principio de segregación de interfaz hace que una aplicación sea más fácil mantener lo que es extremadamente valioso, sobre todo a largo plazo. Abusando hablo puedes terminar con tonos. Off to small interface es lo que los hace más difíciles de usar por clientes antiguos. Este es un olor conocido como anti hielo. Sea así llegamos al final de este apartado. Esa fue una investigación interesante. Pero hay otro principio que nos espera el principio de inversión de dependencia. El siguiente apartado está dedicado al D. I. P. Vamos directo a los negocios. 33. Esbozo de 01: Hola. Este es el último para divertirse de spot ingeniero de hornear. Y en esta sección, vamos a aprender dónde están los principios. Nos referimos a los principios de los que vamos a hablar en esta sección en cuanto a los principios de la materia porque son las raíces de todos los demás principios más concretos adheridos a los que realmente estamos tratando de conformarnos con los principios de la materia. Empezaremos desde la secadora. No te repitas principio. Aprendes la definición de los olores más comunes de violar el principio seco. Después de eso, aprendiste las llaves o lo mantuviste simple. Principio estúpido. Aquí vamos a hablar de simplicidad y complejidad, complejidad accidental y esencial y cómo lograr la simplicidad. El siguiente meta principio del que vamos a hablar es el yo joven o no lo vas a necesitar principio. Está relacionado con el olor innecesario complejidad y se refiere a las anticipaciones fuera de las características comunes . Analizaremos los problemas prácticos a los que nos enfrentamos y qué otras consecuencias la implementación de características que realmente no necesitamos. Después de eso, vamos a hablar del principio de calcetín o separación de preocupaciones. Este principio subyace al incienso. Todos los principios sólidos. La separación de preocupaciones es muy importante para lograr aplicaciones bien mantenibles. Verás las formas más comunes de violar la separación de preocupaciones. Principio Comando principio de separación de consulta hace más fácil razonar sobre. En el código se discutirá el mínimo de Demeter, que es el principal conocimiento fuera de la lista. Por separado, hablaremos del principio fuera menos asombro usted. Después tocaremos el tema de la ocultación y encapsulación de la información. Por cierto, utilizaré la palabra principio en lugar de principio de materia en esta sección. Además, sólo por el bien de ahorrar algún tiempo en la próxima conferencia, aprende sobre el principio seco. Empecemos. 34. Definición de 02 DIP: esta conferencia se titula Definición Off the A P. El principio de inversión de dependencia es todo sobre el desacoplamiento. Esto es muy importante, así que les recordaré qué es el acoplamiento. El acoplamiento indica cómo están los módulos dependientes en los trabajos internos uno al otro. Los módulos fuertemente acoplados se basan ampliamente en el estado específico uno al otro, compartiendo variables y muchos tipos módulos poco acoplados son bastante independientes. Tienen unos ojos AP bien definidos y comparten una cantidad limitada de descuento o ningún dato en absoluto. Entonces el acoplamiento es lo que intentaba es el proceso de lograr los módulos flojamente acoplados . Aquí puedes entender los módulos, tanto como las clases eran la dicha de Assam. El D I P es aplicable a diferentes niveles en el nivel de código fuente en el nivel binario. Si miras Wikipedia, verás que el acoplamiento bajo suele ser una señal de apagado. Un sistema informático bien estructurado y el buen diseño y cuando se combina con una alta cohesión , apoya a las chicas en general fuera de mayor irritabilidad y mantener capacidad Bueno dicho efectivamente. Entonces, ¿cuál es la definición formal? De acuerdo con los principios infantiles, patrones y prácticas en Souchard por el tío Bob, módulos de alto nivel no deben depender de módulos de bajo nivel. Ambos deben depender de las abstracciones. Las abstracciones no deben depender de los detalles. Los detalles deben depender de las abstracciones. Parece que esta es una definición con dos niveles. El primer nivel se refiere a los módulos y el segundo se refiere a las abstracciones. Esta es una gran definición, sin embargo. Siempre es Requiere alguna aclaración más, ya que es muy difícil aplicar en la práctica. Dicho consejo es sin ver ningún ejemplo práctico. Yo quiero mostrarles una imagen que demuestre la D I pena la vida real. Dado el zócalo de la lámpara y un soldado. Una pregunta. Levántate. ¿ Soldarías una lámpara directamente al cableado eléctrico en una pared? Si haces eso, solo podrás usar ese zócalo para esa lámpara porque son por así decirlo apretadamente acoplados. Para solucionar el problema, necesitamos salir con un enchufe estándar, que se puede ver en la imagen pequeña derecha. Si todos los dispositivos implementan tal enchufe, entonces pueden bloquear en el zócalo. Lo mismo es cierto para las dependencias y el código. Las políticas de alto nivel no deben depender directamente de los detalles de bajo nivel en caso de que cuatro dispositivos de imagen no sean enchufes directamente dependientes. Se puede encontrar una excepción de casi todas las reglas. Entonces mira esta imagen. Este es un hotel barato donde el secador de pelo está cableado directamente al enchufe. Pero en este caso, esto se hace intencionalmente, y en realidad es significativo. El propósito en este caso es defender nuevamente a la secadora de los ladrones. Este es un caso raro en esta conferencia. Mencionamos la noción fuera de la dependencia. En la próxima conferencia, veremos más de cerca las dependencias. 35. 03 Dependencias 01: Esta conferencia se titula Dependencias, Definamos lo que entendemos por una dependencia. Existen varios tipos de dependencias en el marco en hojas de tercer cuerpo, sistemas externos como base de datos del sistema de archivos o cualquier recurso del sistema y dependencia cosida en un tipo personalizado construido encima del framework dotnet. En esta sección, el tipo de dependencias más importante para nosotros son las dependencias sobre tipos personalizados que son desarrolladas por nosotros. Por ejemplo, aquí en la diapositiva, el vidrio de la persona depende de la clase de repositorio personal. Una persona no puede proporcionar sus características sin depender de la clase de repositorio personal. El repositorio de personas es una clase de bajo nivel que el Inter opera con una base de datos, mientras que la persona es el objeto de dominio de alto nivel. Por lo que en este caso particular, el objeto de alto nivel depende del objeto de bajo nivel. Tal caso está alineado con la forma en que los principiantes construyen software. Tradicionalmente, este es un alto nivel de ti en una aplicación clásica, con tres lágrimas en la parte superior, tenemos una interfaz de usuario. Una interfaz de usuario llama a un p I off objetos que implementan objetos de lógica empresarial que implementan lógica empresarial, llaman al chico fuera de objetos infraestructurales de bajo nivel los cuales implementan en operación con una base de datos, servicio web externo y así sucesivamente. ¿ Qué tiene de malo las relaciones entre capas en este diagrama? ¿ Saben qué es? El problema es que los objetos de alto nivel fuera de la capa de dominio dependen directamente de los objetos de bajo nivel de la capa infraestructural. El lámpara está soldada al zócalo como un vicio. ¿ Qué harías si entra en juego un requisito para cambiar el sistema de gestión de bases de ? Es difícil como el infierno reemplazar una dependencia. Si hay un acoplamiento apretado entre las dependencias, las partes que cambian con mayor frecuencia recitan en límites fuera de una interfaz de usuario del sistema y las cosas relacionadas con DB son irrelevantes desde la perspectiva del dominio, por lo que la lógica del dominio debe ser independiente de las cosas irrelevantes. Para solucionar el problema, necesitamos revertir la dependencia que apunta hacia la capa infraestructural. En este ejemplo, les mostraré cómo podemos desacoplar una obstrucción de otra. Una teoría fundamental. ingeniería de software de Mawf establece que podemos resolver cualquier problema introduciendo un nivel extra de indirección. Entonces hagámosle exactamente eso a la persona de la pareja del repositorio. Aquí está la diapositiva, que refleja los cambios realizados por un factoring más simple que a menudo nos referimos a tales interfaces como a parece, estas escenas nos permiten inyectar cualquier dependencia que queramos. ¿ Cuál fuera de curso implementa esa interfaz? Se trata de una técnica sencilla pero poderosa para invertir las dependencias, logrando un bajo acoplamiento entre los componentes. Otro aspecto interesante. Preocupaciones en torno al tiempo y tiempo de compilación. Dependencias. Mira el diagrama aquí. Tener un módulo A que vaya función F en módulo. Estar a través de la interfaz cuando usamos polimorfismo creando una interfaz, insertándola entre el módulo A y el módulo B. Terminamos con ese módulo A tiene alrededor del tiempo dependencia de B, pero no tiene una dependencia de compilación en él. Podemos compilar apenas más Joya A. Si queremos. Sin que tu compilación de módulo esté en lenguajes como C Plus plus, ayuda a reducir significativamente la cantidad de tiempo de compilación. Eso fue lo básico de lo que están las dependencias. En la próxima conferencia se echará un vistazo más de cerca a dos tipos principales de dependencias 36. Dependencias de 04 dependencias Volatile y estable: pero esta conferencia se titula Dependencias Volátiles y Estables. En la conferencia anterior, se vio en un ejemplo sencillo cómo invertir la dependencia en el repositorio introduciendo una capa fuera en dirección una pregunta lógica, que viene a la mente se refiere a qué dependencias deben látigos rastreados. Y para responder a esta pregunta, lo primero que tenemos que hacer es darnos cuenta de que todas las dependencias se pueden dividir en dos campamentos. ¿ Un mosaico y dependencias estables definimos dependencias volátiles o, en otras palabras, dependencias inestables? Según Mark semen, una dependencia debe considerarse volátil. Si alguno de los siguientes criterios es cierto, la dependencia en sí depende del entorno, lo que obliga al enfriador a configurar ese entorno. Un ejemplo clásico sería una dependencia de una base de datos o cualquier tipo que implique en la reparación con una base de datos. Cualquier otro sistema externo, como servidores Web, también entra en esta categoría. Todavía no existe la dependencia y aún está en desarrollo. Este es un trato regular cuando queremos escribir código, que entre otras cosas, interoperan con un objeto en existencia. En este punto, no queremos esperar a que se escriba ese objeto, por lo que nos acaba de introducir una costura, que refleja el A P I de ese objeto y hacer llamadas a través de esa escena. El dependencia, que no está instalado en todas las máquinas fuera de los desarrolladores y la dependencia, tiene un comportamiento de stick de menos de 10 minutos. Puede depender de la generación diurna ahora números aleatorios y similares inestables por su naturaleza . Cosas en general. Podemos definir dependencias estables ya que la dependencia es que no son volátiles. Puede sonar extraño, pero bastante simple y útil, así que nos quedaremos con la definición. Dependencias volátiles son aquellas que querrán abstraerse introduciendo niveles desde la dirección. Ya que son inestables, al menos necesitamos tener una forma de reemplazarlos por dobles de prueba en pruebas unitarias. De lo contrario, podemos terminar con aplicación BLE no probada. Recuerda que puedes tratar una aplicación comprobable hasta que su diseño permita escribir pruebas sindicales . Si una aplicación permite sólo pruebas de integración, debe considerarse ble no probada. Elaboremos el tema de la dieta sea aprendiendo términos muy cercanos. I o. C y D I. Hablaremos de ellos en la próxima conferencia 37. 05 Definiciones de IoC e DI: esta conferencia se titula Definiciones Off Fire C y D I. En la conferencia donde discutimos la noción de dependencias, vimos este diagrama. Si miras más de cerca, notarás que el Mogul A tiene una relación fuera de composición con la interfaz. Significa que necesitamos inyectar el módulo B como el implementador fuera de esa interfaz. De alguna manera, este ejemplo demuestra lo que es la dependencia. Dependencia de inyección La inyección es una de las nociones más importantes que utilizará a lo largo este apartado. Entonces separemos el principio de inversión de dependencia, inyección y dependencia para evitar malentendidos fuera de estos conceptos estrechamente relacionados entre sí. En realidad hay otro término general en la versión de control, y también se debe entender la diferencia entre estos términos y los dos anteriores de los que hablamos. Entonces vamos a dar definiciones a estos términos, y vamos a partir del COI. Inversión de Control es un término muy general, que refleja las relaciones móviles off entre un enfriador y un collie. Un flujo clásico de control implica que un cliente tiene un control total sobre el entorno y secuenciar llamadas a métodos de biblioteca. El inversión del control implica que Macaulay podemos implicar cualquier método de biblioteca cuando decimos llamar. Toma el control sobre algunos resfriados entre el color y el llamado. La forma más simple de una nueva versión de control son los respaldos fríos. La idea principal fuera de una devolución de llamada es proporcionar una forma para que una llamada vuelva a llamar a un color. Entonces por eso hay una diferencia muy importante entre las bibliotecas regulares y los marcos. Los marcos gobiernan el cliente. Los marcos de abrigo proporcionan bloques que tienen que ser solo de campo por parte de los clientes. Los marcos también tienen el control sobre el medio ambiente. Esta es la inversión del control en la dependencia de la acción. Principio de inversión es una versión más detallada fuera de la inversión de la noción de control D. I. P. Concretar es que los módulos de alto nivel no deben depender de módulos de bajo nivel y así sucesivamente. La inversión del control es una cuestión de principio. En cierto sentido, acuerdo a la definición fuera de la inyección de dependencia dada por Mark Semen en su libro Inyección de dependencia en punto net, que Air Command a usted mucho. La inyección de dependencia es un conjunto de principios y patrones de diseño de software que nos permiten desarrollar código de acoplamiento suelto. Al mismo tiempo, hay que entender que he visto puede existir sin d I IOC es posible sin die porque podemos cambiar la implementación confiando en subclase ing, ejemplo, por ejemplo,jugando el patrón de plantilla que se discutió anteriormente. No obstante, la principal forma de realizar la inversión del control es responder las técnicas de inyección de dependencia . En la siguiente conferencia, verá un ejemplo de violación del día P. 38. Demostración de violencia de la persona DIP: Aquí te dejamos una dama simple, que demuestra la esencia de un problema. En este caso, tienes una clase llamada Divergence Checker, y esto es lo que tiene a dispositivos físicos, los cuales están representados por dos clases, encuentro y registro fiscal. Er, este es un caso de mi práctica en Rusia. Cuando vendemos algo, necesitamos registrar la operación de venta en un dispositivo especial denominado Registro Fiscal. ER, en mi caso, tendrá un dispositivo separado el cual realiza operaciones de encriptación y descifrado y desafortunadamente, tiene que duplicar la responsabilidad de un registro fiscal, manteniendo todos los detalles sobre células en seguridad. En consecuencia, necesitamos verificar periódicamente que no haya divergencia entre contadores fuera de un registro fiscal y ese dispositivo especial representado aquí por la clase de contador para realizar la comprobación. Implementé esta clase Ahora mismo. Esta búsqueda lógicamente tiene a dependencias. Depende de un contador y registro fiscal. ER, estas clases platicaron directamente con dispositivos físicos en el mundo real, el corrector de divergencia de juegos expuso más de un método público, pero en este caso, basta con tener el único que este método realmente comprueba. Si hay una divergencia entre contadores fuera de dos dispositivos. Este método utiliza ambas dependencias. Se necesitan dos contadores de un dispositivo y lógicamente mismos contadores de otro dispositivo, pero luego sólo comprueba. Si los valores correspondientes son iguales, digamos que queremos escribir una prueba unitaria para el método de divergencia de cabezas. ¿ Cómo vamos a hacer esto con el diseño actual, no hay forma de escribir una prueba sindical para ganar divergencia. La clase Checker está estrechamente acoplada al mostrador y al registro fiscal. ER, estas dependencias son inestables o volátiles ya que representan dispositivos físicos riel. Dispositivos físicos siempre están inclinados dedo del pie inestable pelo ba. Por eso no podemos escribir pruebas unitarias confiables. En la próxima conferencia, veremos tres maneras de aplicar la inyección de dependencia para solucionar el problema. 39. 07 refactoring de una inyección de mayor calidad de calidad de 07: La causa raíz del diseño comprobable de la ONU en este caso es que esta clase es deshonesta. Miente a sus clientes. Miente sobre el hecho de que tiene que hacerlo. La dependencia es que miente ocultándolos. El, um, primera forma de solucionar el problema es hacer visible la dependencia. Hay tres formas principales de lograr esa inyección Constructor, inyección propiedades e inyección de métodos. La inyección de constructor es cuando las dependencias de solicitud que se pasarán a través del constructor. Entonces el obvio reflector y se puede hacer es esto. El primero que tenemos que hacer es crear una escena que sirva de límite entre la lógica principal y los dispositivos externos. Ahora podemos continuar con nuestro proceso de re factoring. Ahora un cliente no puede crear la ganancia querida contra Checker sin pensar en dependencias. Un cliente los ve y tiene que decidir qué a Passan. Se traslada la responsabilidad al lado del cliente y esto es bueno. Ahora podemos escribir una prueba unitaria reemplazando estas dependencias por dobles de prueba que están bajo un control total del código de clientes. Antes de escribir una prueba unitaria. Mira las otras dos opciones inyección de propiedades y método de inyección. En primer lugar, veamos cómo se llama Luke falta con una inyección de propiedad. - La diferencia entre esta opción y la anterior es que el código de clientes puede restablecer la dependencia siempre que le guste al mismo tiempo. Desde la perspectiva, un cliente ahora puede crear el comprobador de divergencia de ganancia y olvidarse de establecer las dependencias. Después de eso, puede llamar que tiene divergencia, método y cara que otra excepción de referencia. Significa que la encapsulación de esta clase está rota. No brinda garantías de que sus métodos funcionarán como se esperaba. Otra opción es solicitar las dependencias en el método donde se necesitan. Puede parecer un poco raro, pero es opción absolutamente válida. En este caso, el código de clientes desconocerá alguna dependencia hasta que llame al método. Este diseño preserva la encapsulación. Proporciona garantías de que tienen divergencia. El método funciona como se esperaba. En cualquier caso. Escribamos una prueba unitaria, que valida la corrección de los cabezales gradodel método de divergencia grado . Pasa la muerte. En esta conferencia, has visto un ejemplo sencillo de aplicar las técnicas de inyección de dependencia ahí efectivamente, realmente simple. En ejemplos más grandes, las técnicas seguirán siendo las mismas antes de continuar. Quiero dar un resumen de las técnicas de tres días que acabamos de aplicar en la siguiente conferencia 40. Técnicas de 08 DI: esta conferencia se titula D. I. Técnicas. La inyección de constructor implica que las dependencias se van a pasar vía constructor. El aspecto más beneficioso de la inyección de constructor es que protege la en varianza del objeto que el objeto quiere. Crear siempre será estado inválido. No obstante, debes estar al tanto de las siguientes posibles trampas. En sistemas grandes, inyección constructor tiende a un camello. Ocho dependencias muchas. Es posible que veas más de tres dependencias solicitadas vía constructor. No obstante, este no es el inconveniente de la propia inyección del constructor. Lo más probable es que esta sea una sonrisa de violar este R P. En caso de que un constructor requiera que se pasen más de tres o cuatro dependencias, considere la posibilidad de extraer cualquier responsabilidad en clases separadas. A veces sucede que varias dependencias tienden a pasar juntas. Aquí hay un fragmento de código, que muestra que si tu modelo toma por dependencias e imagina que muchos otros modelos de vista toman las mismas dependencias también. En tales casos, sería prudente crear un objeto contenedor para ellos y requerir que el objeto contenedor sea mejor en los constructores. Parece que no tiene efecto, pero siempre es una buena idea unir objetos que van juntos en muchos casos. Un día se quiere introducir una validación personalizada importada, que está relacionada, dijo a las dependencias o algo así, sin embargo lo más probable es más que por parámetros es el olor de estas violaciones de Artie, dije. Así que echa un vistazo más de cerca a las responsabilidades de una clase que requiere tantas dependencias. Otro caso interesante se refería a esto, por así decirlo. La dependencia no obligatoria es como un maderero. Se trata de una solución válida para exponer varios constructores, algunos off que dijeron las implementaciones por defecto fuera de las dependencias. Aquí se puede ver un ejemplo. En este caso, puedes reemplazar en la unidad test el I A logger Por un carajo, es doble el cual no hace nada mientras en el código de producción, los clientes solo pueden usar el constructor por defecto, ya que en la mayoría de los casos, nadie le importan los mecanismos de tala. Otra hermosa con la que podría tropezar es que tales marcos, como el marco de entidad u otros mapeadores relacionales de objetos, pueden requerir de los objetos tener un constructor público predeterminado. En tal caso, se verá obligado a exponer la construcción pública por defecto. De lo contrario, obtendrás una excepción en el tiempo de ronda. Por supuesto, se puede considerar escribir un envoltorio alrededor de tal objeto, que se encuentra muy cerca de un bounder de un sistema, preservando así la encapsulación. Si cierta dependencia se usa solo un solo método, entonces considere eliminar esa dependencia del constructor y se solicita como argumento del método que ciertamente lo necesita y no puede proporcionarle sirve sin ella. En otras palabras, considerar utilizar el método inyección de propiedades implica exponer las dependencias vía propiedades con setters públicos. Permite reemplazar la dependencia durante toda la vida útil del objeto. La flexibilidad es la principal ventaja. En este caso, sin embargo, los inconvenientes son tan pesados que debemos esforzarnos por confiar en esta forma de inyectar Onley en caso de no obligado. La independencia es de tal Slager. En tales casos, siempre debe haber implementación predeterminada fuera de la dependencia, y debe establecerse en un constructor predeterminado o derecho en la propiedad. ¿ Ves el ejemplo en la diapositiva? Este adicional dorado se basa en la tienda del mar. Seis Característica off inicialización de la propiedad. En cualquier otro caso, debe evitar la inyección de propiedades, ya que fácilmente puede romper la encapsulación de una clase y hacer que la dependencia esté oculta. La independencia se expone ya que las propiedades están ocultas porque nadie está obligado a recordar todos los detalles internos de un método de clase. La inyección es una técnica interesante. Dependencias, que son propiedades de incendio establecidas, o constructores, suelen ser utilizadas por muchos métodos a lo largo de toda la vida útil del objeto. No obstante, a veces y la implementación lee varían de una llamada a otra o si el método es estático, por ejemplo, la conversión de una moneda a otra requiere de un objeto que obtenga la tasa. Un ejemplo similar es el proveedor de formato I, que se requiere en métodos como barras dobles. No obstante, piénsalo dos veces antes de implementar inyección de método Si quieres pasar una dependencia directamente a una matemática. Tan sólo porque Onley ese método entre otros 20 métodos utiliza esa dependencia, entonces esto es un olor a una violación sirubia, tal vez una responsabilidades separadas que se esconden dentro del cristal. Otro problema con este enfoque es que los contenedores IOC no pueden inyectar automáticamente las dependencias. Dos métodos que veo contenedores son herramientas que ayudaron a automatizar el proceso de inyección de dependencia , y lo discutiremos más en este apartado. De acuerdo, ahora tenemos la idea de inyección de dependencia y tres técnicas principales. Estas técnicas simples tienen implicaciones fundamentales fuera de curso. En el rial, las cosas vivas pueden ser un poco más duras de lo que estaba vendiendo esta conferencia. Los problemas, es belleza, el nivel arquitectónico. Hablemos de implicaciones arquitectónicas fuera de la inversión del control Inyección de independencia en la próxima conferencia. 41. 09 Implicaciones de arquitectura: esta conferencia se titula Implicaciones Arquitectónicas. Invertir la Dependencia es el medio por el cual creamos límites entre los módulos de software . Cuando queremos crear un límite, elegimos qué dependencias invertir contra el flujo de control. Por lo que todos apuntan en la misma dirección a través de los límites limítrofes, como en esta diapositiva fuera del camino creamos bludgeons. Un plug in es un módulo que es llamado de forma anónima por otro módulo. En otras palabras, del collar no tiene idea de quién o qué está llamando en este caso. El módulo que no conoce llama al módulo. Ser bludgeons se pueden desplegar de forma independiente y además, sus de forma independiente desarrollan un ble. Dividimos el sistema por límites y luego invertimos. El dependencia es que cruzó esos límites por lo que ruboriza definiendo los límites fuera tu sistema. El viejo modelo de construcción de sistemas de software con tres niveles es ese móvil centrado en datos en tales arquitecturas de la base de datos y ese esquema es el centro del sistema. Activa todas las demás partes del sistema. Francamente hablando, este enfoque sigue vivo y a veces podría ser beneficioso. Pero ahora los días se inclinaron a tratar base de datos y sus herramientas de I s, que pueden ser reemplazadas en arquitecturas centradas en datos. Una parte importante de la lógica principal se va a implementar en el sitio de base de datos por lo que se implementará en procedimientos almacenados con un lenguaje como secuela. El mayor problema con este enfoque es que lenguajes relacionados con el procesamiento de datos como Sequel , que son muy eficientes en el procesamiento fuera de los alumnos, no fueron diseñados para implementar la lógica empresarial por lo menos trozos significativos de lógica empresarial . Los lenguajes relacionados con la base de datos son muy pobres en características que permitieron motilar las relaciones entre objetos de dominio. Esta es una de las principales razones por las que la comunidad mundial de desarrolladores cambió a otro enfoque donde la base de datos es tratada como un detalle de bajo nivel. Y aquí llegamos al punto en que seguimos analizando las implicaciones fuera de la arquitectura a partir de enchufes. Aquí hay un diagrama donde el dominio se encuentra en el centro. Cuando tratamos bases de datos y ustedes sabias herramientas, que en su mayoría son irrelevantes, nos ocurre la idea de que el núcleo de la aplicación fina es la lógica de dominio. La lógica de la demanda es la parte más estable del sistema. Parece que las políticas de dominio cambiaron relativamente raras. Por ejemplo, la parte derecha cambia con mucha más frecuencia. Observe que todas las dependencias apuntan hacia el dominio. Si agrandas este diagrama, suponiendo que estas grandes guaridas están compuestas por muchos objetos, obtendrás el siguiente diagrama. Tengo este diagrama justo de la cuadra de Mark Semen. Noté que toda la dependencia sigue apuntando hacia el centro fuera de aplicación. Si ingresas las capas a este diagrama, terminarás con lo siguiente. Este diagrama representa lo que las arquitecturas llaman arquitectura cebolla. Existen otras nociones similares, como arquitectura hexagonal y puertos y adaptadores. Arquitectura. Todos estos términos significan esencialmente lo mismo. Todos son alrededor de los mismos puertos. Todos esos parece que introdujimos extrayendo en caras y adaptadores son enchufes, que provienen del bounder fuera de un sistema en sistemas grandes. El gráfico de dependencias es muy grande, aunque debes esforzarte por mantener la gráfica s más plana como puedas, aunque mantengas la gráfica plana. También puedes enfrentar el problema fuera controlar la vida útil de las dependencias. Esto lleva a una pregunta interesante. Quién es el responsable de mantener el control sobre la instancia de dependencias, ver ation en su vida y luego jurar es obvio. Cualquier aplicación comienza desde el método principal. Los desarrolladores suelen referirse a Maine no a un punto de entrada físico, sino a un punto infraestructural donde deben configurarse todas las relaciones entre dependencias . La idea de configurar todas las dependencias en un solo lugar en Maine realmente se ajusta al principio de elección única que se discutió en la sección OCP. Maine es el único lugar que sabe todo sobre las sanciones en sus relaciones . No significa necesariamente que todas las dependencias serán inst enshi ated en Maine. Algunos de ellos pueden ser instancia que odiaba en Maine. En efecto, el otro se creará automáticamente en el tiempo de ejecución, acuerdo con la configuración realizada en la partición principal. En esta conferencia, nos dimos cuenta que lo principal es el punto infraestructural donde montamos todas las dependencias. Ahora tenemos que entender cómo configurarlos en la práctica. En la próxima conferencia, veremos más de cerca la pureza. Yo y yo vemos contenedores. Están relacionados con dos técnicas mayores que permiten configurar las dependencias e inyectarlas adecuadamente 42. 10 envases de DI, puro e IoC: esta conferencia se titula Pure D I y he visto contenedores. Esperemos que ahora entiendas las posibles dificultades que podrías enfrentar aplicando las técnicas de inyección de dependencia . Básicamente, hay dos formas de lidiar con la inyección de dependencia. El 1er 1 es crear manualmente todas las dependencias y dependencias fuera de dependencias e inyectarlas explícitamente llamando al nuevo operador pasando en el constructor. Todas las dependencias requeridas Mark Semen, se referían a estos abordaje manual en cuanto a la llamada muerte del hombre pobre en 2014 Mark aparentemente retiró este término, sustituyéndolo por un nuevo término puro die. El motivo fue que el pobre hombre D me sonaba un poco despectivo o un t menos poco atractivo. Tampoco comunicaba el mensaje de que mueren sin un D. Un contenedor es en muchos casos mejor que el ojo dentro del contenedor IRC. Por el contrario, sonaba como si no fuera tan bueno. Esa fue una cita del Bloque Mark Seamans, Bost. Te mostraré un ejemplo de puro die de una solicitud de reserva o escrito por Mark Semen. Se puede ver aquí en los principales lotes de código. Este es ah conocido ejemplo trivial, que demuestra lo difícil que puede ser configurar y rastrear todas las dependencias manualmente confiando en un D I. puro Por eso tenemos contenedores IRC completos. Volvamos a deslizar la segunda forma de tratar con los ojos para depender de un contenedor del COI . Entonces, ¿qué es un contenedor IRC o un contenedor D I? En otras palabras, veo que el contenedor es un marco que ayuda a aplicar la dependencia. Inyección. Esta es la característica principal del contenedor de hielo Fannie. Veo que el contenedor inyecta dependencias automáticamente fuera de curso los contenedores proporcionan la capacidad de configurarlas configurando esas dependencias. Entonces cuando el código de clientes le pide a un contenedor que resuelva una dependencia en particular, un contenedor sabe cómo crear esa dependencia. Sabe crear las dependencias fuera de que dependencias soldado crea coercitivamente Alden dependencia accesoria es hasta que crea. Solicitaron uno. En la diapositiva, se puede ver un diagrama de dependencias de tipo. Imagina que hacemos una llamada a Nizer Container para resolver el principal de tu modelo. En otras palabras, queremos de una enfermera un contenedor para sacar una instancia de la principal de tu clase móvil. El principal de tu clase media depende del cliente yo en cara. Toma esta interfaz en su Constructor. Por lo que para crear el modelo de vista principal, el contenedor del IOC buscará más allá Para averiguar cómo resolver la interfaz del cliente I, el contenedor encontrará la clase de cliente que implementa esa interfaz del cliente, por lo que el contenedor intentará crear la búsqueda del cliente. Para crear la clase de cliente, el contenedor tiene que pasar a su constructor que yo repositorio de clientes ya que la clase de cliente depende de esta interfaz para resolver el repositorio de clientes I, IOC seguirá cavando más profundo y encontrar al implementador de esa interfaz. Encontrará que yo interfaz de cliente puede ser resuelto por el repositorio de clientes. Pero para crear el repositorio del cliente el contenedor y necesidad de resolver el I. D ser Gateway parece que el repositorio del cliente depende de ello y finalmente muere. El contenedor creará la puerta de enlace de base de datos y después de ese contenedor creará repositorio de clientes que cliente y luego el principal de su modelo. Entonces así es como nuestros contenedores de mar un lee recursivo resolvieron dependencias. Este diagrama no muestra el propio contenedor del COI. Si ponemos aquí, hay una clase de contenedor. Dependerá de todo este tipo. Tiene que saber de todas las dependencias. Es el trabajo del contenedor, su responsabilidad. En la siguiente conferencia, quiero demostrarte rápidamente cómo construir una implementación ingenua a partir de un simple contenedor del IOC para aclarar el mecanismo básico de cómo funcionan. 43. 11 Construir un contenedor de IoC simple: Vamos a implementar un contenedor muy simple veo. Al principio, definiré un mapa entre tipos. Este mapa contendrá un 1 a 1 relaciones entre dependencias. Aquí está fuera de curso. Necesitamos exponer un método público que permita a los clientes registrar dependencias. Este es un método genérico que toma dos tipos y los agrega a nuestro mapa. No hay nada más que explicar. Vamos a crear un método público para resolver dependencias. Este método también es genérico. El parámetro T es el tipo que un cliente quiere ser resuelto. Este método llama a otro método el cual será privado e implementará toda la lógica fuera del contenedor. Aquí obtenemos el tipo correspondiente del mapa. Si no lo encontramos, lanzamos una excepción. Observe que tenemos un tipo. Esto no es una instancia fuera de un tipo. Es su descriptor. Veo que los contenedores usaban un reflejo en gran medida. Sin reflexión. Es imposible analizar las dependencias de tipo y crearlas adecuadamente, teniendo un tipo que podemos solicitar. Se trata de constructores. Implementamos un contenedor COI muy sencillo. Entonces por el bien de la simplicidad, solo obtengo el primer constructor de un tipo teniendo descriptor de un tipo podemos solicitar sus parámetros. Si no hay parámetros, simplemente creamos una instancia fuera de una dependencia y la devolvemos. De lo contrario, tenemos que resolverlos. Lee recursivo. Por lo que necesitamos hacer lo siguiente este frío recursivo Lee intenta resolver todos los parámetros constructores. Al final, queremos crear una instancia fuera de una dependencia, por lo que llamaremos al constructor pasando los parámetros. Aquí vamos. Confía en mí, Este es un contenedor RC muy sencillo. Nada más, nada menos. Tratemos de usarla. Digamos que queremos resolver el modelo de vista principal. Te mostré en el diagrama en la conferencia anterior. Antes de resolver el modelo principal que tú, tenemos que configurar el contenedor del COI. Entonces estamos registrados. La dependencia es uno por uno, modelo de vista principal se mapea a sí mismo en caras se mapean al implementador correspondiente Z. Después de eso, podemos resolver el grado del modelo de vista principal. Dije un punto de ruptura y lleva a frenar el programa para asegurar que todo funcione bien. Sí, se puede ver dónde está el punto de freno. Y si paso el puntero del ratón sobre la instancia del modelo de vista principal. Veo que se creó con éxito. Todo funciona bien. Entonces esa fue la esencia fuera de cualquiera. Veo contenedores. En la próxima conferencia, les mostraré una aplicación que se construye con contenedor NRC para demostrar cómo pueden verse los escenarios del mundo real . 44. 12 Demo de una aplicación real de mundo construida con un contenedor de IoC: aquí se implementa una sencilla aplicación que permite gestionar a los estudiantes menos ajenos. La solución consiste en varios proyectos. El gerente de alumnos es una aplicación WP F que contiene vistas, y veo bootstrapping de contenedores. Si quieres más granularidad, puedes mantener la cara bootstrapping en un ensamblaje separado. Marco indio es el marco que soporta el patrón MVV n y en este caso proporciona unos ojos simples, un contenedor. Echemos un vistazo a la aplicación eran de cerca esta aplicación soporte operaciones de multitud simples . Se trata de una aplicación WP F y se implementa con ellos V V M Patrón. Esto implica mejor vista móvil de tres partes y las vistas vía móvil están representadas por archivos de ejemplo . lo que las vistas representan el porqué cada uno de ustedes tiene un modelo de vista correspondiente con el nombre correspondiente. Por ejemplo, la vista principal tiene el principal correspondiente de su modelo. Los elementos están vinculados a propiedades y métodos fuera de un modelo de vista correspondiente. Esto se logra a través de mecanismo especial en WP F llamado enlace de datos. Por ejemplo, si el usuario hace clic en el botón de agregar en la vista principal, esa llamada será manejada por el método de estudiante de anuncios, que pertenece al modelo de vista principal. La replicación se construye con ayuda de un pequeño marco, que también escribí por mí mismo con el fin de demostrar cómo proporcionan los marcos. Esos parece para ennegrejos notan que el modelo de vista principal requiere que se pasen tres argumentos vía constructor. El primer dependencia es la interfaz, que permite realizar operaciones de multitudes sobre los estudiantes. La base de datos, en este caso está representada por un archivo XML. Por el bien de la simplicidad, no tengo agregador permite pasar mensajes entre cualquier componente de un sistema. Nuevamente, estos detalles no son muy importantes para nuestra discusión. El último dependencia representa una escena proporcionada por el marco que permite abrir y cerrar nuevas vistas desde dentro de los modelos de vista. Cuando construyes una aplicación basada en el olvido, tienes que conectar vistas y remodelar. De alguna manera una forma importante es en En su lugar se comió una vista y luego de ti modelo y otra es lo contrario. Al principio creativo modelas y luego localiza, y en su lugar se comió una vista correspondiente. Nuestro marco soporta ambos modelos. Veamos ahora el framework y cómo nuestra aplicación está consiguiendo bootstrap. Este marco. Es el marco que permite conectar automáticamente tus modelos, conectándolos a vistas para proporcionar esta característica. Un framer tiene que saber qué ensamblajes escanear a través de la búsqueda de un correspondiente de su modelo. El buscador se basa en la convención de nomenclatura. Si se creó una vista principal, entonces un marco buscará a un hombre de tu modelo en los ensamblajes. A esto se suma arrendada por la aplicación que se basa en este marco. Aquí está el oro chunk off, que escanea a través de ensamblajes y busca un modelo de vista y ahora la parte más relevante respecto a nuestro tema. El bootstrap ER base es un gran look el cual nos expone un vaso abstracto el cual tiene que ser implementado en el principal off. El aplicativo que quiere confiar en el framework esto parece, permite framework toe resolver automáticamente dependencias e g. crear e insertar implementador interfaces Zoff. Los ensamblajes selectos deben ser anulados por el cliente. Debería devolver una lista completa de las asambleas que contenían dependencias. Pero obtienen instancia, es un método abstracto el cual será utilizado por el marco para resolver las dependencias. Por lo que un cliente debe anular este método usando un contenedor IRC que quiere usar configure para a tiempo y configure para el tiempo de diseño debe configurar el contenedor helado y tienen que ser escritos por un cliente. El método principal de un cliente debe llamar a un método de inicio que configura el marco. Este método configura todas las cosas internas fuera de un marco. Y entonces también puedes notar que el método off resolviendo se asigna a un estado de campo público fuera de la clase IOC. Esta clase representa un localizador de servicios. Con esta clase, puedes solicitar dar resultado por dependencia desde cualquier lugar que quieras. Esto es necesario porque hay un par de lugares en el marco donde se utiliza este método . De lo contrario, el marco no tendría acceso al mecanismo fuera de la pena. Resolver proporcionar por cliente. Recuerda que debes llamar al contenedor solo desde el código infraestructural. Si llamas explícitamente al código de clientes avizados, probablemente debes ocultar las dependencias. Echemos un vistazo al lado del cliente. Declinado hereda de la base stripper del barco. Utiliza el viejo y potente contenedor RC llamado Castell Windsor. El contenedor Windsor se define como un campo. El ensamblado selecto regresa a los ensamblajes, ensamblar fuera uso y ver modelos. El configure alrededor de la instancia de tiempo sombrea el contenedor, pero luego registra la primera dependencia mediante el uso del AP Windsors, diré que si se solicitará un contenedor para resolver el proveedor de datos I de estudiante, debe pasar el proveedor XML de Estudiantes como la implementación de la interfaz genérica. Además, decimos que crear el proveedor XML de los estudiantes un contenedor debe pasar el rap de los estudiantes sobre XML String como argumento al constructor. Tengo Integra, Gator y yo administrador de ventanas se registran después. Están registrados de la misma manera excepto un detalle que se refiere a su vida. El método Lifestyle Singleton asegura que el implementador Zoff estas interfaces se crearán una vez y después de eso, la misma instancia se pasará por todas partes. No tengo agregador ni yo administrador de ventanas solicité. Por lo que nos singularizan y dejarán a lo largo de toda la vida fuera de la aplicación hasta que se descargue el dominio de aplicaciones. Al final, hay una llamada al registro de su método de modelos. Míralo. Este método agrega al contenedor todas las clases cuyo nombre termina en modelo de vista. Es así como se implementa el arquitectónico con enchufes y los raperos para entender alrededor del flujo de ejecución del tiempo. Te mostraré el siguiente modelo de aplicación de diagrama está definido por el marco de par W. Define un evento de startup. Esa aplicación se suscribe a ella y el manejador puede ser tratado como el punto de entrada o el método principal. Este manejador crea la ER bootstrap, que hereda de la base stripper, definida en nuestro pequeño, um, marco Vivian. Y va el método de inicio. El método de inicio llama a la configuración alrededor del tiempo conduce al proceso apagado configurando el contenedor helado . El Castell Windsor en nuestra aplicación WP de proporciona el punto donde dijimos la primera vista la cual tiene que abrirse. Simplemente no te mostré. Se lo dije a una infraestructura especial de vista de shell de Yukol. Esta vista es un control de usuario que cuesta otras vistas. Shelve Utiliza un mecanismo especial de cableado automático, modelos fuera de vista proporcionados por el marco indio. Dado que todas las dependencias y todas las asambleas son bien conocidas por el marco indio, se trata de un poco de Cades. El estantería tu modelo y creó por qué hay un contenedor. El show de tu modelo crea automáticamente el principal de tu modelo de I I C, y las vistas correspondientes creadas a través del mecanismo especial WBF fuera de las plantillas de datos. Está bien usar están viendo la estantería tu modelo. Dado que esto de su modelo es infraestructura pura, es responsable únicamente de cambiar las vistas en la parte superior de una vista de shell. En este punto, se inicia la aplicación y la ventana principal es visible para el usuario. Ahora, cuando el usuario hace clic en, por ejemplo, en el at student Parton, el modelo View llama al gestor de ventanas I, que es parte del marco indio, pasando al tipo de un modelo de vista. El correspondiente view off, que tiene que abrirse en caso de apagarse en estudiante ahí se pasaría el estudiante de edición de tu modelo. Y aquí entra en juego el encuadrador. Crea el modelo de vista solicitado. Por qué eso he visto entonces localiza el tipo de vista y lo crea. Después de eso, conecta modelo de vista a revisión estableciendo el contexto de datos fuera de la vista toe la instancia de modelos de vista . Por último, el marco llama al W pay for method show en la ventana para que sea visible. Aquí está el flujo de ejecución. Observe cómo los marcos proporcionan muchos puertos para los clientes oro, lo que los dice por adaptadores implementados en el lado del cliente. El código de clientes define la lógica empresarial Framer hace su propio trabajo al proporcionar todas las características infraestructurales requeridas. Su contenedor marítimo asume la responsabilidad de crear dependencias y gestionar su vida útil. Cada parte hace su propio trabajo. Muy bonito. Si quieres cambiar el mecanismo de persistencia, no hay problema Solo implementado yo proveedor de datos y configura el I. C s u necesitas y listo. No hay problemas. Esta demo muestra cómo las aplicaciones del mundo real tal vez estructuran usted condone, Lou el oro fuente de esta aplicación y comenzó este ejemplo en su propio combustible tres. Para desacreditar la aplicación y mirar hacia fuera se construye en profundidad antes de pasar a la conclusión. Resumamos lo que hemos aprendido para marcar algunos olores comunes de violación de jp. 45. 13 hueles comunes de violaciones de infraciones de DIP: Esta conferencia se titula Olores Comunes de la Violación AP. Todos los olores comunes del día P violación toman sus raíces desde el día p definición. El I P establece claramente que las políticas de alto nivel no deben depender de detalles de bajo nivel, Por lo que los olores comunes son los siguientes. Un cierre crea explícitamente una o más dependencias ocultándolas de un cliente. Una clase utiliza la dependencia no determinista es como diurna o aleatoria. Hay formas de que la pareja este tipo de dependencias, que a menudo provienen del propio marco de dotnet. Una forma es crear una clase que funcione con dependencias no deterministas y cubrirla mediante pruebas de integración. Y otra opción es crear algún tipo de adaptador apagado. Es decir, crea tu propia interfaz e implementada en una clase personalizada, que utiliza dependencias no deterministas. Entonces puedes usar esa interfaz personalizada en el código de producción y reemplazada por dobles de prueba , que están bajo tu control En pruebas unitarias, una clase usa dependencias declaradas muy a menudo. Son solo estafadores de Singleton make unit testing de Singleton. Muy difícil. Dependencias declaradas de una clase también se ocultan a un cliente, por lo que si un estado de dependencia no era instancia correctamente, creado que una clase probablemente se comportará incorrectamente lanzando excepciones. Y así esto obliga a los clientes a recordar todo el tiempo sobre dependencias ocultas. Esto casi siempre es algo malo. La idea principal fuera quitar los olores D I. P es que se necesita extraer una capa fuera en dirección en Make the Class, que, mientras que es el D I p dependiente de esa capa off en dirección. Otro principio, que muchas veces ayuda, es el principio de responsabilidad única. Adherirse al SRP a menudo ayuda a evitar la extracción de interfaces inútiles. En la próxima conferencia, resumiremos lo aprendido en esta sección. 46. Conclusión de 14: Esta conferencia se titula Conclusión. En la sección aprendiste lo que es día sea día ser implica que las políticas de alto nivel no deben depender de detalles de bajo nivel. Ahí hay dos tipos principales de dependencia es estable e inestable o volátil. Dependencias inestables son aquellas a las que no aplicaremos la inversión del control. Qué inversión es la inyección de independencia de control y cómo se relacionan estas nociones el D. I P y entre sí. Tres técnicas de inyección de dependencia constructor de inyección, cuales deben utilizarse en el 95% de los casos, y la inyección de propiedades y métodos que se adhieren a la D. I P. Lleva a un enchufe en arquitectura, que comúnmente se conoce como la arquitectura de puertos y adaptadores. Esto nos llevó a una conclusión de que debería haber un solo lugar que sepa todo sobre aplicación, dependencias y sus relaciones, y este lugar está hecho. También aprendimos que la inyección manual de dependencia puede volverse tediosa y por eso veo existen contenedores, lo que ayuda a simplificar la inyección de dependencia. En casos difíciles, aprendes a construir un simple contenedor helado, y viste un ejemplo de una aplicación del mundo real que se basa en un contenedor helado y lo configura en Maine. Y también resumimos lo que el común huele de la violación de Diaby existe y cómo solucionarlos . Esta sección es la última de este volumen, que cubre el último principal de las siglas sólidas. En el siguiente volumen, discutiremos los principios de la materia y cómo se relacionan con principios sólidos. Te estaré esperando en el siguiente apartado. Gracias por ver. 47. Esbozo de 01: Hola. Este es el último para divertirse de spot ingeniero de hornear. Y en esta sección, vamos a aprender dónde están los principios. Nos referimos a los principios de los que vamos a hablar en esta sección en cuanto a los principios de la materia porque son las raíces de todos los demás principios más concretos adheridos a los que realmente estamos tratando de conformarnos con los principios de la materia. Empezaremos desde la secadora. No te repitas principio. Aprendes la definición de los olores más comunes de violar el principio seco. Después de eso, aprendiste las llaves o lo mantuviste simple. Principio estúpido. Aquí vamos a hablar de simplicidad y complejidad, complejidad accidental y esencial y cómo lograr la simplicidad. El siguiente meta principio del que vamos a hablar es el yo joven o no lo vas a necesitar principio. Está relacionado con el olor innecesario complejidad y se refiere a las anticipaciones fuera de las características comunes . Analizaremos los problemas prácticos a los que nos enfrentamos y qué otras consecuencias la implementación de características que realmente no necesitamos. Después de eso, vamos a hablar del principio de calcetín o separación de preocupaciones. Este principio subyace al incienso. Todos los principios sólidos. La separación de preocupaciones es muy importante para lograr aplicaciones bien mantenibles. Verás las formas más comunes de violar la separación de preocupaciones. Principio Comando principio de separación de consulta hace más fácil razonar sobre. En el código se discutirá el mínimo de Demeter, que es el principal conocimiento fuera de la lista. Por separado, hablaremos del principio fuera menos asombro usted. Después tocaremos el tema de la ocultación y encapsulación de la información. Por cierto, utilizaré la palabra principio en lugar de principio de materia en esta sección. Además, sólo por el bien de ahorrar algún tiempo en la próxima conferencia, aprende sobre el principio seco. Empecemos. 48. 02 DRy: esta conferencia se titula Principio Seco. Un número sustancial de caja en el software son causados por código repetitivo. Si tienes 10 funciones que hacen lo mismo, y necesitas cambiar el comportamiento de dicha función, tendrás que modificar las 10 funciones. Por lo que la definición fuera del principio seco fue formulada en un famoso libro, El programador pragmático de Andy Hunt y Dave Thomas. Y suena así. Todo conocimiento pieza fuera debe tener una sola representación inequívoca en el sistema. Este principio concierne a todos los diferentes aspectos fuera del software se puede aplicar sobre cualquier código de programación o esquemas de base de datos o cualquier otra cosa, incluyendo documentación de las formas más comunes de violar el principio seco son los siguiendo cadenas mágicas o cualquier otro valor mágico, duplicar lógica en múltiples ubicaciones y repetir dar que lógica o múltiples casos de conmutador dispersos por toda la base de código? Echemos un vistazo a ejemplos. Mira este ejemplo. No obtienes la respuesta de un dispositivo, entonces comparamos los resultados con 188. Tales valores mágicos tienden a extenderse sobre una clase que el Inter opera con el dispositivo. Así es como aparece la duplicación. Un lado de la duplicación que sabe lo que 188 significa dedo del pie entender el significado del código? Tenemos que leer la documentación. ¿ No sería bueno definir una constante con un nombre significativo? Esta constante ahora se puede usar en todas partes que necesitemos. Ahora está claro lo que significa 188. Significa que no hay conexión con el dispositivo. Aquí hay otro ejemplo. La situación similar aquí Vemos que los valores mágicos comenzaron a extenderse aparte que es absolutamente imposible entender lo que está pasando aquí. Y la ubicación del dip puede llevar a consecuencias desafortunadas. Por ejemplo, si se va a cambiar uno de los valores duplicados, entonces vas a cambiar esos valores en todas partes. Se utilizó para solucionar el problema. Podemos aplicar la misma técnica definiendo valores constantes que se convierten en las fuentes únicas fuera cambio. Definí valores constantes solo para valores duplicados, pero lo más probable es que haría lo mismo para todos los demás valores. Ahora es evidente que los comandos al principio inicializan un dispositivo que enviar un comando, y después de eso, cerró el dispositivo. Aquí te dejamos el mismo ejemplo. ¿ Qué pasa aquí? Arreglamos los números mágicos duplicados, pero lo que se puede mejorar. Además, aquí tenemos la lógica duplicada, y no es por hablar que pueden aparecer 10 nuevos métodos con el mismo patrón off mandamientos enviados . Mira cómo podemos reflejarla. Este abrigo extraigo un método que elimina la lógica duplicada quitando la responsabilidad, envolviendo comandos reales por inicialización y terminación. Los beneficios podrían no ser otros, pero en caso de que fuera más de tres métodos, los beneficios serían de esto. Este es un ejemplo sencillo de lógica duplicada. Hay caso mucho más interesante relacionado con la lógica duplicada. La pregunta es: ¿Es cierto eso? Esa lógica duplicada siempre es algo malo, y entonces, señor es bastante interesante. Imagina que desarrollas tres aplicaciones que pertenecían al mismo dominio. Lógicamente, tales aplicaciones tendrían similitudes significativas en la funcionalidad que implementan. Este hecho lleva lógicamente a un deseo natural de crear una biblioteca compartida, que contiene piezas fuera de funcionalidad. Eso es lo mismo para las tres aplicaciones. Como recuerdan, cada pieza de conocimiento debe tener una sola representación inequívoca en el sistema. Entonces si implementas el mismo conocimiento funcional tres veces quiere para cada aplicación, entonces aparentemente violas al principal seco? Sí. Ahora consideremos el siguiente caso. De mi práctica, tuvimos tres aplicaciones que compartieron la lógica de la siguiente función. Aquí tenemos una clase con tres propiedades y la función que cheques dan la tarjeta es válida desde hace algún tiempo. Esta función funcionó bien para las tres aplicaciones, pero un día cambió una de las aplicaciones. Se requiere de los requisitos para comprobar el nombre y menos nombre también. Implementar otra función para esa aplicación en particular se consideraría una violación al principio de impulsión. Por lo que se tomó la decisión de introducir una bandera de toro. Y aquí está la segunda versión de la misma función. Enfriar. Conservamos la capacidad de utilizar la misma función en toda la base de código. La paz se ha asentado y continuamos nuestro trabajo desde hace algún tiempo. Todo estaba bien hasta un día en que Boss dijo que hay otro requisito a partir de la tercera aplicación. La tercera aplicación ahora puede permitir que las ideas tengan más de 10 caracteres para preservar la capacidad de usar el mismo funcional sobre la base de código que introdujo una nueva bandera de Boland. Así es como se veía la nueva versión de esa función. Sí, sí, sé que esta función se convirtió en masa de riel, y esto es sólo el principio. Si comienzas a aplicar principios sólidos y todas las mejores prácticas para evitar esta masa, a menudo terminarás con una implementación separada para cada aplicación. A menudo no siempre. Pero a menudo es mejor no compartir tu lógica entre aplicaciones. Es mejor hacer crecer esa lógica por separado, al menos hasta que estés absolutamente seguro de que puedes fusionar las mismas implementaciones. En efecto, hay casos en los que estamos 100% seguros de que la lógica empresarial particular nunca cambiará. O la probabilidad fuera de los cambios es extremadamente baja. Si semántico es diferente, no fusionar el código, que parece código duplicado. Veamos otro caso en el que la duplicación en realidad no es una duplicación en absoluto. Aquí hay un ejemplo, por cierto, este ejemplo también es de mi propia práctica. Las preguntas simplemente se nombran de manera diferente. Tienes dos clases que fueron presidente, diferentes dispositivos. Ambos tienen las mismas propiedades de datos. Un desarrollador junior de nuestro equipo decidió que esto viola claramente el principio seco, por lo que decidió extraer las mismas propiedades de datos en vidrio basado. Salió con la versión reflejada caída de este código. Aquí está el vidrio del dispositivo, que contiene las propiedades duplicadas. Ahora todos los dispositivos heredarán del vidrio y el principio seco es Matt. Desafortunadamente, esa fue una mala decisión y hay varias razones. El primer motivo es que es difícil creer que todos los dispositivos compartan las mismas propiedades. Estoy bastante seguro de que L S P es violada por esta su fábrica. El segundo motivo es que ahora tenemos un fuerte acoplamiento entre clase basada y herederos . Y en realidad, no veo donde los beneficios de tal herencia amistosa. Es un caso muy raro cuando la herencia fuera de los datos es una buena idea. Ya sabes, todos los idiomas, los objetos se componen de funciones públicas. Deberían ocultarse los datos. El tercer motivo es que la primera intención estaba equivocada. No hubo duplicación alguna. El hecho de que los objetos toe tengan las mismas propiedades de datos no los hace similares. Lo que hace similar al objeto es su comportamiento. Por lo que no hay necesidad de emparejar objetos que tienen diferentes semánticos. Vladimir Horcoff incluso salió con la noción de herencia de utilidad. Vladimir Horcoff, hay uber fuera de este video curso incluso salió con la noción de herencia de utilidad, este ejemplo demuestra exactamente esa mala técnica. En la diapositiva, se puede ver la referencia al bloque bossed sobre la herencia de utilidades. Echa un vistazo a este código aquí tiene una enumeración fuera de las formas y la clase Visualize ER, que define las operaciones del dedo del pie. Sólo hay dos operaciones solo por el bien de la simplicidad. En el escenario del mundo real, habría muchas clases que usaban eso en, um, um, oraciones y docenas de métodos apagados llenados por casos de cambio. Entonces, qué casos sobre el mismo en admiración, que están dispersos por toda la base de código, es una de las peores pesadillas. Se puede la vida mayor cuando algún tipo de aspecto de comportamiento cambia respecto a una de las enumeraciones de Alice. Tienes que encontrar todos los lugares del sistema donde se implementan los casos de interruptores y cambiar los fragmentos de código correspondientes. Si agregas una forma, tienes que encontrar todos los lugares con cajas de cambio y modificarlas, agregando cajas para esa nueva forma. Esta es una verdadera duplicación maligna. Cómo solucionar el problema. El principio de cierre abierto es la respuesta. Se puede definir el cristal base y convertir los valores de enumeración en herederos representados por clases. Si algo cambia, tienes un solo lugar donde necesitas hacer ese cambio. Ahora el código del cliente sólo puede confiar en el cristal de forma base. No hay cajas de interruptores dispersas por toda la base de código. Recuerda que la repetición y la lógica exigen abstracción. Genial. En la próxima conferencia, estudiaremos el principio del beso. 49. KisS: esta conferencia se titula Principio del beso. ¿ Has escuchado la declaración de Albert Einstein? Haz que todo sea lo más simple posible, pero no más simple. Esta afirmación es la esencia del principio del beso. Beso significa mantenerlo simple, Estúpido. Cuanto más complejo de sistemas, más posibilidad de que pueda romperse. Por lo tanto, simplicidad debe ser un objetivo clave en el diseño y en la complejidad del evaluador se debe evitar mientras yo joven no lo vas a necesitar. Principio se trata de quitar un beso de abrigo asesor se trata de cómo hacer la implementación lo más simple posible. Entonces la afirmación de este principio es una solución simple es mejor que una compleja aunque la solución parezca estúpida, el principio es profundamente filosófico en efecto, sólo tratando de llegar a una definición verdadera fuera de la sencillez, cómo definir y medir la simplicidad la definición directa sería la siguiente simplemente ciudades el estado de calidad de ser simple. ¿ No te parece que tal definición no te sirvió? Yo sí. ¿ Qué significa ser simple? Aparentemente que la única manera en que podemos tratar la simplicidad en el software es que algo que es fácil de entender o explicar, Puede ser considerado simple. En contraste con algo complicado. Es muy duro y a veces incluso imposible llegar a una solución simple que resuelva un problema difícil. La complejidad fuera de la implementación tiende a crecer junto con el creciente número de fuera de los requisitos , por lo que el sentimiento fuera de la sencillez es relativo. La técnica principal que utilizamos para luchar con la complejidad es la descomposición, y por cierto, la composición es el aspecto, que está fuertemente relacionado dedo del pie casi todos los principios sólidos. Adhiriéndonos al SRP, aplicamos la composición a los objetos o módulos acoplados, confirmando con la chismosa no siempre sino que a menudo implica también la composición, sobre todo cuando necesitamos crear un nuevo tipo de dedo fuente aislada de cambio en la segregación facial. Principio es todo sobre la composición. dependencia en la versión se trata de hacer que el mundo del sistema sea demasiado compuesto. El listado de principio de sustitución es mayormente sobre cómo evitar la descomposición de apuestas así del alma. Los principios están dirigidos a lograr soluciones lo más simples posible. Por otro lado, abusar de principios sólidos siempre conducen a la complejidad de los accesorios. Esta es la verdadera manifestación de la unidad y lucha contra la ley opuesta. Se asemeja a mí, una hierba llamada valor. Aaron Valerie en tiene cualidades sedantes, Así que cuando tomas el Lear en medicina Aceh, esperas ser más tranquilo al mismo tiempo. Es un hecho muy conocido que si te quitas demasiado mientras estás dentro, causará la sensación de ansiedad. El hecho será lo contrario. El problema fuera sencillez relativa nous nos lleva a dos nociones relacionadas. Complejidad accidental y esencial. Dije antes que los sistemas complejos son en realidad complejos y no se puede hacer nada al respecto . No se puede implementar el software del sistema bancario y esperar que sea un simple como solitario. A la complejidad impuesta por el propio dominio se le llama la complejidad esencial. La complejidad esencial no puede reducirse de ningún modo. El único modo en que se reduce la complejidad esencial es cuando las reglas de dominio cambian en la dirección de la simplicidad. Desafortunadamente, apenas se puede hacer cumplir este tipo de cambios. complejidad accidental es la complejidad fuera de nuestras soluciones, las cuales están destinadas a resolver los problemas fuera del dominio del que somos responsables. La complejidad accidental son los desarrolladores. El diseño de la optimización del software están todos relacionados con la complejidad accidental. El beso es principio filosófico fundamental, por lo que podemos marcar las siguientes reglas, que por supuesto, no son dogmas. Prefiero la composición por encima de la herencia eran posibles. Sigue con si Ellison, que dio declaraciones hasta que veas que necesitas introducir polimorfismo, evita llevar a la optimización en el 90% de los casos. Las soluciones más lentas funcionan lo suficientemente rápido Excepciones de esta regla es cuando sabes con certeza que estás trabajando en un software muy complejo, uno de los principales aspectos de los deseos. El desempeño cuando el desempeño es absolutamente crítico. Los vasos más pequeños y los métodos más pequeños son la mezcla. El mejor método es un liner de un solo, Google. Para la técnica, que se llama extractiva te caigas, que se trata de métodos re factoring. No se apresure a extraer clases de utilidad para métodos privados que se utilizan de un solo lugar dentro de la clase. Deja s ciudades hasta que haya otras partes de código. Se requerirá ese método también. No escribas perimetral arizado. Los métodos generales prefieren métodos que resuelvan un problema específico. Divide y conquista. Este es un principal dirigido a resolver problemas complejos. Divida el problema en problemas más pequeños y resolverlos uno por uno. Esfuérzate por evitar comentarios. Comentarios significan que fallaste al intentar expresar la intención en el lenguaje de programación, tipos de hermanos correctos, Y no tengas miedo de tirarlos a la basura. Mantener el número de fantasías que resuelven un problema aproximadamente de 5 a 7 humanos. La mente no es buena para guardar en la memoria. Modernas siete cosas simultáneamente, Trabajando constantemente. Simplificando tu base de código. El tío Bob Martin incluso sugiere una regla que antes de hacer un check in, siempre debes preguntarte si el código base es mejor de lo que era antes registrarlo. Esta es la regla de un Boy Scout. optimización es la principal excusa para escribir código complejo, pero se esfuerzan por mantener la cantidad de dicho oro más cerca del cinco o 10% de la base del código, no más. Optimiza solo si estás absolutamente seguro de que hay un problema de rendimiento. No midas el rendimiento por tu confío en herramientas especiales para el seguimiento del rendimiento . Recuerda que hay dos valores fuera del software. El 1er 1 es que el software debe funcionar correctamente, y el 2do 1 es que el software debe diseñarse bien, y el 2do 1 es mucho más difícil de lograrlos. El 1er 1 en la mayoría de los casos. El siguiente principal del que vamos a hablar es el principio joven, que significa u N Va a necesitar Este principio es similar al principio de beso. En la siguiente conferencia, ¿cuál es la diferencia entre estos dos principios y lo que significa Yogi en la práctica? 50. 04 YAGNI: esta conferencia se titula Principio Yardeni. El pueblo del Poder siempre está buscando maneras de hacer que todo a su alrededor sea tan poderoso. Es posible que los desarrolladores también sean personas, y también tienden a hacer que todo el código del programa sea tan general como pueda ser. Por ejemplo, cuando un desarrollador de software tiene la tarea de crear una biblioteca simple para generar informes simples de resultados de ingresos, permitirá que toda la biblioteca de propósito general genere cualquier posible reporte financiero . Necesito analizar un par de valor clave de un personalizado comprando un reformador. ¿ Qué estoy haciendo? Correcto. Estoy escribiendo todo el maldito sparser con manejar todos los casos posibles. Sí, Agni significa que no vas a necesitar todo se trata de evitar sobre ingeniería, él Agnese fuertemente relacionado con lo que discutimos anteriormente en el curso. ¿ Recuerdas el olor llamado Complejidad Innecesaria? Sí, Detail dice que debemos evitar este olor. ¿ Te acuerdas de nuestra charla sobre anticipación de los próximos cambios? Anticipando los próximos cambios, los desarrolladores comienzan a introducir puntos de extensión. El problema es que podría suceder que nunca se utilicen todos esos puntos de extensión. Los puntos de extensión tienen su costo. No son libres. Hacen que los sistemas sean más complejos y por lo tanto más difíciles de entender. Sí, Guineas. Principio profundamente filosófico. No existe un criterio bien definido, que permita medir la pulcritud joven del sistema. Si miras Wikipedia, verás que Young es un principal fuera de la programación extrema, o XP. En resumen, eso establece que los programadores no deben agregar funcionalidad hasta que se considere necesario. Al ser un tipo de desarrollo de software federal, programación extrema aboga por liberaciones frecuentes ciclos de desarrollo asegurados, que se pretende mejorar la productividad e introducir puntos de control en los que se puedan adoptar nuevos requisitos de los clientes . XP, cofundador de Jeffries, ha escrito. Siempre implementa las cosas cuando realmente las necesitas. Nunca. Cuando solo para ver que los necesitas, tienes rodillas. El principio detrás de la práctica de XP off hace lo más simple que posiblemente podría funcionar. Otro concepto interesante, que también está fuertemente relacionado con Young Me se llama Peor is Better. También conocido su estilo de Nueva Jersey respecto al desarrollo de software. Peor es mejor implica un modelo de diseño e implementación de software, que tiene las siguientes características. Simplemente sentado, el diseño debe ser simple, tanto una implementación como una interfaz. Es más importante que la implementación sea simple que la interfaz. simplicidad es la consideración más importante en la corrección del diseño. El diseño debe ser correcto en todos los aspectos observables, pero es ligeramente mejor ser simple que correcto. La consistencia que diseñan no debe ser excesivamente inconsistente. La consistencia se puede sacrificar por simplicidad en algunos casos, pero es mejor dejar de lado aquellas partes del diseño que tratan con circunstancias menos comunes que introducir complejidad o inconsistencia e integridad de implementación. El diseño debe cubrir tantas situaciones importantes como sea práctico. Deberían cubrirse todos los casos razonablemente esperados. La integridad se puede sacrificar a favor de cualquier otra calidad. De hecho, la integridad debe sacrificarse siempre que las simplicidades de implementación. Joe pard ized consistencia se puede sacrificar para lograr la integridad si se conservan simplicidades , especialmente sin valor es consistencia fuera de interfaz. Hay un problema con todos los principios de la materia. El desperdicio que podemos seguirlos y aplicarlos en la práctica son vagos. Lo único que podemos hacer es discutir el nombre joven o detalles. Pero al final, nuestra discusión también contendrá cosas tan difíciles de medir como la complejidad del software. Por ejemplo, considere la siguiente frase de un bloque apagado. Siguió Martin. Esta es una buena frase, que deja claro el significado fuera. Sí, Agni, pero aún no es tan fácil aplicar en la práctica. Aquí está la sentencia. Si haces algo por una necesidad futura que en realidad no aumente la complejidad del software, entonces no hay razón para invocar tu acné. Pero la complejidad del software, surge la pregunta. ¿ Cómo diablos voy a estimar el complejo nous antes de mirar un par de ejemplos de jugar? El principio también quiere quedarse que no debes apegarte a ningún principio ciegamente. Por ejemplo, si te apegas ciegamente al yo joven, terminarás con estos fríos organizados y enfrentarás tarde o temprano la necesidad de realizar un trabajo masivo. Por lo que hay que confiar fuertemente en varias otras prácticas, como continúa para factoring, continúa las pruebas unitarias automatizadas y continúa la integración para evitar consecuencias negativas. El Agni depende de las prácticas de apoyo, y esto se afirma en la definición original. En programación extrema. Consideremos dos casos en los que podemos aplicar. Sí, Agni, llamaré al primer caso de alto nivel uno. En el segundo caso, llamaré a un nivel bajo. Imagínese la situación que un equipo está trabajando en el sistema de pago, que el Inter opera con muchos dispositivos, como van dispensadores, Bilic, zapadores y así sucesivamente. Puede haber muchos modelos fuera de cualquier tipo de esos dispositivos. Trabajando en una versión actual, es necesario implementar un controlador para Inter operando con modelos e off a dispensador de facturas. Al mismo tiempo, un gerente de proyecto espera que en cuatro meses necesiten apoyar el modelo Y fuera de un dispensador de facturas. Es una tentación implementar ese modelo esperado en paralelo con el modelo Z, para evitar el cambio de tareas en el futuro. Y por cierto, sería genial decirle a Boston el futuro. Oye, lo anotaremos cuando llegue el momento de implementar el modelo blanco. Decidir implementar tales características presuntivas es una violación clásica fuera del principio Agni . ¿ Te das cuenta del posible desperdicio financiero en el caso de que nunca se necesitará móvil para ser implementado? El costo de Butte se comprende de todos los esfuerzos que se gastan en analizar la programación y probar esta característica ahora inútil. De acuerdo, imagina que el gerente del proyecto tenía razón sobre esa característica. ¿ Crees que no hay costo de tal decisión? El caso es que implementar esa característica esperada que todavía Tiempo, que podría ser gastado en otras características realmente necesarias. Se trata de un retraso en el costo de descuento, ya que otras características se retrasarán. El retraso será igual al tiempo dedicado a implementar esa característica esperada. Y esto no quiere decir que inicialmente podrías estar equivocado, y esa característica nunca podría ser necesaria. Y esto no es entonces, y otros costos de implementación de características se anticipaban estar en demanda en el futuro mediante el uso de una bola de cristal para adivinar la fortuna. ¿ Está la costa frente a Clery? Muy a menudo, código adicional dificulta la comprensión, mantenimiento y modificación del sistema . Entonces, si también necesitas implementar una característica realmente necesaria, que depende de ese frío relacionado con los dispositivos, es probable que pases más tiempo para implementarla. Y esto no lo es Entonces hay un escenario muy desafortunado cuando la necesidad fuera de una característica se pronostica correctamente. Pero la implementación del futuro está equivocada. Cuando llegan los tiempos y te das cuenta de que se implementa una característica, no nosotros esperamos por los clientes. Te enfrentarás en una situación en la que tienes una característica equivocada, a veces completamente equivocada, y tienes que tomar una dura decisión sobre si tirar a la basura la implementación actual y er implementar la característica completamente desde el tierra o invertir recursos en la reparación de la implementación incorrecta existente. Este es un dilema muy duro. Es difícil estimar si debe reescribir la característica o reparar la existente . Martin padre se le ocurrió una gran piel, lo que demuestra todos los problemas potenciales relacionados con la joven violación. El ejemplo que discutimos es el caso de alto nivel y tú, Agnese mucho más simple de aplicar en este nivel, aunque, por supuesto, incluso en este nivel, a veces cometemos errores. Otro caso es de bajo nivel y se refiere a las elecciones diarias que tomamos en el proceso de codificación. Por ejemplo, imagina que en este momento estás escribiendo una función dentro de una clase la cual necesita analizar un número de una cadena personalizada recuperada de una tarjeta de plástico. Básicamente tienes dos opciones. Una es simplemente implementar una función separada que pase esa cadena dentro de esa clase estás trabajando en este momento. La segunda opción y esta es la forma que fue por defecto muy a menudo es implementar una función de paso y extraer la clase de utilidad que contiene la función de paso Esto suena lógico. Parece que podemos anticipar que nuestros colegas también podrían querer usar la característica fuera del análisis de otras partes de la base de código. No quiero contestar esta pregunta en relación a este caso en particular. Yo quiero contestar la pregunta. Generalmente, existe un algoritmo simple que ayuda a tomar una decisión correcta en el proceso de codificación y en tales situaciones. En primer lugar, pregúntate si se necesita la función o un futuro para ser implementado en este momento. Eventos fueron sí, luego implementado, tienes La respuesta es no. Hágase otra pregunta. ¿ Cuántos esfuerzos se necesitarán para implementar esa función o una característica en el futuro? En el caso, se requerirá. Si la respuesta es, definitivamente será muy simple. Entonces mantén todas las cosas como están. No introduzcas nada adicional. Si la respuesta es, tomará una enorme cantidad de tiempo escribir muchas cosas para modificar el diseño para que sea lo suficientemente flexible como para introducir esa característica. Entonces considera realizar fracciones de verano, que permitan evitar escrituras masivas en el futuro. Recuerde que ni las prácticas gile ni ningún principio de materia impusieron la idea para evitar planeación. Por el contrario, siempre debes planificar cuidadosamente lo que necesitarás en el futuro. ¿ Y qué recursos y esfuerzos tomará de usted para volver a cumplir con los nuevos requisitos? No quiere decir que tengas que realizar un gran arriba desde el diseño, pero sí lo debe. No quiere decir que tengas que olvidarte de mucho. El objetivo que queremos lograr aplicando ya Agni es ahorrar tiempo. Por favor, no postules. Joven me para re fábrica. Es necesario realizar una fábrica para habilitar a Yanni. Espero que ahora entiendas mejor cómo lograr el Santo Grial con el algoritmo que presenté en esta conferencia. Estén listos para fallar. Aplicando el principio Agni, tomará algún tiempo obtener suficiente experiencia e inventar. Tu perseverancia dará sus frutos en la próxima conferencia. Echaremos un vistazo al principio de separación de preocupaciones. 51. 05 SoC: Esta conferencia se titula Separación de Preocupaciones. Separación de Preocupaciones o un Calcetín y Corto es un principio que en realidad se discutieron en la sección off Principio de responsabilidad única SRP en el futbol fuertemente relacionado. Básicamente, fútbol es un principio, lo que significa que tenemos que separar diferentes preocupaciones en diferentes módulos. Adherirse al calcetín permite construir sistemas modulares. La diferencia entre el futbol y el SRP es que el futbol se aplica mayoritariamente al más alto nivel . El valor de la separación de preocupaciones es simplificar el desarrollo y mantenimiento de programas informáticos . Cuando las preocupaciones están bien separadas, las secciones individuales pueden ser reutilizadas, así como desarrolladas y actualizadas de forma independiente. Un valor especial es la capacidad de mejorar o modificar posteriormente una sección de código sin tener que conocer los detalles fuera de otras secciones y sin tener que hacer un cambio de respuesta a esas secciones. La mayoría de las veces, puedes tratar SRP y calcetín como los mismos conceptos, y puedes usarlos indistintamente. Aquí está la lista de preocupaciones que a menudo debemos enfrentar en el desarrollo de software empresarial. Eres lógica empresarial, presentación, presentación, lógica y base de datos. Imagina una habitación donde todas las cosas estén dispersas por todo el piso será simple. Para encontrar allí un libro en particular. ¿ No sería más fácil mantener todas las cosas libros separados en el estante, juguetes en las cajas y demás? Lo mismo podemos decir de la programación y separación de preocupaciones. Si entras enreda te. Yo era lógica de negocios. Entonces será más difícil para ti mantener toda la masa, encontrar cualquier cosa que necesites, su cambio, cualquier cosa que necesites cambiar y así sucesivamente. Hay algo que puede arruinar nuestras mejores intenciones respecto a la separación de preocupaciones. A esta cosa desagradable se le llama lamer abstracciones con preocupaciones separadas. Al jugar la constante off encapsulación Onley por encapsulación, podemos proteger objetos y ocultar sus internos. Desafortunadamente, abstracción aguanta a la fuga, sobre todo en ojos AP complejos. Hay un gran número de casos populares fuera de lamer abstracciones. Uno de mi ejemplo favorito. Uno de tu modelo o, en otras palabras, lógica de presentación conoce algo específico para ti. Yo aquí hay un ejemplo cuando un modelo de vista expone una propiedad de tipo collar, este es un ejemplo clásico cuando la lógica de presentación se implementa incorrectamente desde el punto de vista del calcetín . Para arreglar este ejemplo, necesitamos quitar la propiedad y exponer otra que solo devuelve un bowline que estás su lado debe decidir de qué color pico. Esto no es una preocupación fuera de una capa presentacional. Otro buen ejemplo. Cuando la lógica principal opera con identificadores únicos almacenados en una base de datos. En tal caso, una preocupación de persistencia se mezcla con la lógica de dominio. La lógica de dominio debe ser agnóstica respecto a cualquier mecanismo de persistencia, realidad ahí en apaga ejemplos de abstracciones de parpadeo. Tenga en cuenta que las capas, que representan preocupaciones diferentes, deben aislarse unas de otras de tal manera que ninguna de ellas debe conocer de ningún detalle intrínseco de la otra parte. Debo admitir que puede haber excepciones a esta regla desde la perspectiva del diseñador de Domine Dreamin Didi Dean camisa procedimientos de inicio de escritura, que implementan cualquier tipo de lógica empresarial. Por ejemplo, realizan validación y la mutación de datos se considera una violación de separación de preocupaciones. Principal Al mismo tiempo, desafortunadamente, desafortunadamente, corriendo directamente, los procedimientos quirúrgicos son mucho más rápidos en ciertos escenarios que realizar operaciones a través de un objeto. Mapeador relacional como marco de entidad, tratar tales casos como excepciones. En la siguiente conferencia, aprenderás el principio de separación de consulta enfermas de EU o de comando 52. 06 CQS: Esta conferencia se titula Comando Query Separation Comando. La separación de consultas es un principal fuera de la programación imperativa. Fue ideado por un pero admirar como parte de su trabajo pionero en el lenguaje de programación Eiffel . Establece que todo método debe ser un comando que se realice en acción o una consulta que devuelva datos al enfriador, pero no ambos. Es decir, hacer una pregunta no debe cambiar la respuesta. Generalmente, podemos dividir funciones en dos tipos principales. Funciones que realizan comandos y funciones, que realizan una consulta y devuelven un resultado. A menudo los principiantes mezclan cuadrados y comandos. En consecuencia, crean funciones que realizan un comando y devuelven un resultado de adquirir. Al mismo tiempo. Esto casi siempre es algo malo. Considera un ejemplo. ¿ De qué color se pregunta aquí? ¿ Fue exitoso el intento Logan? Tal vez true significa que un usuario ya ha sido bloqueado. Es difícil de decir mirando la firma de la función. El caso es que es imposible expresar el significado de un resultado boudin por el nombre de las funciones. El problema no está en el mal nombre de la función, pero el problema es que un comando no está separado de una consulta. La lógica de comandos y la lógica queer se mezclan en la misma función. Tan enfermo. Estados Unidos es uno de los principios fundamentales que ayudaron a diseñar mejores ojos AP con respecto a este ejemplo. Sería mejor desplegar una función que implemente un comando y una o más funciones que implementen consultas por ejemplo, como esta por los nombres y firmas de estas funciones. Está claro lo que significan y lo que hacen. En otras palabras, estas funciones son honestas de que no implican algo oculto y no mienten a una persona que llama. En la próxima conferencia, veremos la ley fuera del metro decano. 53. Ley de Demeter: esta conferencia se titula Ley Off de Meter. Si miramos a Wikipedia, veremos que la ley fuera del medidor, Señor en breve o principal conocimiento fuera de lista es una guía de diseño para desarrollar software , particularmente programas orientados a objetos. En su forma general, el Señor es un caso específico fuera de acoplamiento suelto. Está bien, suena genial. Pero, ¿qué significa realmente? Formulación general del bajo es que cada unidad debe tener un conocimiento limitado sobre otras unidades. Las unidades Onley estrechamente relacionadas con la unidad actual o cada unidad solo deben hablar con sus amigos. No hables con extraños. Gran Suena claro, pero aún no lo suficientemente práctico. Se puede resumir la forma objeto formal de la ley. Esto un método a menudo objeto solo puede llamar a métodos fuera del propio objeto. Un argumento fuera del método, cualquier objeto creado dentro del método y cualquier propiedad directa o campos del objeto. Ah, por fin, el significado práctico se vuelve claro. Además, todos estos lineamientos al final llegaron a la siguiente declaración simple. No hables con extraños. utiliza otra fórmula sencilla de esta ley. Sólo un doc. De acuerdo, entonces vamos a ver su un ejemplo práctico, que fue sugerido hace mucho tiempo por David Bach. Es una gran ilustración del problema. Considera el siguiente caso. Fingamos que debemos motilar las relaciones comerciales entre un chico de papel y el cliente que quiere comprar revistas. Un chico de papel toca el timbre, el cliente lo abre. A un chico de papel de alguna manera se le tiene que pagar y luego entregar una revista al cliente. Echemos un vistazo al código. Ejemplo. ¿ Qué modelos? El caso aquí es una clase de cliente simple, cual tiene nombres y apellidos, y además tiene una cartera tipo wallet off. Aquí puedes ver la clase de billetera. Es extremadamente sencillo. Simplemente almacena el valor decimal, que determina la cantidad de dinero en la cartera. El cliente fuera de la billetera. AP. Puedo agregar dinero a la billetera, puedo retirar dinero y comprobar la cantidad actual de dinero. Se ve bien y sencillo. Es solo que la violencia debe alimentar nuestras necesidades. El último es implementar la lógica fuera de un papel, pero echemos un vistazo por dentro. En la clase de cartón se expone un único método Entregar revista, que toma el costo de la revista y del cliente al que tiene que entregar un papelero. Se ve muy bien la revista. Echemos un vistazo al documento de implementación. Boi solo quita la billetera a un cliente y luego comprueba la cantidad de dinero si hay suficiente dinero que el papelero simplemente toma, necesitaban algo. De lo contrario un chico de papel simplemente se va. Genial. Bueno, yo diría, ¿Qué opinas? ¿ Es realmente genial? Si piensas un poco más profundo, entonces puedes salir con la idea de que hay algo extraño en el hecho de que el chico del papel le quita la billetera a un cliente con el fin de que le paguen un chico de papel tiene acceso a clientes Mundo. Qué tontería. ¿ Sería tan amable de darle a su billetera dedo del pie papeles desconocidos? Dudo así en este caso, la violación a la ley de D necesita un reservista. El chico de papel opera con un agua a través de un cliente. El primer punto aquí en el código es cuando un chico de papel toma el mundo. Entonces hay una segunda hija Cuando comprueba la cantidad de dinero en el mundo el mismo caso cuando un papelero retira algo de dinero para describir el problema o en serio, debo decir que el principal problema con este diseño es que los chicos de papel que están expuestos más información de la que necesita ser. Todos los problemas son las consecuencias de este hecho. Por lo que ahora estas tres clases están fuertemente acopladas. Si cambiamos la clase mundial, cuando tengo que hacer cambios a ambas fuera de las otras clases, por cierto, si una billetera es ahora que el chico de papel lanzará la excepción de referencia inferior, así podría ser que en el mundo real basado en código el chico de papel tendrá que lidiar con ello, introduciendo ahora cheques y la segunda secuencia que abarrota el código. Entonces, ¿cómo solucionar el problema con el fin de solucionar el problema? Debilitar Simplemente motile el escenario del mundo real. Cuando el chico del papel entrega una revista, sólo pide un pago. Echemos un vistazo al diseño mejorado. Ahora. En la clase de cliente se expone el método público llamado Get Payment. En tanto que el objeto de cartera subyacente ahora está contenido en un campo privado. Nadie excepto el cliente tiene acceso a su billetera. El chico de papel ahora está forzado dedo del pie. Pide al cliente que obtenga el pago. Paperboy no no tiene los derechos. Y, por cierto, la responsabilidad, como en el diseño anterior, colmar en la cartera del cliente por lo que el diseño mejorado es mejor de tres maneras. Modela mejor el escenario del mundo real. El código Paper Boy ahora está pidiendo al cliente un pago. El chico de papel no tiene acceso directo a la billetera. Segundo, el papel que ahora puede cambiar la clase. Y los chicos de papel completamente aislados del cambio y el tercero ahora estaban libres para cambiar la implementación del método de pago get. De acuerdo, volvamos a las diapositivas. Para resumir, quiero decir que la regla sobre el número de puntos a veces puede ser engañosa. El caso es que la ley fuera del medidor no se trata del número de puntos. Esta ley trata de reducir el acoplamiento y probar la encapsulación. Cuando estamos hablando de estructuras de datos como estructuras de datos, que están expuestas por el documento de Excel, está perfectamente bien cuando es un P. Te permite cavar la estructura del documento como este documento de Excel que ella no celular y así sucesivamente. Lo mismo se puede aplicar a los ojos AP fluidos. Cuando cada objetivo devuelve un objeto para que puedas construir cadenas de métodos, por lo que siempre es no tratar las reglas como dogmas y tratar de entender el significado subyacente de la habitación. En lugar de aplicar reglas ciegamente en la próxima conferencia, vamos a aprender el principal fuera menos asombro. 54. 08 PoLA: esta conferencia se titula Principal Off Menos Aasombro y otro Principio básico, sobre el cual se levantará un gran número de Padre Príncipe es el principal fuera menos asombro. Este principio establece que un componente fuera de un sistema debe comportarse de una manera consistente con la forma en que probablemente se espera que los usuarios fuera de ese componente se comporten. Los siguientes principios y técnicas se basan en el principio de asombro fuera de la lista. Y, por supuesto, ayudan a conformarse con este principio. Caja fuerte completa. A p comando la separación de consultas en mutabilidad diseñada por contrato y ahora la prevención y muchos otros. Mira el siguiente ejemplo. Contamos con una clase de reportaje con dos métodos trae reporte a e imprimir reporte. Ser y este fragmento de código funciona bien. Pero si un cliente cambia la secuencia de esta llama como esta un error de conexión a base de tuyo. El caso es que una conexión de base de datos se abre al inicio del traer a Reppert un método y se cierra al final de la impresión Reppert ser método. Este es un ejemplo sencillo, que tiene un fuerte olor a acoplamiento temporal donde la raíz provoca el efecto secundario que se oculta al cliente haciendo lo muy asombroso desde el punto de vista del cliente. manera humorística, podemos concluir que la métrica que refleja el factor fuera de asombro muchas veces FBI es el número fuera gritado WTF está permitido. pocas palabras, el principal asombro fuera de la lista significa que un diseño debe tanto grandes expectativas cumplir con esas expectativas. Debería hacer más o menos lo que la gente esperaba hacer. Otro ejemplo de un ocho b I, que asombra a sus clientes, es el tipo sobre la pila estándar de Java. Implementación de pila estándar en Java expuso métodos Bush y pop, y además, expone el método de anuncio heredado de la clase vectorial God's sake. De qué se supone que tiene que hacer la ed matemática donde se va a agregar el ítem. Es absolutamente asombroso. Yo era casi grande cuando me enfrenté al día por primera vez. Aquí te dejamos un ejemplo de la tienda del mar. Un usuario esperaría de la al menos que permita dedo del pie agregar elementos. Desafortunadamente, incluso el sistema tipo Sea shops no es ideal en este caso. No están apoyados. Excepcional el trono. En la siguiente conferencia, aprende cuál es la información escondida y encapsulación, y cuál es la diferencia entre ellos 55. Encapsulación 09: Esta conferencia se titula Ocultación y Encapsulación de la Información. Si miramos a Wikipedia, veremos la siguiente definición fuera de la información Ocultar en informática Información Ocultar es el principio de segregación fuera de las decisiones de diseño en un programa informático que es más probable que cambien, protegiendo así a otras partes del programa de modificaciones extensas. Si la decisión de diseño ha cambiado, la protección implica proporcionar una interfaz estable que proteja el resto del programa de la implementación. El detalle que más les gusta cambiar escrito de otra manera. Ocultar información es la capacidad de evitar que ciertos aspectos de una clase o componente de software sean accesibles para sus clientes. uso de cualquiera de las fisuras del lenguaje de programación como variables privadas era una política de exportación explícita . Estoy de acuerdo con esta definición, y después de aprender los principios sólidos, está absolutamente claro que la información oculta subyace a todos los principios sólidos. Siempre nos esforzamos por ocultar esa información, que es irrelevante para los clientes. Cuando un cliente ve lo que no necesita, hace más difícil entender un p I. Una de las preguntas más populares que se pueden escuchar en las entrevistas es explicar la diferencia entre la ocultación de información y la encapsulación, un gran número de personas confundió estas nociones. Existe la opinión popular de que estos términos son los mismos. No estoy de acuerdo con esta afirmación de que la ocultación de información es la encapsulación de Samos. Y aquí está el porqué. En primer lugar, trate de mirar hacia atrás y responder a la siguiente pregunta. ¿ Construye sus aplicaciones encima de los componentes reutilizables? Seguro en 100% que respondiste. Sí, sí lo hago. Por supuesto que sí. Si programas en el trabajo O C. Sharp que tus aplicaciones, al menos ponte encima de todo un maldito marco. Y la siguiente pregunta es, ¿se encuentra leyendo el código fuente de esos componentes reutilizables? Si está disponible de forma regular y lo más probable es que la respuesta no lo hagas de vez en cuando. Necesitamos leer el código fuente de BCL, por ejemplo. Pero ese es un caso raro. Esto se debe a que esos componentes están encapsulados. Permitieron usarlos sin cavar sus internos. No necesitamos dedo del pie. Entender la cocina fuera de los componentes reutilizables para usarlos. Esto es lo que es la encapsulación. La encapsulación permite reutilizar componentes sin comprender su implementación interna . Mira el ejemplo de una clase mal encapsulada aquí una burla. Podría parecer que este es un ejemplo de silicio, pero he visto mucho fuera de tal base de oro. Por supuesto, este es el peor de los casos, pero incluso un AP recordar implementado mal puede llevar a graves consecuencias desafortunadas. ¿ Qué tiene de malo esto? A. P Veo el ritmo vendedor y método. ¿ Por qué devuelve un valor de cadena? ¿ Es el código de respuesta? ¿ Es un cliente que D devuelvo? ¿ Quién diablos podría saber qué puede ser encapsulado por el valor de cadena? Toma la montaña representada por arroyo. ¿ Qué se espera aquí? ¿ Un decimal o caminar? Tal vez un entero busque más allá, pero obtienen devoluciones de método del cliente Evite entender cómo regresa este método, un cliente un cliente de la seguridad tiene que saber sobre el evento recibido por el cliente y el último eliminar método del cliente. Devuelve un entero de nuevo. Cualquier cosa puede representado por un valor entero. En tal caso, he visto una vez cómo un programador de C usó enteros para devolver boletines sus unos y ceros en la tienda C. Sí, he visto incluso una basura tan aterradora ver cómo podría verse este código. Aquí está el salario base, que devuelve nulo y acepta decimal. Todo es comprensible. Ahora es un comando que acepta el valor del dinero en decimal. Otra opción es devolver un momento de resultado, que está fuera del alcance de este curso. Si estás interesado en construir ojos AP robustos respecto a errores con el momento de resultado de uso considerado para tomar mi curso A B y C shop, las mejores prácticas de diseño e implementación en ti. Para mí, otro método get customer ahora devuelve un cliente. Todo está bastante claro. Otra opción es regresar y tal vez fuera de cliente quizá también se llame así Mona, que está fuera del alcance de este curso. Y si te interesa construir robots, chicos de cinta respecto ahorita con el uso del momento tal vez considerado para tomar mi curso una tienda PNC , las mejores prácticas de diseño e implementación en ti lo atenuan para el cliente eliminado puede ya sea volver nulo o un resultado. Utilizamos un momento de resultado para afirmar explícitamente en una firma que la operación que fallan si regresa evitar significa que la operación es exitosa siempre. Este es un ejemplo de un buen claro, p I. La intención fuera de encapsulación es proteger el in variance haciendo imposible los estados inválidos comando Quitter. El principio de separación es uno de los principios más importantes relacionados con la encapsulación. Y luego quiero bromear que siempre debes recordar que debes escribir código para que el lector de tu código sea un asesinato en masa psicópata. ¿ Quién conoce la dirección de tu domicilio? Duerme bien, mi querido estudiante. 56. 10 API: ¿ Qué es un P I, en esencia, un p I es una funcionalidad de set off. En términos generales, se puede enviar como una biblioteca completa. O puede ser simplemente una clase. Todo programador produce un premio de una forma u otra. Buena programación es modular. Lo que intrínsecamente significa que esos límites modulares son ojos AP por sí mismos. buenos ojos AP tienden a reutilizarse. Pueden convertirse en un gran activo. Por el contrario, mal un premio se convierten en pasivos. Son unos lindos ojos CP. Hay ojos AP desagradables, pero no hay FBI perfectos. Definitivamente el perfecto Un pastel es algo en un realista. Si desarrollas una clase para uso interno dentro de una empresa, desarrollas una privada A buy para los otros desarrolladores dentro de tu empresa, este tipo off ambiente en el que las hojas frías marcan semen llama zoológico si desarrollas una clase para el público. Se trata de un FBI público, que puede ser utilizado potencialmente por millones de desarrolladores vendidos en todo el mundo, que este tipo de ambiente en el que el código deja marca semen llama desierto. Estos dos casos mayores son diferentes, pero cuánto son diferentes. Consideraremos un poco después de la introducción. Por cierto, puedes leer un gran artículo sobre guardabosques y zookeepers de Mark Semen siguiendo el enlace que he adjuntado. En primer lugar, sería muy bonito definir características fuera de un buen p I. Marcaremos las siguientes características. Simplicidad, expresividad y compromisos, extensible y consistencia. Ahora vamos a profundizar en las características fuera de los ojos AP. La primera simplicidad característica se puede describir a través de la bien conocida regla referente a un desarrollo de pasteles que siempre se puede agregar pero nunca quitar. Esto significa que si hay muchos usuarios fuera de tu a p I, no puedes quitar funcionalidad que ya usan. Por eso desarrollar tu P I. Siempre es preferible posponer funciones cuestionables en lugar de incluirlas en la versión actual fuera de curso. El enunciado anterior es también sobre AP Ivor Shani, pero lo consideramos en el contexto fuera encontrar el equilibrio entre poder y sencillez. Entonces aquí nos enfrentamos a un compromiso entre poder y sencillez. Cuando el poder o, en otras palabras, las habilidades expresadas en funcionalidad apagado en un p I bruto, es la sencillez se degrada. El equilibrio está oculto en algún lugar de la media dorada por lo que una de las preguntas más interesantes aquí es cómo estimar la simplicidad, a menudo un P I. Desafortunadamente, no hay formas algorítmicas de calcular ningún significativo coeficientes fuera de la sencillez. A menudo FBI. El único modo de entender si un FBI es simple o no es estimar el tiempo dedicado a entender por sus usuarios. Este método permite construir una curva de aprendizaje, muchas veces FBI, si la simplicidad A P I de la que estás tratando de analizar, es relativamente pequeña se. Si no es un marco enorme, entonces puedes dárselo a un par de tus compañeros y ver. ¿ Cuánto tiempo tardarán en entender tu A P I y cuántas veces requerirán comentarios o cualquier documentación fuera del FBI? Estos sencillos pasos mostrarán si el FBI es lo suficientemente simple, comparando con tus requerimientos de simplicidad o no. Entonces, primer lugar, se puede fijar un límite de tiempo para entender Europa. Entonces les pido a sus compañeros que intenten usar una funcionalidad de premio y luego comparar su premisa. Con los resultados de riel yendo de esta manera, podrás tomar una decisión para hacer más simple tu pastel o parar en el punto actual . Cosas cada vez más complejas cuando un P I se expresa en términos fuera de un determinado modelo de dominio. En este caso, hay que encontrar a quienes están familiarizados con el modelo de dominio y a quienes no lo están. ¿ Por qué ambos? Porque los programadores son recursos humanos y pueden dejar una empresa en cualquier momento. Estos pueden llevar a la situación en la que un recién llegado asumirá la responsabilidad de trabajar con tu A p I. Así que tienes que entender cuánto tiempo tardará en entender tu A P I. En ambos casos, estos pensamientos conducen a la siguiente característica de un buen A P I. buenos ojos AP son caros porque para hacerlos sencillos, es un accesorio para pasar mucho más tiempo que solo enviar todos los ensayos. Desafortunadamente, no sólo la sencillez sufre de bajo inversión, los errores tienen tendencia a acumularse y el diseño comienza a pudrirse. En consecuencia, conduce a una gran bola de barro en lugar de claridad, y al final, conduce a recurso de caja es que se puede asignar para reparar el desarrollo siempre son limitados . Entonces obviamente no podemos pulir a ocho tipos durante mucho tiempo. Por eso siempre hay compromisos entre poder y sencillez por cierto. A pesar de esforzarse por crear un FBI súper poderoso, es casi imposible desfilar universalmente, chicos, significa que un desarrollador P I tiene que implementar primero lo primero. Para entender los principales escenarios, es un accesorio para analizar habilidades, ventajas y fallas que enfrentará el usuario de todas las formas diferentes fuera de implementar una extensión P I. La estabilidad es la siguiente característica importante. Esta característica refleja las capacidades para aumentar el poder, muchas veces FBI sin escritos de grado. Hay un par de noticias es respecto a esta característica. Podemos mirar la capacidad extiende desde la perspectiva, fuera agregar nueva funcionalidad y preservar la compatibilidad hacia atrás. El diseño debe esforzarse por ser capaz de agregar nueva funcionalidad. El objeto principal no son principio en este caso es el principio de cierre abierto, lo que significa que un objeto debe abrirse para su extensión y cerrarse para su modificación. Yo diría que en su mayoría este principio es aplicable al zoológico. AP Eyes e g brillantes con los chicos en cuanto al público ocho chicos es que al principio no debemos desplegar características que podrían contradecir con la funcionalidad que se pueda introducir en el futuro. Si estás en dudas. Es mejor no presentar a un miembro del FBI que presentarlo. Cuando hablamos de ojos AP públicos, disparamos al principio, conservamos la compatibilidad hacia atrás, cambiando un AP I existente por lo que romperá cualquier cliente existente es la mejor escena. Desafortunadamente, esta escena no se puede evitar a veces, pero debes esforzarte por romper el código de los clientes tan raramente como sea posible. Un FBI tiene que ser lógico y consistente. La consistencia, a menudo FBI, significa que las decisiones se aplican al diseño de la cinta. La IE está fuertemente opinionada. Siempre habrá diferentes opciones disponibles con sus ventajas y desventajas. Pero un P I diseñadores deberían tomar a un lado y pegarse con él a lo largo de todo el camino. Echemos un mal ejemplo apagado para la consistencia. La Biblioteca de Peaster Beach expone los siguientes métodos. Al parecer, hay un método de nomenclatura inconsistente. Parece que los desarrolladores estaban en duda y dudaron sobre qué estilo off naming deberían seguir. En el camino. La mejor opción en este caso en particular fue usar subrayados en todas partes. Una peor manera era usar en todas partes. El naming conjunto y la peor manera posible es usar en todas partes, diferentes estilos de nomenclatura, la peor manera posible es exactamente lo que los diseñadores de BHP string AP I han elegido. Ahora los desarrolladores deben tener en cuenta dos estilos de nomenclatura diferentes y recordar cuándo usar cuál es Esto es realmente una locura. De acuerdo, hemos discutido las características de los chicos de fe. Ahora hablemos brevemente de chicos públicos y privados. Los principios señalados son más importantes para construir ojos AP públicos públicamente, chicos ponen mayor responsabilidad a la juventud y ser ojos privados. Es por eso que tienes que esforzarte por hacer mejor que esas características tanto como puedas. El costo de las malas decisiones puede ser extremadamente alto. Lo que acabo de decir no significa que los desarrolladores privados del FBI no necesiten tomar en cuenta esas características. Soy un fuerte creyente en que se deben desarrollar ojos AP privados, teniendo en cuenta todas esas características. Las repercusiones de baja calidad privada AP I diseñando podrían ser horribles. El caso es que las capas se construyen encima de otras capas así como aplicaciones a menudo construidas sobre otras aplicaciones. Por lo que introducir cambios de ruptura en ojos AP privados podría tener un impacto muy malo en módulos dependientes y aplicaciones enteras. El Corolla re de este hecho es que los zookeepers deben esforzarse por convertirse en guardabosques de todos modos. De esta manera todas las técnicas que discutiremos en este curso son aplicables para desarrollar tanto ojos AP privados como públicos más sobre el tema. Se puede leer siguiendo los enlaces adscritos a esta conferencia. De acuerdo, hablemos un poco de unos principios de desarrollo P I. Existen algunos principios de desarrollo que nos ayudan a crear unos ojos P con características grandes o al menos satisfactorias. Echemos un vistazo más de cerca. Los ojos AP deben ser lo más simples posible, pero no más simples. Este es el principio hablado en primer lugar por Albert Einstein. Este es un principio general que es aplicable a muchas cosas de nuestra vida, en el contexto fuera de un desarrollo de premios. Este principio implica que las cosas simples deben ser simples y al mismo tiempo, las cosas difíciles deben ser alcanzables en la práctica. También significa que cuando tienes dudas sobre introducir a un determinado miembro, solo déjalo fuera. Recuerda de nuevo que siempre puedes agregar pero nunca quitar. Esta regla es más relevante para público un premio, pero no olvides que introducir cambios rompedores en el FBI privado también es tener una escena, un buen AP. Debería permitir hacer mucho sin aprender mucho en la práctica, significa que debes esforzarte por construir unos ojos P, que son sencillos de usar en otros, para lograr tareas simples. Y en la parte superior de estos escenarios simples, deberían ser posibles realizar tareas más difíciles. ¿ Notaste que el primer principio resuena con el 2do 1? En realidad, todos los principios están interenredados. Todos tienen algo en común. AP Eyes debe basarse en casos de uso como una práctica Corolla re podemos decir aquí es que significa dos cosas. El 1er 1 es que para diseñar un AP, me imagino que eres cliente de la cinta. Escribo algún código, cual usa ese apenas aún inexistente a p I. Cómo deberían parecer los clientes fríos hacer como el frío que has escrito. El segundo es que hay que empezar a hacer un boceto a un vecino lo antes posible . No acumules requisitos de apaga, solo haz un boceto simple y pregunta ¿ Son los desarrolladores qué piensan de tu diseño? Por lo que lo primero que debes hacer es escribir varias muestras frías para los principales casos de uso. Pide a tus compañeros que implementen esos principales casos de uso si experimentaron dificultades. Es una mala señal. Proporcionar una barrera baja para usar un A P I. En la práctica, significa que siempre se debe proporcionar a los constructores más simples valores por defecto para los parámetros deben arrojar excepciones con mensajes que expliquen qué hacer para arreglar. El problema no debe requerir de los clientes crear explícitamente más de un tipo para lograr el uso principal. Los casos no deben requerir de los planes para realizar una inicialización amplia, a menudo objeto construir ojos AP autoexplicativos. Yo expresaría este pensamiento. En otras palabras, que un pastel clientes para confiar en Intel un sentido A por los clientes debe entender el a pastel simplemente usando la inteligencia. Entonces un a p tengo que ser comprensible intuitivamente. A pesar del punto anterior, debe proporcionar una documentación decente en el caso fuera de los ojos AP privados. Esto es especialmente importante para un premio que contenía las nociones principales lo que intrínsecamente las hace difíciles de entender, sobre todo para aquellos que son sólo el principio aprendiendo los conceptos de dominio. Al final, diría que su bebé debería apelar a la emoción más poderosa. ¿ Cuál crees? ¿ Amor? No exactamente. Apelar a la pereza. Nadie quiere aprender un libro. Una mano de espesor sobre el uso de tu FBI. Nadie, ni siquiera tú. 57. 11 VS YAGNI: esta conferencia se titula Solid versus Young. Si observas el curso con cuidado, podrías notar que al tratar de solucionar un problema de diseño, siempre terminamos con más clases y funciones. En otras palabras, podría parecer que terminamos con un diseño más complejo. La aplicación ciega fuera de principios sólidos puede llevarnos a la complejidad innecesaria. Sonríe muy a menudo. complejidad innecesaria es el resultado directo de violar el principio Yardeni. Greg Young hace mucho tiempo salió con la siguiente declaración. Los desarrolladores tienen tendencia a intentar resolver problemas específicos con soluciones generales. El chapado en oro siempre conduce al acoplamiento y la complejidad y el software. Greg Yann sugirió hacer específica a cabra en lugar de hacerlo general. El principio de responsabilidad única Natural se ajusta a la sugerencia de Greg Young de hacer específico al oro. SRP conduce a clases específicas con responsabilidades concretas. Aborda un problema muy específico. El Kalay shin off principios aparecen cuando llegamos a una situación en la que necesitamos hacer el código más general, lo que debemos hacer que la verdadera pregunta es qué debe generalizarse. El contestar a esta pregunta da su principio de abstracción reutilizado. El principio de envoltura significa esencialmente que si tienes una abstracción en nuestro caso, una interfaz o una clase abstracta y no es reutilizada o, en otras palabras, implementada por más de un implementador. Entonces probablemente violes el principio de abstracción reutilizado. Entonces el valor real de una abstracción es que elimina lo irrelevante y amplifica esencial según Toa Tío Bob. Por lo que para venir aquí a resolver principios evitando la violación yardeni al mismo tiempo, iniciar con una implementación concreta fuera de un comportamiento específico, observar los elementos comunes emergentes y aplicar la regla de tres, que establece que si te encuentras en una situación en la que quieres repetir la misma llamada tercera vez, necesitas introducir una abstracción y encapsulado el comportamiento común en ella. Esta es la única forma en que puedes lograr el equilibrio entre nous sólido y tú, Agnes a nivel arquitectónico. En la próxima conferencia, concretaremos un poco este tema y hablaremos de OCP versus Yeah, Agni 58. 12 OCP VS: En la conferencia anterior, aprendiste las relaciones entre principios sólidos en general y principio Yanni. En esta conferencia, verás un ejemplo concreto off solid versus Yardeni en la forma off OCP versus the Agony . Volvamos a la forma clásica de violación de UCP que analizamos en la sección de recetas. Tenemos aquí el método de dispositivo fino, que implementa su. ¿ Qué declaración de caso Inside Switch declaración Gay es una construcción fuera de una programación procedimental en la naturaleza? ¿ Este método viola el OCP? Desde la perspectiva de la definición de chismosa de Myers, aquí no se viola la receta, ya que agregar un nuevo modelo de dispositivo no conduce a ningún cambio en la firma fuera del método del dispositivo de fuego . Pero en su mayoría nos interesó la definición de Martín. En los tiempos modernos, y desde el punto de vista de Martín, la OCP es claramente violada para solucionar el problema. En el OCP, Sectional introdujo una clase basada en abstracto y varios herederos, que representaban los modelos de dispositivos. Por lo que introdujimos varios tipos nuevos en lugar de uno inicial. Sí, Agni al mismo tiempo significa que no necesitamos introducir ninguna abstracción hasta que realmente las necesitemos. Entonces, ¿qué hacer con esta situación? Qué principio debe esperar aquí chismosa Orry Ogni, Un colega mío, Vladimir Horcoff, da una gran respuesta a esta pregunta. Su respuesta es, depende. Depende de lo que hablamos anteriormente. Ya sea que estemos hablando de AP público, yo o no, la respuesta es diferente en estos casos. Entonces en el caso fuera de un AP privado, yo joven es más importante que OCP. Si somos dueños del código basado en su totalidad y lo desarrollamos dentro de un grupo privado de personas, no deberíamos introducir ninguna abstracción. Hasta que veamos que va a aparecer el tercer repetitivo Cho Chung, entonces necesitamos aplicar OCP para evitar una aplicación excesiva de código. En el caso del AP público, necesito sacrificar su agonía y aplicar OCP de inmediato porque los costos futuros honra Factoring hacia el diseño orientado a objetos será enorme introducirá cambios de ruptura . A los clientes no les gusta romper cambios. Entonces en este caso, OCP es más importante que Yanni. En la próxima conferencia, vamos a aclarar la diferencia entre SRP y yo hablo 59. 13 SRP e ISP: esta conferencia se titula como R P y Eyes Speed. Muy a menudo, los desarrolladores se confunden por la diferencia entre SRP y yo hablo. Por ejemplo, los desarrolladores dicen que si aplican este R P, entonces no hay necesidad de aplicar velocidad de hielo. Desde que todas las gafas tienen una sola responsabilidad, piensan que yo las velocidades me aplican para arreglar esta violación de RP. No obstante, esta opinión dista mucho de ser la verdad. S R B implica que una clase debe tener sólo una. El motivo para cambiar hablo al mismo tiempo nos dice que los clientes no deben depender cosas que no necesitan de manera más concreta y yendo directo al grano, sus diferentes puntos de vista sobre la misma idea, SRP está más enfocado en el diseñador lado. Punto de vista, mientras hablo está más enfocado en el punto de vista del lado del cliente. Considera el siguiente ejemplo aquí tener un almacenamiento de datos que implementa tanto operaciones de lectura como de escritura. Sería raro separar estas operaciones en clases separadas, por lo que no violamos esto. ¿ Están aquí al mismo tiempo? Si tenemos 10 clientes que dependen de la de la funcionalidad de lectura y otros 10 clientes que dependen de la funcionalidad de escritura de préstamos de lo que podría ser significativo introducir dos interfaces yo lector y yo escritor por ocultar cosas de los clientes que hacen no. Necesito ver para que podamos aplicar el hielo p aquí. Está bien. En la próxima conferencia, hablaremos de arquitectura y diseño. 60. 14 Arquitectura y diseño: esta conferencia se titula Arquitectura y Diseño. ¿ Alguna vez has pensado ¿Qué es la arquitectura? ¿ Qué significa? ¿ Y cuál es la diferencia entre arquitectura y diseño? Los desarrolladores a menudo usaban estos términos de manera intercambiable. Es muy importante sentir la diferencia. Entonces, empecemos con la arquitectura. Todo software serio tiene una arquitectura. Aunque la arquitectura sea caótica, significaría que el caos es la arquitectura fuera de ese caótico sistema. La arquitectura de software es un término muy vago, que muy a menudo se trata como el más alto nivel de abstracción fuera de un sistema. ¿ Qué tipo de almacenamiento de datos está presente? ¿ Cómo interactúan los módulos entre sí? ¿ Qué sistemas de recuperación hay en su lugar y así sucesivamente? En algún lugar de 2013 hubo un post de Martin padre que analizó el problema de definir la noción fuera de la arquitectura. Citó a Ralph Johnson, quien dijo que no existe tal noción, el más alto nivel de abstracción de un sistema usuarios, desarrolladores, titulares de productos, todos miran el sistema desde diferentes ángulos y ver la arquitectura de manera diferente. Es más correcto decir que la arquitectura está compuesta por componentes significativos, y lo que hace significativo a un componente es un experto. Desarrolladores dicen que componentes particulares son significativos, por lo que el rodar la noción fuera de la arquitectura es social. Se trata de un acuerdo formal y muy a menudo informal sobre cómo ver el sistema desde el más alto nivel. También hay otra definición de cama fuera de la arquitectura, y es importante hablar de ello. Aquí está. arquitectura es las decisiones que desearías que pudieras tomar temprano en un proyecto. Debido a esta definición, los desarrolladores tienden a pensar que al elegir un culo de DBM en particular, toman una decisión arquitectónica. En algunos casos, es cierto, y en otros casos no lo es. Por ejemplo, si nos aislamos para ser amasados mediante el uso de interfaces en el límite correspondiente fuera de nuestro sistema de software y podríamos reemplazar que d sea un desastre, lo hacemos irrelevante. Y lo más probable es que no tratemos eso. D ser una masa tiene un componente significativo. En realidad, el BMS y tú soy herramientas. Cuando decimos que una respuesta DBM en particular usted la alta tecnología pertenece a la arquitectura. viene a la mente una analogía que cuando construimos una casa, tratamos a los martillos, sierras de calar y otras herramientas como la arquitectura de la casa. Eso sonaría sin sentido. Por supuesto, esta no es una analogía absolutamente válida, ya que los martillos no tienen una influencia tan significativa en el sobre el resultado, como lo hacen los sistemas de gestión de bases de datos. Pero debemos entender que debemos esforzarnos, si es posible,por si es posible, hacer que las herramientas sean irrelevantes desde la perspectiva del dominio. Debemos esforzarnos por diferir las decisiones arquitectónicas en la medida de lo posible, ya que las decisiones tomadas en etapas tempranas muy a menudo al final resultan no ser óptimas en mejor de los casos. La definición fuera de un diseño de software no amerita observaciones tan profundas. El diseño de software se trata de diseñar los módulos o componentes individuales. ¿ Cuáles son las responsabilidades? Funciones off module X off glass? Por qué, qué puede hacer y qué no qué patrones de diseño se pueden utilizar. El diseño de software hace énfasis en componente de módulo y nivel de búsqueda. También tenemos nociones como arquitectura y panners de diseño. Los patrones arquitectónicos son formas estándar fuera de las relaciones entre componentes que consideraron patrones de arquitectura significativos en general incluyen cliente y servidor de dos niveles básicamente y escenario de servidor, cliente de tres niveles señor, y base de datos con mayor frecuencia software o arquitectura terminada, el modelo de servicio Web, impulsado por eventos y así sucesivamente. Los padres diseñados son esos patrones de los que hablamos a lo largo del curso. De vez en cuando, se pueden dividir en patrones conductuales, estructurales y de creación todos. Espero que ahora entiendas mejor. ¿ Qué es la arquitectura y el diseño? Vamos a despotricar un poco sobre buscar un equilibrio en la próxima conferencia. 61. Conclusión: en esta sección, aprendiste que cada pieza de conocimiento debe tener una sola representación inequívoca en el sistema, y esta es la definición del principio de impulsión. Las formas más comunes de la violación principal seca son la corriente mágica o los valores, lógica duplicada en múltiples ubicaciones y repetida incluso la lógica o múltiples casos de conmutadores dispersos por toda la base de código. Se aprende que esto implica que la simplicidad debe ser un objetivo clave en el diseño y sobre la complejidad del evaluador debe evitarse. La técnica principal que utilizamos para luchar con la complejidad es la descomposición. A la complejidad impuesta por el propio dominio se le llama la complejidad esencial. complejidad accidental es la complejidad fuera de nuestras soluciones, las cuales están destinadas a resolver los problemas del dominio. Sí, pero se trata de evitar por encima de la ingeniería. No existe un criterio bien definido, que permita medir la joven novedad del sistema. Sí, es un principal fuera de la programación extrema que establece que un programador no debe agregar funcionalidad hasta que se considere un accesorio. S El futbol europeo está fuertemente relacionado. Básicamente, calcetín es un principio que significa que tenemos que separar diferentes preocupaciones en diferentes módulos. Adherirse a calcetín permite construir sistemas modulares aquí está la lista de preocupaciones que a menudo debemos enfrentar en el desarrollo de software empresarial. You I business logic, presentation, logic and data laberinto Comando consulta, separación o buscarnos es un principio que establece que cada método debe ser o un comando que realiza en acción o una consulta que devuelve datos a la persona que llama, pero no ambas. Es decir, hacer una pregunta no debe cambiar la respuesta. Una formulación general de la ley de Demeter es la siguiente. Cada sindicato debe tener un conocimiento limitado sobre otras unidades. Unidades Onley estrechamente relacionadas con la unidad actual o cada sindicato solo deben hablar con sus amigos o no hablar con extraños que traiga una lista de retiros. El asombro subyace a un gran número de otros principios y técnicas. Este principio establece que un componente fuera de un sistema debe comportarse de una manera consistente con cómo es probable que los usuarios fuera de ese componente se esperen que se comporten. Aprendiste que la ocultación de información y la encapsulación son conceptos diferentes. La encapsulación está destinada a proteger la información en varianza. Ocultar es una de las formas en que logramos una encapsulación adecuada. También aprendiste que puedes lograr límites entre complejidad y simplicidad, aplicando su principio de abstracción reutilizado que OCP bits Yardeni en caso de AP I público y viceversa en caso de privado A P I. Sí, agonía vence a OCP. Se aprende que una terapia y hielo pr similares en su intención, pero diferentes desde el punto de vista semántico. SRP y yo hablamos y ambos se apliquen en la misma clase. Por ejemplo, no se contradicen entre sí. Aprendes que la arquitectura y el diseño son nociones diferentes. arquitectura es el acuerdo entre grupo de personas, generalmente programadores expertos, respecto a la importancia fuera de los componentes del sistema. Si bien el diseño de software es un concepto de nivel más bajo y se refiere a los detalles de implementación al final, cómo interactúan las clases e interfaces y así Y también aprendió que por supuesto, hay que practicar para llegar a ser sabio respecto a la construcción sistemas de software mantenibles. Enhorabuena. Este es el final del curso. Ese fue un largo viaje. Espero que lo hayan disfrutado. Aprendí mucho y me convertí en un mejor desarrollador. Y gracias por ver