Обектно-ориентиран дизайн

от Уикипедия, свободната енциклопедия
Направо към навигацията Направо към търсенето

Обектно-ориентиран дизайн е процес на планиране на системата да взаимодейства с обекти с цел разрешаване на софтуерни проблеми.  Това е един от подходите за разработка на софтуер.

История[редактиране | редактиране на кода]

Обектът съдържа затворени данни и процедури, които групирани заедно представляват една отделна единица. „Обектният интерфейс“ определя начина за взаимодействие с обекта. Една обектно-ориентирана програма се характеризира с взаимодействието на тези обекти. Обектно-ориентираният дизайн е дисциплината, която дефинира обектите и техните взаимодействия за разрешаването на проблем, който е бил идентифициран и документиран по време на обектно-ориентираният анализ.

Това, което следва е описанието на класове базирани на подмножества в обектно-ориентирания дизайн, който не включва обект с прототипно базирани подходи, където обектите не са типично получени от примерни класове, а от клонирането на други (прототипни) обекти.

Обектно-ориентираният дизайн е начин, при който дизайнът обхваща процеса на обектно-ориентирана декомпозиция и нотация за представяне на логически и физически, също така статични и динамични модели на системата преди дизайна.

Обектно ориентиран дизайн – теми[редактиране | редактиране на кода]

Въведение (източници) в обектно-ориентирания дизайн[редактиране | редактиране на кода]

Входът за обектно-ориентирания дизайн е предоставен от крайния резултат на обектно-ориентирания анализ. Става ясно, че изходният продукт не е необходимо да бъде напълно разработен, за да служи като начало за обектно-ориентирания дизайн; анализът и дизайнът могат паралелно да възникнат и на практика резултатите от едно действие могат да захранят други действия в кратък цикъл на обратна връзка чрез повтарящ се процес. И двете, анализът и дизайнът, могат да се извършват постепенно, а крайните резултати може постоянно да растат.

Някои типични входни продукти за обектно-ориентирания дизайн са:

  • Концептуален модел: Резултат от обектно-ориентиран анализ: Той обхваща понятията/концепциите/идеите за решаване на проблеми и разработване на основната концепция. Концептуалният модел е изрично избран да бъде независим от детайлите по изпълнението, като конкретни алгоритми и начини за съхранение на данни.
  • Случай на употреба: Описание на последователност от действия, които са взети заедно, позволяват на системата да изпълнява нещо полезно. Всеки един случай на употреба предоставя един или повече сценарии, които да демонстрират взаимодействието на системата с всички потребители, наречени актьори, за постигането на специфична бизнес цел или функция. Актьорите могат да бъдат крайни потребители или други системи. В голяма част от обстоятелствата, случаите на употреба се доразработват в диаграми. Те се използват с цел идентификация на актьорите (потребители или други системи) и процесите, които те изпълняват.
  • Диаграма на системната последователност: Диаграма на системната последователност (ДСП) е картина, която показва, за определен сценарий или случай на употреба. Случаите, които са генерирани от външни актьори, с тяхната последователност и възможните вътрешно-системни резултати.
  • Документация на потребителски интерфейс (ако е приложимо): Документ, който показва и в който са описани изгледа и поведението на интерфейса на продукт за крайния потребител. Неговото наличие не е задължително, но би оказало помощ при визуализацията на крайния продукт и следователно да подпомогне на дизайнера.
  • Релационен модел на данните (ако е приложимо): Моделът на данните е абстрактен модел, който описва начина на представяне на данните и тяхната употреба. Ако обектът на базите данни не е използван, релационният модел на данните следва да бъде разработен преди дизайна, тъй като стратегията избрана за обектно-релационното планиране/разпределяне е изходният резултат от ОО-дизайнерския процес. Въпреки това разработката на релационния модел на данни е възможна паралелно с обектно-ориентирани дизайнерски продукти, а ръста на един продукт може да стимулира усъвършенстването на други.

Обектно-ориентирани концепции[редактиране | редактиране на кода]

Петте основни концепции на обектно-ориентирания дизайн са характеристиките на нивото на изпълнение, които са вградени в езика за програмиране. Тези функции са често срещани под следните имена:

  • Обект / Клас: Тясна взаимно свързаност на структури от данни с методи или функции, които оперират над тези данни. Това се нарича клас, или обект (обекта се създава на базата на клас). Всеки обект изпълнява отделна функция. Тя се дефинира от неговите полета, за какво служи и какво може да прави. Обекта може да бъде част от клас, който е набор от подобни обекти.
  • Скриване на данни: Способността да се защитят част от компонентите на обекта от външни лица. Това се реализира чрез ключови думи на езика, за да се даде възможност на дадена променлива да бъде декларирана като частна или защитена за класа, който я притежава.
  • Наследяване: Възможността на даден клас да разшири или замени функционалност на друг клас. Така нареченият подклас има цял раздел, който се извлича (наследява) от супер класа и по този начин, притежава свой собствен набор от функции и данни.
  • Интерфейс (обектно-ориентирано програмиране): Способността за отлагане на имплементацията на даден метод. Възможността да се дефинира сигнатурата на функциите или методите без да се прилагат.
  • Полиморфизъм: Възможността да се замени един обект с неговите под-обекти. Способността на променлива на даден обект да съдържа не само този обект, но също така и всички негови под-обекти.

Концепции на дизайна[редактиране | редактиране на кода]

  • Дефиниране на обекти, създаване на диаграма на класове от основната концепция: Обикновено това е описване на статичната структура на дадена система.
  • Идентификация на атрибутите.
  • Употреба на шаблони за дизайн(ако е приложимо): Шаблонът за дизайн е незавършен дизайн, описващ разрешението на често срещан проблем в контекста. Основното предимство на употребата на дизайнерски шаблон е, че може да бъде използван многократно в множество приложения. Той може да бъде считан и за шаблон за разрешаването на проблем, който може да бъде използван в много различни ситуации и/или приложения. Обектно-ориентираните дизайнерски шаблони показват типичните връзки и взаимодействия между класовете или обектите без да се уточняват крайните класове или обекти, които са включени.
  • Дефиниране на работна рамка на приложението (ако е приложимо): Работна рамка на приложение е термин, който обикновено се използва за насочване към множество библиотеки или класове, които се използват за изпълнението на стандартна структура на приложение за дадена операционна система. Чрез групирането на голямо количество кодове за многократна употреба в структурата се спестява време за разработчика, тъй като той/тя е записал/а задачата за пренаписването на голямо количество стандартен код за всяко ново приложение, което се разработва.
  • Идентифициране на постоянни обекти/данни (ако е приложимо): Идентифициране на обекти с многократно приложение, отколкото еднократно по време на изпълнение на приложението. Ако се използва релационна база данни, то тогава е необходимо проектирането на релационен обект.
  • Идентифициране и определяне на отдалечени обекти (ако е приложимо): Идентифициране на отдалечени обекти, дава възможност за използването на обекти които не са описани в текущата структура.

Изход (резултати) на обектно-ориентирания дизайн[редактиране | редактиране на кода]

Примерна диаграма на последователностите
  • Диаграма на последователностите: Разширяване на системната диаграма на последователността с добавянето на специфични обекти, които описват начина, по който групи от обекти постигат съвместно някакво поведение. Една диаграма на последователността показва реда, в който се случват нещата, като последователност от съобщения: по вертикала – изобразява се последователността от случващите се събития, като тези с по-високо ниво се случват по рано от тези по-ниско в диаграмата; правоъгълници – изобразяват инстанциите на представените класове и обекти; хоризонтални стрелки (връзки) – изобразяват съобщенията, с които различните процеси или обекти се обменят помежду си, следвайки последователността на тяхното възникване.
  • Диаграма на класа: Диаграма на класа е от типа на статична структура UML-диаграма, която описва структурата на система, показвайки системните класове, техните атрибути и връзките между класовете. Съобщенията и класовете, идентифицирани по време на разработката на последователност от диаграми, може да послужат като начало за автоматизирано генериране на глобалните класови диаграми на системата.

Някои принципи и стратегии на дизайна[редактиране | редактиране на кода]

  • Внедряване на зависимост: Основната идея е, че ако един обект зависи от моментната наличност на други обекти, то тогава необходимият обект бива „инжектиран“ в зависимият обект; Пример: прехвърлянето на връзката на база данни, в качеството си на аргумент, към конструктора вместо да се създаде вътрешно за него.
  • Принцип на ацикличните зависимости: Графиката на зависимост на пакети или компоненти (нееднородността зависи от приложимото поле на работа на разработчика) не трябва да има цикли. Това също се нарича директна ациклична графика. Например, пакет В зависи от пакет Б, който зависи от пакет А. Ако пакет А също зависи от пакет В, то тогава би имало цикъл.
  • Принцип на комбинирана повторна употреба: Позволява да бъдат дефинирани и създавани обекти, които са специализирани варианти на вече съществуващи обекти.

Вижте също[редактиране | редактиране на кода]

Източници[редактиране | редактиране на кода]

Външни препратки[редактиране | редактиране на кода]

Криейтив Комънс - Признание - Споделяне на споделеното Лиценз за свободна документация на ГНУ Тази страница частично или изцяло представлява превод на страницата „Object-oriented_design“ в Уикипедия на английски. Оригиналният текст, както и този превод, са защитени от Лиценза „Криейтив Комънс - Признание - Споделяне на споделеното“, а за съдържание, създадено преди юни 2009 година — от Лиценза за свободна документация на ГНУ. Прегледайте историята на редакциите на оригиналната страница, както и на преводната страница. Вижте източниците на оригиналната статия, състоянието ѝ при превода и списъка на съавторите.