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

Добродетелите на ООП

Очакваме от всяка методология за разработване на софтуер, че тя ще ни помогне при решаването на нашите проблеми. Но едно от най-големите предизвикателства пред дизайна е сложността. Колкото по-голяма и по-сложна е една софтуерна система, толкова по-важно е да я разбиете на малки, добре дефинирани парчета. За да се справите със сложността, трябва да се абстрахирате от детайлите. В този смисъл класовете са много удобен инструмент.

Класовете ви позволяват да конструирате от полезни компоненти с прости инструменти, което ви позволява да се абстрахирате от подробностите за изпълнението.
Данните и операциите върху тях образуват определена единица и те не се разпространяват в цялата програма, както често се случва в процедурното програмиране, а са описани заедно. Локализацията на кода и данните подобрява видимостта и поддръжката на софтуера.
Инкапсулацията ви позволява да въведете модулност, което улеснява паралелното изпълнение на задачата между множество изпълнители и актуализиране на версии на отделни компоненти.

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

Полиморфизмът е полезен предимно в следните ситуации.

Обработка на разнородни структури от данни. Програмите могат да работят, без да разграничават вида на обектите, което значително опростява кода. По всяко време могат да се добавят нови видове.
Промяна на поведението по време на изпълнение. На етапа на изпълнение един обект може да бъде заменен с друг, което улеснява, без промяна на кода, адаптирането на алгоритъма в зависимост от това кой обект се използва .
Изпълнение на работа с наследници. Алгоритмите могат да бъдат обобщени, така че те вече да могат да работят с повече от един вид обекти. .
Създаване на "рамка" (рамка). Независими от приложения части на домейна могат да бъдат внедрени като набор от общи класове или рамка и допълнително разширени чрез добавяне на специфични за приложението части.

Често софтуерът за многократна употреба не може да бъде постигнат, тъй като съществуващите компоненти вече не отговарят на нови изисквания. OOP помага да се постигне това, без да се нарушават съществуващите компоненти, което ви позволява да извлечете максимума от възможността за повторна употреба на компонентите.

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

Недостатъци на ООП

Документирането на класове е по-трудно, отколкото при процедурите и модулите. Тъй като всеки метод може да бъде заменен, документацията трябва да казва не само какво прави даден метод, но и в какъв контекст се нарича. В крайна сметка, заменените методи обикновено се извикват не от клиента, а от самата рамка. По този начин програмистът трябва да знае какви условия са изпълнени при извикване на даден метод. За абстрактни методи, които са празни, в документацията трябва да се посочи с каква цел трябва да се използва заменения метод.

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

Методите обикновено са по-кратки от процедурите, тъй като извършват само една операция с данните, но има много повече. Кратките методи са по-лесни за разбиране, но са неудобни, тъй като кодът за обработка на съобщението понякога е "размазан" в много малки методи.

Не трябва да се злоупотребява с капсулиране на данни. Колкото повече логика и данни са скрити в недрата на даден клас, толкова по-трудно е да ги разширите. Отправната точка тук не трябва да бъде, че клиентите нямат право да знаят за определени данни, но че клиентите не трябва да знаят, за да работят с класа на тези данни.

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

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

В хибридни езици като Oberon-2, Object Pascal и C ++ изпращането на съобщение води само до обаждане чрез указател към процедурна променлива. На някои машини съобщенията са само с 10% по-бавни от обичайните процедурни повиквания. И тъй като съобщенията се появяват в програмата много по-рядко от други операции, ефектът им върху времето за изпълнение практически няма ефект.

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

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

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

Заключение

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