Sampung Object-Oriented na Mga Prinsipyo ng Disenyo na Dapat Malaman ng Java Programmer

Ang mga prinsipyo ng Object Oriented Design (OOD) ay ang core ng Java Object Oriented Programming (OOP), ngunit nakikita ko ang karamihan sa mga Java programmer na nagtatrabaho sa mga pattern ng Singleton at Decorator . o "Observer" , at hindi binibigyang pansin ang pag-aaral ng object-oriented na pagsusuri at disenyo. Siyempre, mahalagang matutunan ang mga pangunahing kaalaman ng OOP : abstraction, encapsulation, polymorphism at inheritance, ngunit sa parehong oras, ito ay pantay na mahalagang malaman ang mga prinsipyo ng disenyo upang lumikha ng mahusay na istruktura at naiintindihan na mga produkto. Patuloy akong nagmamasid sa mga programmer, mga developer ng iba't ibang antas na alinman ay hindi nakarinig tungkol sa mga prinsipyo ng SOLID OOD , o sadyang hindi alam ang tungkol sa mga pakinabang na ibinibigay nito o ng prinsipyong iyon sa disenyo, o kung paano ilapat ito sa code. Bottom line, laging magsikap para sa pagkakaugnay ng code at magandang disenyo sa iyong solusyon. Ang magagandang halimbawa para sa pag-aaral ng Java at OOD ay ang open source na Apache at Sun. Ipinakita nila kung paano dapat gamitin ang mga prinsipyo ng OOD sa pagsulat ng code sa mga programang Java. Ilustrasyon ng paggamit ng mga pattern sa JDK: Factory, ang pattern na "pabrika" sa klase ng BorderFactory , Ano ang pattern ng disenyo ng Factory... , ang pattern ng Singleton, "singleton", sa klase ng Runtime RunTime , ang pattern ng Dekorator, "decorator", sa iba't ibang klase ng java.io . Siyanga pala, kung interesado kang magsanay ng java code, basahin ang Effective Java, Joshua Bloch (halimbawa, Effective Java na isinalin sa Russian ), isang obra maestra mula sa may-akda ng Java API. Gayundin sa paksa ng OOD at mga pattern, inirerekomenda ko ang Head First Design Pattern, pati na rin ang Head First Object Oriented Analysis at Design. Tutulungan ka ng mga aklat na ito na magsulat ng mas mahusay na code sa pamamagitan ng pagsasamantala sa mga prinsipyo ng OOD. Bagama't ang pinakamahusay na paraan upang matutunan ang anumang mga prinsipyo ay ang pagsasanay at pag-unawa sa mga kahihinatnan ng paglabag sa mismong mga prinsipyong ito, ang paksa ng artikulong ito ay isang panimula sa mga prinsipyo ng OOD para sa mga programmer ng Java na hindi pa gumagamit ng mga ito o nag-aaral pa lamang ng wika. Naniniwala ako na ang bawat isa sa mga nakasaad na prinsipyo ng OOD ( SOLID ) ay karapat-dapat sa isang hiwalay na artikulo na may detalyadong paliwanag ng kakanyahan, at susubukan ko sa hinaharap (upang isulat ang mga artikulong ito - tinatayang transl.), ngunit sa ngayon, maghanda upang mabilis na lampasan ito. 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у, который сможет работать с любой новой реализацией интерфейса. Используйте переменные интерфейсного типа, методы с возвращаемым meaningм or методы с параметрами. Те же советы содержатся в Effective Java и книгах по ООД. Принцип делегирования Не делайте всё самостоятельно, поручите работу соответствующему классу. Хрестоматийный пример применения принципа делегирования — использование методов equals() и hashCode(). Для сравнения двух an objectов мы поручаем классу самостоятельно сделать эту работу, instead of того, чтобы оставлять проверку клиентскому классу. Преимущество этого принципа в избежании двойного codeа и легкости в изменении поведения. Все изложенные принципы an objectно-ориентированного дизайна помогут вам писать гибкий и лучший code, связный, но без лишних связок. Теория — первый шаг. Важнее всего развивать способность к анализу, где применимы эти принципы ООД. Следите, не нарушаете ли вы Howой-либо из принципов, подвергая опасности гибкость codeа. Вместе с тем, ничто не совершенно, невозможно всегда решать проблемы только применением принципов ООД в программировании. Они критичны, по большей части, для корпоративных решений, проектов с длинным циклом технической поддержки.