Java プログラマーが知っておくべき 10 のオブジェクト指向設計原則

オブジェクト指向設計 (OOD) の原則は Java オブジェクト指向プログラミング (OOP) の中核ですが、ほとんどの Java プログラマはシングルトン パターンとデコレータパターン、または「オブザーバ」パターンを使って作業しており、オブジェクト指向分析とデザイン。もちろん、OOP の基本(抽象化、カプセル化、ポリモーフィズム、継承) を学ぶことは重要ですが、同時に、適切に構造化されたわかりやすい製品を作成するために設計の原則を知ることも同様に重要です。私は、 SOLID OOD 原則について聞いたことがない、または単にその設計原則が提供する利点や、それをコードに適用する方法について知らない、さまざまなレベルのプログラマーや開発者を常に観察しています。 結論としては、ソリューション内のコードの一貫性と優れた設計を常に追求する必要があります。Java と OOD を学習するための優れた例は、オープンソースの Apache と Sun です。これらは、Java プログラムでコードを記述する際に OOD 原則をどのように使用する必要があるかを示しています。JDK でのパターンの使用例: Factory、BorderFactoryクラスの「factory」パターン、Factory デザイン パターンとは... 、Runtime RunTimeクラスの Singleton パターン「singleton」、Decorator パターン、さまざまな java.io クラスの「decorator」。ちなみに、Java コードの練習に興味がある場合は、Java API の作者による傑作である、 Effective Java, Joshua Bloch (たとえば、 Effective Java のロシア語訳) を読んでください。また、OOD とパターンのトピックに関しては、Head First Design Pattern と Head First オブジェクト指向分析と設計をお勧めします。これらの書籍は、OOD 原則を利用してより良いコードを作成するのに役立ちます。原則を学ぶための最良の方法は、まさにその原則に違反した場合の結果を実践して理解することですが、この記事のトピックは、OOD をまだ使用していない、または言語を学習しているばかりの Java プログラマー向けに、OOD の原則を紹介することです。OOD ( SOLID )で述べられている各原則は、その本質を詳細に説明した別の記事に値すると信じています。将来的には (これらの記事を書くために - おおよその翻訳を) 試みるつもりですが、今のところは、すぐに確認する準備をしてください。 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у, который сможет работать с любой новой реализацией интерфейса. Используйте переменные интерфейсного типа、戻り値を持つメソッド、またはパラメータを持つメソッド。同じアドバイスが、Effective Java および OOD の本に記載されています。 委任の原則 自分ですべてを行うのではなく、適切なクラスに仕事を割り当てます。委任の原則を適用する教科書的な例は、equals() メソッドと hashCode() メソッドの使用です。2 つのオブジェクトを比較するには、チェックをクライアント クラスに任せるのではなく、クラス自体に作業を行わせます。この原則の利点は、二重コーディングが回避され、動作の変更が容易になることです。オブジェクト指向設計の上記の原則はすべて、一貫性がありながらも不必要な接続のない、柔軟で優れたコードを作成するのに役立ちます。理論は最初のステップです。最も重要なことは、これらの OOD 原則がどこに適用されるかを分析する能力を開発することです。原則に違反していないか、コードの柔軟性を危険にさらしていないかどうかを確認してください。同時に、完璧なものはなく、プログラミングに OOD 原則を適用するだけで常に問題を解決することは不可能です。これらは、ほとんどの場合、技術サポート サイクルが長い企業ソリューションやプロジェクトにとって重要です。