Обектно-ориентирано програмиране

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

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

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

Фундаментални концепции на обектно-ориентираното програмиране[редактиране | edit source]

Обектно-ориентираното програмиране използва следните понятия:

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

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

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

Забележки: Абстракцията е важна, но не уникална за обектно-ориентираното програмиране. Многократната използваемост е предимство, често приписвано на обектно-ориентираното програмиране.

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

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

Предизвикателството в ООП, следователно, е проектирането на добре обмислена система от обекти.

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

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