Diez principios de diseño orientado a objetos que un programador de Java debe conocer

Los principios del Diseño Orientado a Objetos (OOD) son el núcleo de la Programación Orientada a Objetos (OOP) de Java, pero veo que la mayoría de los programadores de Java trabajan con los patrones Singleton y Decorator ... u "Observer" y no prestan suficiente atención al estudio del análisis orientado a objetos y diseño. Por supuesto, es importante aprender los conceptos básicos de la programación orientada a objetos : abstracción, encapsulación, polimorfismo y herencia, pero al mismo tiempo es igualmente importante conocer los principios del diseño para crear productos bien estructurados y comprensibles. Observo constantemente a programadores, desarrolladores de varios niveles que no han oído hablar de los principios de SOLID OOD o simplemente no conocen las ventajas que ofrece tal o cual principio de diseño, ni cómo aplicarlo en el código. En pocas palabras, esfuércese siempre por lograr la coherencia del código y un buen diseño en su solución. Grandes ejemplos para aprender Java y OOD son Apache y Sun de código abierto. Demuestran cómo se deben utilizar los principios OOD al escribir código en programas Java. Ilustración del uso de patrones en el JDK: Factory, el patrón “factory” en la clase BorderFactory , Qué es el patrón de diseño Factory... , el patrón Singleton, “singleton”, en la clase Runtime RunTime , el patrón Decorator, “decorador”, en varias clases de java.io. Por cierto, si está interesado en practicar el código Java, lea Effective Java, de Joshua Bloch (por ejemplo, Effective Java traducido al ruso ), una obra maestra del autor de la API de Java. También sobre el tema de OOD y patrones, recomiendo Head First Design Pattern, así como Head First Object Oriented Analysis and Design. Estos libros le ayudarán a escribir mejor código aprovechando los principios de OOD. Aunque la mejor manera de aprender cualquier principio es practicar y comprender las consecuencias de violar estos mismos principios, el tema de este artículo es una introducción a los principios de OOD para programadores de Java que aún no los usan o simplemente están aprendiendo el lenguaje. Creo que cada uno de los principios declarados de OOD ( SOLID ) merece un artículo separado con una explicación detallada de su esencia, y lo intentaré en el futuro (escribir estos artículos - aprox. transl.), pero por ahora, prepárate para repasarlo rápidamente. DRY (Не повторяйтесь) Первым принципом обозначим «не повторяйтесь», что значит, не пишите повторяющегося códigoа, используйте принцип абстракции, обобщая простые вещи в одном месте. Если у вас присутствует один и тот же блок códigoа более, чем в двух местах, подумайте об отдельном методе для него. Если есть константа для многоразового использования, создайте глобальную переменную с модификаторами public final. Большим преимуществом использования данного принципа является легкость дальнейшей технической поддержки. Важно также не злоупотреблять этим принципом, когда, к примеру, повторение códigoа существует не для самого códigoа, а для реализации функциональности. Например, когда вы проверяете OrderID и SSN, это не значит, что они идентичны o станут таковыми в будущем. Используя одинаковый código для двух разных функций o элементов, вы связываете их тесно, и когда OrderID поменяет формат, código проверки SSN перестанет работать. Имейте в виду такие связки и не комбинируйте все подряд, что использует схожий código, но на самом деле, не является связанным. Инкапсулируйте то, что меняется Одна вещь постоянна в мире программного обеспечения — изменение. Инкапсулируйте código, который в будущем будет меняться. Преимущество принципа в легкости тестирования и поддержки надлежащим образом инкапсулированного códigoа. При написании программ на java следуйте, по умолчанию, правилу создания переменных и методов с модификатором доступа private, расширяя доступ шаг за шагом, от private к protected, но не public. Несколько принципов дизайна java используют инкапсуляцию, паттерн Factory — хороший пример, где código создания un objetoов инкапсулирован и достаточно гибок, чтобы позже создавать новые un objetoы, но без воздействия на существующий código. Открыто-закрытый принцип дизайна Классы, методы, функции должны быть открыты для расширения (новой функциональности) и закрыты для модификации. Это отличный принцип из набора SOLID, соответствующий букве «О», предотвращающий изменение протестированного и работающего códigoа. Идеально, если вы добавляете новую функциональность только, когда ваш código должен тестироваться, и в этом цель этого принципа ООД. Принцип уникальной ответственности (SRP) SRP соответствует букве S в SOLID и означает, что не должно существовать более 1 причины для изменения класса, иными словами, класс должен обладать уникальной функциональностью. Если один класс java реализует 2 набора функций, их сцепление создает ситуацию, при которой изменение одного нарушит имеющееся сочетание, что потребует нового раунда тестирования во избежание сюрпризов при использовании программ. Внедрение зависимостей (DI) o принцип инверсии управления (IOC) Не просите зависимости, фреймворк вам её обеспечит. Этот принцип отлично реализован в фреймворке Spring. Прелесть принципа в том, что любой класс с внедренной зависимостью (DI, часть фреймворка Spring), легко тестировать с помощью un objetoа-муляжа и легко поддерживать, потому что código, создающий un objeto, инкапсулирован в фреймворке, и не смешивается с клиентским códigoом. Существует множество способов внедрять зависимости, например, используя инструментарий в byte-códigoе от фреймворков аспектно-ориентированного программирования типа AspectJ o используя прокси, Cómo в Spring. Посмотрите этот пример использования принципа DI & IOC, представляющего букву D в аббревиатуре SOLID. Предпочитайте структуру наследованию Всегда ставьте на первое место структуру, композицию, если возможно. Кто-то может спорить с этим утверждением, но я нахожу, что приоритет композиции - гораздо более гибкий подход, чем реализация через наследование. Композиция позволяет изменить поведение класса во время исполнения, задавая свойства в текущем режиме. Использование интерфейсов для создания класса, применение полиморфизма, дает нам гибкость в улучшении реализации каждый раз. Даже в книге Effective Java говорится о преимуществе композиции над наследованием. Принцип подстановки Лисков (LSP) Согласно принципу LSP, буква L в SOLID, функции, которые используют ссылки на базовые классы, должны иметь возможность использовать un objetoы производных классов, не зная об этом. LSP тесно связан с принципом уникальной ответственности и принципом разделения интерфейсов. Если у базового класса больше функциональности, чем у производного, такое соотношение нарушает принцип LSP. Quéбы следовать этому принципу, производный класс o подкласс должен расширять функциональность, а не сужать её. Принцип разделения интерфейсов (ISP) Данный принцип гласит, что класс не должен внедрять интерфейс ( Qué такое интерфейс в Java...) , если интерфейс не используется. В основном, такое происходит, когда интерфейс многофункциональный, а класс требует только одной функциональности. Разработка интерфейсов — сложная работа, реализовав интерфейс, трудно изменить его без изменения всей реализации. Другое преимущество использования принципа ISP заключается в том, что интерфейс внедряет методы до того, Cómo Cómoой-либо класс может их использовать, поэтому уникальная функциональность требует внедрения меньшего количества методов. Программирование для интерфейса, а не реализации «Всегда программируйте для интерфейса, а не реализации.» Следование этому принципу приведет вас к гибкому códigoу, который сможет работать с любой новой реализацией интерфейса. Используйте переменные интерфейсного типа, métodos con un valor de retorno o métodos con parámetros. El mismo consejo se encuentra en los libros Effective Java y OOD. Principio de delegación No hagas todo tú mismo, asigna el trabajo a la clase adecuada. Un ejemplo de libro de texto sobre la aplicación del principio de delegación es el uso de los métodos equals() y hashCode(). Para comparar dos objetos, dejamos que la clase haga el trabajo por sí misma, en lugar de dejar la verificación a la clase cliente. La ventaja de este principio es que evita la doble codificación y facilita el cambio de comportamiento. Todos los principios anteriores del diseño orientado a objetos le ayudarán a escribir código mejor y más flexible, coherente, pero sin conexiones innecesarias. La teoría es el primer paso. Lo más importante es desarrollar la capacidad de analizar dónde se aplican estos principios de OOD. Observe si está violando alguno de los principios, poniendo en peligro la flexibilidad de su código. Al mismo tiempo, nada es perfecto; es imposible resolver siempre los problemas únicamente aplicando los principios OOD en la programación. Son fundamentales, en su mayor parte, para soluciones corporativas y proyectos con un ciclo de soporte técnico largo.