Ten Object Oriented Design Principles a Java Programmer Should Know

Object Oriented Design (OOD) principles are the core of Java Object Oriented Programming (OOP), but I see most Java programmers working with the Singleton and Decorator patterns . or "Observer" , and not paying enough attention to studying object-oriented analysis and design. Of course, it is important to learn the basics of OOP : abstraction, encapsulation, polymorphism and inheritance, but at the same time, it is equally important to know the principles of design in order to create well-structured and understandable products. I constantly observe programmers, developers of various levels who either have not heard about the SOLID OOD principles , or simply do not know about the advantages that this or that design principle provides, or how to apply it in code. Bottom line, always strive for code coherence and good design in your solution. Great examples for learning Java and OOD are the open source Apache and Sun. They demonstrate how OOD principles should be used in writing code in Java programs. Illustration of the use of patterns in the JDK: Factory, the “factory” pattern in the BorderFactory class , What is the Factory design pattern... , the Singleton pattern, “singleton”, in the Runtime RunTime class , the Decorator pattern, “decorator”, in various java.io classes . By the way, if you are interested in practicing java code, read Effective Java, Joshua Bloch (for example, Effective Java translated into Russian ), a masterpiece from the author of the Java API. Also on the topic of OOD and patterns, I recommend Head First Design Pattern, as well as Head First Object Oriented Analysis and Design. These books will help you write better code by taking advantage of OOD principles. Although the best way to learn any principles is to practice and understand the consequences of violating these very principles, the topic of this article is an introduction to the principles of OOD for Java programmers who do not yet use them or are just learning the language. I believe that each of the stated principles of OOD ( SOLID ) is worthy of a separate article with a detailed explanation of the essence, and I will try in the future (to write these articles - approx. transl.), but for now, get ready to just quickly go over it. 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у, который сможет работать с любой новой реализацией интерфейса. Используйте переменные интерфейсного типа, methods with a return value, or methods with parameters. The same advice is contained in Effective Java and OOD books. Principle of Delegation Don't do everything yourself, assign the work to the appropriate class. A textbook example of applying the principle of delegation is the use of the equals() and hashCode() methods. To compare two objects, we let the class do the work itself, rather than leaving the checking to the client class. The advantage of this principle is that it avoids double coding and makes it easy to change behavior. All of the above principles of object-oriented design will help you write flexible and better code, coherent, but without unnecessary connections. Theory is the first step. The most important thing is to develop the ability to analyze where these OOD principles apply. Watch to see if you're violating any of the principles, jeopardizing the flexibility of your code. At the same time, nothing is perfect; it is impossible to always solve problems only by applying OOD principles in programming. They are critical, for the most part, for corporate solutions and projects with a long technical support cycle.