Dix principes de conception orientée objet qu'un programmeur Java devrait connaître

Les principes de conception orientée objet (OOD) sont au cœur de la programmation orientée objet (POO) Java, mais je vois que la plupart des programmeurs Java travaillent avec les modèles Singleton et Decorator ou "Observer" et ne prêtent pas suffisamment d'attention à l'étude de l'analyse orientée objet et conception. Bien sûr, il est important d'apprendre les bases de la POO : abstraction, encapsulation, polymorphisme et héritage, mais en même temps, il est tout aussi important de connaître les principes du design afin de créer des produits bien structurés et compréhensibles. J'observe constamment des programmeurs, des développeurs de différents niveaux qui soit n'ont pas entendu parler des principes SOLID OOD , soit ne connaissent tout simplement pas les avantages qu'offre tel ou tel principe de conception, ni comment l'appliquer dans le code. En fin de compte, efforcez-vous toujours d’assurer la cohérence du code et une bonne conception dans votre solution. De bons exemples pour apprendre Java et OOD sont les logiciels open source Apache et Sun. Ils démontrent comment les principes OOD doivent être utilisés pour écrire du code dans des programmes Java. Illustration de l'utilisation des patterns dans le JDK : Factory, le pattern « factory » dans la classe BorderFactory , Qu'est-ce que le design pattern Factory... , le pattern Singleton, « singleton », dans la classe Runtime RunTime , le pattern Decorator, « décorateur », dans diverses classes java.io. À propos, si vous souhaitez pratiquer le code Java, lisez Effective Java, Joshua Bloch (par exemple, Effective Java traduit en russe ), un chef-d'œuvre de l'auteur de l'API Java. Toujours sur le thème de l'OOD et des modèles, je recommande Head First Design Pattern, ainsi que Head First Object Oriented Analysis and Design. Ces livres vous aideront à écrire un meilleur code en tirant parti des principes OOD. Bien que la meilleure façon d'apprendre des principes soit de pratiquer et de comprendre les conséquences de la violation de ces mêmes principes, le sujet de cet article est une introduction aux principes d'OOD pour les programmeurs Java qui ne les utilisent pas encore ou qui apprennent simplement le langage. Je crois que chacun des principes énoncés de OOD ( SOLID ) mérite un article séparé avec une explication détaillée de l'essence, et j'essaierai à l'avenir (d'écrire ces articles - environ trad.), mais pour l'instant, préparez-vous à le parcourir rapidement. 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у, который сможет работать с любой новой реализацией интерфейса. Используйте переменные интерфейсного типа, des méthodes avec une valeur de retour ou des méthodes avec des paramètres. Les mêmes conseils sont contenus dans les livres Effective Java et OOD. Principe de délégation Ne faites pas tout vous-même, confiez le travail à la classe appropriée. Un exemple classique d’application du principe de délégation est l’utilisation des méthodes equals() et hashCode(). Pour comparer deux objets, nous laissons la classe faire le travail elle-même, plutôt que de laisser la vérification à la classe client. L’avantage de ce principe est qu’il évite le double codage et facilite le changement de comportement. Tous les principes de conception orientée objet ci-dessus vous aideront à écrire un code flexible et de meilleure qualité, cohérent, mais sans connexions inutiles. La théorie est la première étape. Le plus important est de développer la capacité d’analyser où ces principes OOD s’appliquent. Surveillez si vous violez l’un des principes, mettant ainsi en péril la flexibilité de votre code. En même temps, rien n'est parfait ; il est impossible de toujours résoudre les problèmes uniquement en appliquant les principes OOD en programmation. Ils sont essentiels, pour la plupart, pour les solutions et les projets d'entreprise nécessitant un long cycle de support technique.