Java 程式設計師應該了解的十項物件導向設計原則

物件導向設計 (OOD) 原則是 Java 物件導向程式設計 (OOP) 的核心，但我看到大多數 Java 程式設計師都在使用單例和裝飾器模式（或「觀察者」），而沒有足夠重視學習面向物件的分析和方法。設計。當然，學習OOP 的基礎知識：抽象、封裝、多態性和繼承很重要，但同時，了解設計原則以創建結構良好且易於理解的產品也同樣重要。我經常觀察程式設計師、不同層級的開發人員，他們要么沒有聽說過SOLID OOD 原則，要么根本不知道這個或那個設計原則提供的優勢，或者如何在程式碼中應用它。 最重要的是，始終努力在解決方案中實現程式碼一致性和良好的設計。學習 Java 和 OOD 的好例子是開源 Apache 和 Sun。它們示範如何使用 OOD 原則在 Java 程式中編寫程式碼。JDK中模式的使用圖解：Factory，BorderFactory類別中的“工廠”模式，什麼是Factory設計模式...，Singleton模式，RunTime類別中的“單例” ， Decorator模式， “裝飾器”，在各種java.io 類別中。順便說一下，如果你有興趣練習java程式碼，請閱讀Effective Java，Joshua Bloch（例如，翻譯成俄語的Effective Java），Java API作者的傑作。另外，關於 OOD 和模式的主題，我推薦 Head First 設計模式，以及 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() 方法。為了比較兩個對象，我們讓類別自己完成工作，而不是將檢查留給客戶端類別。這個原則的優點是它避免了雙重編碼並且可以輕鬆改變行為。所有物件導向設計的上述原則將幫助您編寫靈活、更好、連貫、但沒有不必要連接的程式碼。理論是第一步。最重要的是培養分析這些 OOD 原則適用範圍的能力。請注意是否違反了任何原則，從而危及程式碼的靈活性。同時，沒有什麼是完美的；僅透過在程式設計中應用 OOD 原則來解決問題是不可能的。在大多數情況下，它們對於技術支援週期較長的企業解決方案和專案至關重要。