Капсулиране

"Здравей, Амиго! Искам да посветя днешната лекция на капсулирането . Вече имаш обща представа Howво представлява."

И така, Howви са предимствата на капсулирането? Много са, но ще посоча четири, които според мен са най-важни:

1) Валидно вътрешно състояние.

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

Така че обектът трябва да проследява всички промени във вътрешните си данни or още по-добре – той трябва да прави тези промени.

Ако не искаме някоя променлива на класа да бъде променяна от други класове, тогава я декларираме като частна , което означава, че само методите на този клас имат достъп до нея. Ако искаме променливите да са само за четене за други класове, тогава добавяме public getter към тези променливи.

Например, може да искаме всички да знаят колко елемента има в нашата колекция, но никой не трябва да може да го променя без наше разрешение. В този случай ние декларираме променлива private int count и публичен метод getCount() .

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

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

2) Проверка на параметри.

Понякога трябва да проверите параметрите, предадени в методите на вашия клас. Да предположим например, че имаме клас, който представлява „човек“ и можете да посочите неговата рождена дата. Трябва да проверим дали всички предадени данни съответстват на логиката на програмата и логиката на класа. Например няма 13-ти месец, няма 30 февруари и т.н.

„Защо някой би посочил рождена дата 30 февруари?“

— Ами, първо, може да е резултат от грешка при въвеждане на данни.

Второ, преди една програма да работи като часовник, тя може да има много грешки. Например може да се случи нещо подобно.

Програмист пише code, който определя кой има рожден ден вдругиден. Да кажем, че днес е 3 март. Програмата добавя 2 към текущата дата и намира всички, които са родени на 5 март. Дотук добре.

Но когато дойде 30 март, програмата не намира никого, тъй като няма 32 март. Програмите са много по-малко бъгови, когато методите извършват проверка на параметри."

„Спомням си, когато изучавахме ArrayList, погледнах codeа му и имаше проверки в методите get и set, за да се гарантира, че параметърът на индекса е по-голям or equals на нула и по-малък от дължината на масива. Кодът ще хвърли изключение, ако масивът не е имал елемент, съответстващ на индекса.

„Да, това е класическа проверка на въвеждане. “

3) По-малко грешки при промяна на codeа вътре в класовете.

Да предположим, че написахме наистина полезен клас като част от огромен проект. Всички го харесват толкова много, че други програмисти започнаха да го използват на стотици места в собствения си code.

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

Но ако променим методите, маркирани като частни, знаем, че тези методи не се извикват от ничий друг code никъде. Можем да ги пренапишем и да променим броя и вида на параметрите и зависимият code пак ще работи. Или поне пак ще се компorра.

4) Ние определяме How другите обекти ще взаимодействат с нашия обект.

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

Капсулирането ни позволява да налагаме допълнителни ограничения , които могат да се превърнат в допълнителни предимства . Например класът String е имплементиран като неизменен обект. Екземплярите на класа String не могат да бъдат променяни между създаването и унищожаването му. Всички методи на класа String (remove, substring, ...) връщат нов низ и по ниHowъв начин не променят обекта, към който са извикани.

„Свещена крава. Значи така стоят нещата.“

„Енкапсулирането е интригуващо.“

"Съгласен съм."