Java proqramçısının bilməli olduğu on obyekt yönümlü dizayn prinsipi

Obyekt yönümlü dizayn (OOD) prinsipləri Java Obyektyönümlü Proqramlaşdırmanın (OOP) əsasını təşkil edir, lakin mən görürəm ki, əksər Java proqramçıları Singleton və Decorator nümunələri ilə işləyir . dizayn. Əlbəttə ki, OOP əsaslarını öyrənmək vacibdir : abstraksiya, inkapsulyasiya, polimorfizm və irsiyyət, lakin eyni zamanda yaxşı strukturlaşdırılmış və başa düşülən məhsullar yaratmaq üçün dizayn prinsiplərini bilmək eyni dərəcədə vacibdir. SOLID OOD prinsipləri haqqında eşitməmiş və ya sadəcə olaraq bu və ya digər dizayn prinsipinin təmin etdiyi üstünlükləri və ya kodda necə tətbiq olunacağını bilməyən proqramçıları, müxtəlif səviyyəli tərtibatçıları daim müşahidə edirəm. Nəticə olaraq, həmişə həllinizdə kod uyğunluğu və yaxşı dizayn üçün səy göstərin. Java və OOD öyrənmək üçün əla nümunələr açıq mənbə Apache və Sundur. Java proqramlarında kod yazarkən OOD prinsiplərindən necə istifadə edilməli olduğunu nümayiş etdirirlər. JDK-da naxışların istifadəsinin təsviri: Fabrika, BorderFactory sinfində "zavod" nümunəsi , Fabrika dizayn nümunəsi nədir... , Singleton nümunəsi, "singleton", Runtime RunTime sinifində , Dekorator nümunəsi, “dekorator”, müxtəlif java.io siniflərində . Yeri gəlmişkən, əgər siz java kodu ilə məşğul olmaq istəyirsinizsə, Java API-nin müəllifinin şah əsəri olan Effektiv Java, Joshua Bloch (məsələn, Effektiv Java rus dilinə tərcümə edilmiş ) kitabını oxuyun. Həmçinin OOD və naxışlar mövzusunda mən Head First Design Pattern, eləcə də Head First Object Oriented Analysis and Design-ı tövsiyə edirəm. Bu kitablar OOD prinsiplərindən istifadə edərək daha yaxşı kod yazmağınıza kömək edəcək. Hər hansı bir prinsipi öyrənməyin ən yaxşı yolu məşq etmək və məhz bu prinsipləri pozmağın nəticələrini anlamaq olsa da, bu məqalənin mövzusu onlardan hələ istifadə etməyən və ya dili yenicə öyrənən Java proqramçıları üçün OOD prinsiplərinə girişdir. İnanıram ki, OOD-un ( SOLID ) qeyd olunan prinsiplərinin hər biri mahiyyətinin ətraflı izahı ilə ayrıca məqaləyə layiqdir və mən gələcəkdə çalışacağam (bu məqalələri yazmağa - təqribən. tərcümə), lakin hələlik, tez bunun üstündən keçməyə hazır olun. 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у, который сможет работать с любой новой реализацией интерфейса. Используйте переменные интерфейсного типа, qaytarma dəyəri olan üsullar və ya parametrləri olan üsullar. Eyni məsləhət Effektiv Java və OOD kitablarında da var. Nümayəndəlik prinsipi Hər şeyi özünüz etməyin, işi müvafiq sinifə tapşırın. Təqdimat prinsipinin tətbiqinə dair dərslik nümunəsi equals() və hashCode() metodlarının istifadəsidir. İki obyekti müqayisə etmək üçün yoxlamanı müştəri sinfinə buraxmaqdansa, sinfə işi özü etməyə icazə veririk. Bu prinsipin üstünlüyü ondan ibarətdir ki, o, ikiqat kodlaşdırmadan qaçır və davranışı dəyişdirməyi asanlaşdırır. Obyekt yönümlü dizaynın yuxarıda göstərilən bütün prinsipləri çevik və daha yaxşı kod yazmağa kömək edəcək, ardıcıl, lakin lazımsız əlaqələr olmadan. Nəzəriyyə ilk addımdır. Ən vacibi, bu OOD prinsiplərinin harada tətbiq olunduğunu təhlil etmək bacarığını inkişaf etdirməkdir. Prinsiplərdən hər hansı birini pozduğunuzu və kodunuzun çevikliyini təhlükə altına atdığınızı görmək üçün baxın. Eyni zamanda, heç bir şey mükəmməl deyil, yalnız proqramlaşdırmada OOD prinsiplərini tətbiq etməklə həmişə problemləri həll etmək mümkün deyil. Onlar uzun texniki dəstək dövrü olan korporativ həllər və layihələr üçün çox vacibdir.