Даҳ Принсипи тарҳрезии ба объект нигаронидашуда барномасози Java бояд бидонад

Принсипҳои тарҳрезии ба an object нигаронидашуда (OOD) асосии барномасозии Java ба an object нигаронидашуда (OOP) мебошанд, аммо ман мебинам, ки аксари барномасозони Java бо намунаҳои Singleton ва Decorator ё "Нозир" кор мекунанд ва ба омӯзиши таҳлor ба an object нигаронидашуда диққати кофӣ намедиҳанд. тарҳрезӣ. Албатта, омӯхтани асосҳои OOP муҳим аст : абстраксия, инкапсуляция, полиморфизм ва мерос, аммо дар айни замон донистани принсипҳои тарроҳӣ барои эҷоди маҳсулоти хуб сохторшуда ва фаҳмо муҳим аст. Ман пайваста барномасозон, таҳиягарони сатҳҳои гуногунро мушоҳида мекунам, ки ё дар бораи принсипҳои SOLID OOD нашунидаанд ё танҳо дар бораи бартариҳое, ки ин ё он принсипи тарҳрезӣ медиҳад ва чӣ тавр онро дар code татбиқ карданро намедонанд. Дар сатри поён, ҳамеша барои ҳамоҳангии code ва тарҳи хуб дар ҳалли худ саъй кунед. Намунаҳои олӣ барои омӯзиши Java ва OOD манбаи кушодаи Apache ва Sun мебошанд. Онҳо нишон медиҳанд, ки чӣ гуна принсипҳои OOD бояд ҳангоми навиштани code дар барномаҳои Java истифода шаванд. Намоиши истифодаи намунаҳо дар JDK: Фабрика, намунаи "заводӣ" дар синфи BorderFactory , Намунаи тарроҳии завод чист... , намунаи Singleton, "singleton", дар синфи Runtime RunTime , Намунаи Decorator, "декоратор", дар синфҳои гуногуни java.io . Дар омади гап, агар шумо ба машқ кардани codeи java таваҷҷӯҳ дошта бошед, Effective Java, Joshua Bloch (масалан, Effective Java тарҷумашуда ба русӣ ), шоҳасари муаллифи Java API-ро хонед. Инчунин дар мавзӯи OOD ва намунаҳо ман тавсия медиҳам, ки Head First Design Pattern ва инчунин таҳлил ва тарҳрезии ба an object нигаронидашудаи Head First. Ин китобҳо ба шумо бо истифода аз принсипҳои OOD барои навиштани codeи беҳтар кӯмак мекунанд. Гарчанде ки роҳи беҳтарини омӯхтани ҳама гуна принсипҳо амал кардан ва фаҳмидани оқибатҳои вайрон кардани ин принсипҳо мебошад, мавзӯи ин мақола муқаддима ба принсипҳои OOD барои барномасозони Java мебошад, ки ҳанӯз онҳоро истифода намебаранд ё танҳо забон меомӯзанд. Ман боварӣ дорам, ки ҳар яке аз принсипҳои зикршудаи 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, мо ба синф иҷозат медиҳем, ки тафтишро ба синфи муштарӣ вогузор кунем, балки худи синф корро иҷро кунад. Бартарии ин принсип дар он аст, ки он рамзгузории дукаратаро пешгирӣ мекунад ва тағир додани рафторро осон мекунад. Ҳама принсипҳои дар боло зикршудаи тарроҳии ба an object нигаронидашуда ба шумо дар навиштани codeи фасеҳ ва беҳтар, ҳамоҳанг, вале бидуни пайвастҳои нолозим кӯмак мекунанд. Назария қадами аввал аст. Муҳимтар аз ҳама он аст, ки қобorяти таҳлил кардани ин принсипҳои OOD дар куҷо татбиқ карда шаванд. Бубинед, ки оё шумо ягон принсипро вайрон карда, чандирии codeи худро зери хатар мегузоред. Дар айни замон, ҳеҷ чиз комил нест, танҳо бо истифода аз принсипҳои OOD дар барномасозӣ ҳамеша мушкилотро ҳал кардан ғайриимкон аст. Онҳо дар аксари мавридҳо барои ҳалли корпоративӣ ва лоиҳаҳо бо давраи тӯлонии дастгирии техникӣ муҳиманд.