Java программисти билиши керек болгон объектке багытталган дизайндын он принциптери

Объектке багытталган дизайн (OOD) принциптери Java Объектке багытталган программалоонун (OOP) өзөгүн түзөт, бирок мен Java программисттеринин көбү Singleton жана Decorator үлгүлөрү менен иштеп жатканын көрүп жатам . же " Байкоочу " . дизайн. Албетте, OOP негиздерин үйрөнүү маанилүү : абстракция, инкапсуляция, полиморфизм жана тукум куучулук, бирок ошол эле учурда жакшы структураланган жана түшүнүктүү өнүмдөрдү түзүү үчүн дизайн принциптерин билүү да бирдей маанилүү. Мен дайыма SOLID OOD принциптери жөнүндө укпаган , же тигил же бул дизайн принциби берген артыкчылыктарды же аны codeдо кантип колдонууну билбеген программисттерди, ар кандай деңгээлдеги иштеп чыгуучуларды дайыма байкап турам. Жыйынтыктап айтканда, чечимиңизде ар дайым codeдун ырааттуулугуна жана жакшы дизайнга умтулуңуз. Java жана OOD үйрөнүү үчүн сонун мисалдар ачык булак Apache жана Sun болуп саналат. Алар Java программаларында code жазууда OOD принциптерин кантип колдонуу керектигин көрсөтөт. JDK үлгүлөрүнүн колдонулушунун иллюстрациясы: Factory, BorderFactory классындагы "фабрика" үлгүсү , Фабрика дизайн үлгүсү деген эмне... , Singleton үлгүсү, "singleton", Runtime RunTime классында , Decorator үлгүсү, "декоратор", ар кандай java.io класстарында. Айтмакчы, эгер сиз Java-codeду үйрөнгүңүз келсе, анда Java API авторунун шедеври болгон Effective Java, Joshua Bloch (мисалы, Effective Java орус тorне которулган ) дегенди окуңуз. Ошондой эле OOD жана үлгүлөр темасында мен Head First Design Pattern, ошондой эле Head First Объектке багытталган анализди жана дизайнды сунуштайм. Бул китептер OOD принциптерин колдонуу менен жакшыраак code жазууга жардам берет. Кандайдыр бир принциптерди үйрөнүүнүн эң мыкты жолу бул принциптерди бузуунун кесепеттерин практикалоо жана түшүнүү болсо да, бул макаланын темасы 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() ыкмаларын колдонуу болуп саналат. Эки an objectти салыштыруу үчүн текшерүүнү кардар классына калтырбастан, класска ишти өзү аткарууга уруксат беребиз. Бул принциптин артыкчылыгы, ал кош codeдоодон качат жана жүрүм-турумду өзгөртүүгө жеңил кылат. Объектке багытталган дизайндын жогорудагы бардык принциптери ийкемдүү жана жакшыраак codeду, ырааттуу, бирок керексиз байланыштарды жазууга жардам берет. Теория биринчи кадам болуп саналат. Эң негизгиси - бул OOD принциптери кайда колдонуларын талдоо жөндөмүн өнүктүрүү. Кодуңуздун ийкемдүүлүгүнө коркунуч келтирип, кандайдыр бир принциптерди бузуп жатасызбы, карап көрүңүз. Ошол эле учурда эч нерсе кемчorксиз эмес, программалоодо OOD принциптерин колдонуу менен ар дайым маселелерди чечүү мүмкүн эмес. Алар узак техникалык колдоо цикли менен корпоративдик чечимдер жана долбоорлор үчүн маанилүү болуп саналат.