Dez princípios de design orientado a objetos que um programador Java deve conhecer

Os princípios do Design Orientado a Objetos (OOD) são o núcleo da Programação Orientada a Objetos (OOP) Java, mas vejo a maioria dos programadores Java trabalhando com os padrões Singleton e Decorator ou "Observer" e não prestando atenção suficiente ao estudo da análise orientada a objetos e projeto. Claro, é importante aprender o básico de OOP : abstração, encapsulamento, polimorfismo e herança, mas ao mesmo tempo, é igualmente importante conhecer os princípios de design para criar produtos bem estruturados e compreensíveis. Observo constantemente programadores, desenvolvedores de vários níveis que ou não ouviram falar dos princípios SOLID OOD , ou simplesmente não sabem das vantagens que este ou aquele princípio de design oferece, ou como aplicá-lo no código. Resumindo, sempre busque a coerência do código e um bom design em sua solução. Ótimos exemplos para aprender Java e OOD são o código aberto Apache e Sun. Eles demonstram como os princípios OOD devem ser usados ​​na escrita de código em programas Java. Ilustração do uso de padrões no JDK: Factory, o padrão “factory” na classe BorderFactory , O que é o padrão de design Factory... , o padrão Singleton, “singleton”, na classe Runtime RunTime , o padrão Decorator, “decorador”, em diversas classes java.io. A propósito, se você estiver interessado em praticar código Java, leia Effective Java, Joshua Bloch (por exemplo, Effective Java traduzido para o russo ), uma obra-prima do autor da API Java. Também no tópico OOD e padrões, recomendo o Head First Design Pattern, bem como o Head First Object Oriented Analysis and Design. Esses livros ajudarão você a escrever um código melhor, aproveitando os princípios do OOD. Embora a melhor maneira de aprender quaisquer princípios seja praticar e compreender as consequências da violação desses princípios, o tópico deste artigo é uma introdução aos princípios do OOD para programadores Java que ainda não os utilizam ou estão apenas aprendendo a linguagem. Acredito que cada um dos princípios declarados do OOD ( SOLID ) é digno de um artigo separado com uma explicação detalhada da essência, e tentarei no futuro (escrever esses artigos - tradução aproximada), mas por enquanto, prepare-se para repassar isso rapidamente. DRY (Не повторяйтесь) Первым принципом обозначим «не повторяйтесь», что значит, не пишите повторяющегося codeа, используйте принцип абстракции, обобщая простые вещи в одном месте. Если у вас присутствует один и тот же блок codeа более, чем в двух местах, подумайте об отдельном методе для него. Если есть константа для многоразового использования, создайте глобальную переменную с модификаторами public final. Большим преимуществом использования данного принципа является легкость дальнейшей технической поддержки. Важно также не злоупотреблять этим принципом, когда, к примеру, повторение codeа существует не для самого codeа, а для реализации функциональности. Например, когда вы проверяете OrderID и SSN, это не значит, что они идентичны or станут таковыми в будущем. Используя одинаковый code для двух разных функций or элементов, вы связываете их тесно, и когда OrderID поменяет формат, code проверки SSN перестанет работать. Имейте в виду такие связки и не комбинируйте все подряд, что использует схожий code, но на самом деле, не является связанным. Инкапсулируйте то, что меняется Одна вещь постоянна в мире программного обеспечения — изменение. Инкапсулируйте code, который в будущем будет меняться. Преимущество принципа в легкости тестирования и поддержки надлежащим образом инкапсулированного codeа. При написании программ на java следуйте, по умолчанию, правилу создания переменных и методов с модификатором доступа private, расширяя доступ шаг за шагом, от private к protected, но не public. Несколько принципов дизайна java используют инкапсуляцию, паттерн Factory — хороший пример, где code создания an objectов инкапсулирован и достаточно гибок, чтобы позже создавать новые an objectы, но без воздействия на существующий code. Открыто-закрытый принцип дизайна Классы, методы, функции должны быть открыты для расширения (новой функциональности) и закрыты для модификации. Это отличный принцип из набора SOLID, соответствующий букве «О», предотвращающий изменение протестированного и работающего codeа. Идеально, если вы добавляете новую функциональность только, когда ваш code должен тестироваться, и в этом цель этого принципа ООД. Принцип уникальной ответственности (SRP) SRP соответствует букве S в SOLID и означает, что не должно существовать более 1 причины для изменения класса, иными словами, класс должен обладать уникальной функциональностью. Если один класс java реализует 2 набора функций, их сцепление создает ситуацию, при которой изменение одного нарушит имеющееся сочетание, что потребует нового раунда тестирования во избежание сюрпризов при использовании программ. Внедрение зависимостей (DI) or принцип инверсии управления (IOC) Не просите зависимости, фреймворк вам её обеспечит. Этот принцип отлично реализован в фреймворке Spring. Прелесть принципа в том, что любой класс с внедренной зависимостью (DI, часть фреймворка Spring), легко тестировать с помощью an object-муляжа и легко поддерживать, потому что code, создающий an object, инкапсулирован в фреймворке, и не смешивается с клиентским codeом. Существует множество способов внедрять зависимости, например, используя инструментарий в byte-codeе от фреймворков аспектно-ориентированного программирования типа AspectJ or используя прокси, How в Spring. Посмотрите этот пример использования принципа DI & IOC, представляющего букву D в аббревиатуре SOLID. Предпочитайте структуру наследованию Всегда ставьте на первое место структуру, композицию, если возможно. Кто-то может спорить с этим утверждением, но я нахожу, что приоритет композиции - гораздо более гибкий подход, чем реализация через наследование. Композиция позволяет изменить поведение класса во время исполнения, задавая свойства в текущем режиме. Использование интерфейсов для создания класса, применение полиморфизма, дает нам гибкость в улучшении реализации каждый раз. Даже в книге Effective Java говорится о преимуществе композиции над наследованием. Принцип подстановки Лисков (LSP) Согласно принципу LSP, буква L в SOLID, функции, которые используют ссылки на базовые классы, должны иметь возможность использовать an objectы производных классов, не зная об этом. LSP тесно связан с принципом уникальной ответственности и принципом разделения интерфейсов. Если у базового класса больше функциональности, чем у производного, такое соотношение нарушает принцип LSP. Whatбы следовать этому принципу, производный класс or подкласс должен расширять функциональность, а не сужать её. Принцип разделения интерфейсов (ISP) Данный принцип гласит, что класс не должен внедрять интерфейс ( What такое интерфейс в Java...) , если интерфейс не используется. В основном, такое происходит, когда интерфейс многофункциональный, а класс требует только одной функциональности. Разработка интерфейсов — сложная работа, реализовав интерфейс, трудно изменить его без изменения всей реализации. Другое преимущество использования принципа ISP заключается в том, что интерфейс внедряет методы до того, How Howой-либо класс может их использовать, поэтому уникальная функциональность требует внедрения меньшего количества методов. Программирование для интерфейса, а не реализации «Всегда программируйте для интерфейса, а не реализации.» Следование этому принципу приведет вас к гибкому codeу, который сможет работать с любой новой реализацией интерфейса. Используйте переменные интерфейсного типа, métodos com valor de retorno ou métodos com parâmetros. O mesmo conselho está contido nos livros Effective Java e OOD. Princípio da Delegação Não faça tudo sozinho, atribua o trabalho à turma apropriada. Um exemplo clássico de aplicação do princípio da delegação é o uso dos métodos equals() e hashCode(). Para comparar dois objetos, deixamos a classe fazer o trabalho sozinha, em vez de deixar a verificação para a classe cliente. A vantagem deste princípio é que ele evita a codificação dupla e facilita a mudança de comportamento. Todos os princípios de design orientado a objetos acima irão ajudá-lo a escrever código flexível e melhor, coerente, mas sem conexões desnecessárias. A teoria é o primeiro passo. O mais importante é desenvolver a capacidade de analisar onde estes princípios OOD se aplicam. Fique atento para ver se você está violando algum dos princípios, comprometendo a flexibilidade do seu código. Ao mesmo tempo, nada é perfeito; é impossível sempre resolver problemas apenas aplicando os princípios OOD na programação. São fundamentais, em sua maioria, para soluções corporativas e projetos com longo ciclo de suporte técnico.