Java 프로그래머가 알아야 할 10가지 객체 지향 설계 원칙

OOD(객체 지향 설계) 원칙은 Java 객체 지향 프로그래밍(OOP)의 핵심이지만 대부분의 Java 프로그래머는 Singleton 및 Decorator 패턴 또는 "Observer"를 사용하여 작업하고 객체 지향 분석 및 연구에 충분한 주의를 기울이지 않는 것을 봅니다 . 설계. 물론 OOP의 기본인 추상화, 캡슐화, 다형성, 상속을 배우는 것도 중요하지만, 동시에 잘 구조화되고 이해하기 쉬운 제품을 만들기 위해서는 디자인의 원리를 아는 것도 똑같이 중요합니다. 저는 SOLID OOD 원리 에 대해 들어본 적이 없거나 단순히 이 설계 원리나 그 설계 원리가 제공하는 이점이나 이를 코드에 적용하는 방법을 모르는 다양한 수준의 프로그래머, 개발자를 지속적으로 관찰합니다 . 결론적으로, 항상 솔루션의 코드 일관성과 좋은 디자인을 위해 노력하십시오. Java 및 OOD 학습의 좋은 예는 오픈 소스인 Apache와 Sun입니다. Java 프로그램에서 코드를 작성할 때 OOD 원칙을 어떻게 사용해야 하는지 보여줍니다. JDK의 패턴 사용 예시: Factory, BorderFactory 클래스의 "팩토리" 패턴 , Factory 디자인 패턴이란 무엇입니까... , Runtime RunTime 클래스의 싱글톤 패턴, "싱글턴" , 데코레이터 패턴, 다양한 java.io 클래스의 "데코레이터". 그런데 Java 코드 연습에 관심이 있다면 Java API 작성자의 걸작인 Effective Java, Joshua Bloch(예: 러시아어로 번역된 Effective Java )를 읽어보세요. 그리고 OOD와 패턴에 관해서는 Head First Design Pattern과 Head First Object Oriented Analysis and Design을 추천합니다. 이 책들은 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 원칙을 적용하는 것만으로는 항상 문제를 해결할 수 없습니다. 대부분의 경우 기술 지원 주기가 긴 기업 솔루션 및 프로젝트에 매우 중요합니다.