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 原则来解决问题是不可能的。在大多数情况下，它们对于技术支持周期较长的企业解决方案和项目至关重要。