Принципи на капсулиране

здрасти Нека посветим днешния урок на капсулирането и веднага да започнем с примери :) Тук имате обикновена машина за газирани напитки . Имам един въпрос към вас: How работи? Опитайте се да дадете подробен отговор: откъде идва чашата, How се поддържа вътрешната температура, къде се съхранява ледът, How машината знае кой сироп да добави и т.н.? Вероятно нямате отговори на тези въпроси. Честно, тъй като не всеки използва такива машини. Те не са толкова популярни в днешно време. Нека се опитаме да дадем друг пример. Нещо, което определено използвате много пъти всеки ден. О, ето една идея! Разкажете ни How работи търсачката Googleвърши работа. Как точно търси информация, свързана с думите, които въвеждате? Защо определени резултати са високо класирани, а други не? Въпреки че използвате Google всеки ден, има вероятност да не знаете. Но няма meaning. Не е нужно да знаете това. Можете да въвеждате заявки в търсачката, без да мислите How работи. Можете да си купите сода от машина, без да знаете How работи. Можете да карате кола, без да разбирате How работи двигател с вътрешно горене и без изобщо да знаете физика, дори на ниво начално учorще. Всичко това е възможно благодарение на един от основните принципи на обектно-ориентираното програмиране: капсулирането. Четейки различни статии за обектно-ориентирано програмиране (ООП), сигурно сте попадали на факта, че програмирането включва две общи концепции: капсулиране и скриване . И авторите използват думата "капсулиране", за да означават едно нещо, а след това друго. Ще проучим и двата термина, за да получите пълно разбиране. В програмирането първоначалното meaning на капсулирането е групирането на данни, заедно с методите, които работят върху тези данни, в една единица (т.е. „капсула“). В Java класът е единицата за капсулиране. Класът съдържа Howто данни (полета), така и методи за работа с тези данни.Това може да изглежда като очевидно правилния подход за вас, но в други парадигми на програмиране всичко е подредено по различен начин. Например във функционалното програмиране данните са строго разделени от операциите върху тях. В ООП програмите се състоят от капсули or класове, които се състоят от данни и функции за работа с тези данни. Сега нека поговорим за криенето . Как става така, че използваме всяHowви сложни устройства, без да разбираме How са организирани or How работят? Просто е: техните създатели ни предоставиха прост и удобен интерфейс. На машина за газирани напитки интерфейсът е бутоните на панела. С натискане на един бутон избирате размера на чашата. Натискайки друг, избирате вкуса. Трета е отговорна за добавянето на лед. И това е всичко, което трябва да направите. Вътрешната организация на машината няма meaning. Важното е, че е проектиран по начин, който изисква потребителят да натисне три бутона, за да получи сода . Същото важи и за колите. Няма meaning Howво се случва вътре. Важното е, че при натискане на десния педал колата се движи напред, а при натискане на левия педал забавя. Ето Howво представлява криенето. Всички "вътрешности" на програмата са скрити от потребителя. За потребителя това е излишна, ненужна информация. Потребителят се нуждае от крайния резултат, а не от вътрешния процес. Нека разгледаме Autoкласа като пример:

public class Auto {

   public void go() {

       /* Some complicated things happen inside the car.
       As a result, it moves forward */
   }

   public void brake() {

       /* Some complicated things happen inside the car.
       As a result, it slows down. */
   }

   public static void main(String[] args) {

       Auto auto = new Auto();

       // From the user's perspective,

       // one pedal is pressed and the car accelerates.
       auto.gas();
      
       // The other is pressed, and the car slows down.
       auto.brake();
   }
}

Ето How изглежда скриването на изпълнението в Java програма. Това е точно Howто в реалния живот: на потребителя се предоставя интерфейс (методи). Ако потребителят се нуждае от кола в програма, за да извърши действие, той or тя просто извиква желания метод. Това, което се случва вътре в тези методи, е излишно. Важното е всичко да работи Howто трябва. Тук говорим за скриване на внедряване . Освен това Java има и скриване на данни . Писахме за това в урока за гетери и сетери , но прегледът на концепцията няма да навреди. Например, имаме Catклас:

public class Cat {

   public String name;
   public int age;
   public int weight;

   public Cat(String name, int age, int weight) {
       this.name = name;
       this.age = age;
       this.weight = weight;
   }

   public Cat() {
   }

   public void sayMeow() {
       System.out.println("Meow!");
   }

  
}

Може би си спомняте проблема с този клас от последния урок? Ако не, нека си го припомним сега. Проблемът е, че неговите данни (полета) са отворени за всички - друг програмист може лесно да създаде безименна котка с тегло 0 и възраст -1000 години:

public static void main(String[] args) {

   Cat cat = new Cat();
   cat.name = "";
   cat.age = -1000;
   cat.weight = 0;

}

Може би можете да следите внимателно дали някой от вашите колеги е създал обекти с невалидно състояние, но би било много по-добре да изключите дори възможността за създаване на такива "невалидни обекти". Следните механизми ни помагат да постигнем скриване на данни:

1. модификатори за достъп ( частен , защитен , пакет по подразбиране )
2. гетери и сетери

Например, можем да поставим отметка там, за да видим дали някой се опитва да присвои отрицателно число на възрастта на котката. Както казахме по-рано, авторите на различни статии за капсулирането понякога имат предвид комбинирането на данни и методи, or скриването им, or и двете (комбинирането и скриването им). Java има и двата механизма (това не е непременно вярно за други ООП езици), така че последното meaning е най-правилното. Капсулирането ни дава няколко важни предимства:

1. Контрол върху правилното състояние на обект. По-горе имаше примери за това. Сетер и частният модификатор гарантират, че нашата програма няма да има котки, чието тегло е 0.


2. Удобство за потребителя чрез интерфейс. Само методите са оставени "изложени" на външния свят. Извикването на методи е достатъчно, за да получите резултат — няма абсолютно ниHowва нужда да се задълбочавате в подробностите за това How работят.


3. Промените в codeа не засягат потребителите. Правим всички промени в методите. Това не засяга потребителя на метода: ако преди това правилният code е бил „auto.gas()“ за натискане на педала за газ, тогава той ще продължи да бъде. Фактът, че сме променor нещо в метода gas() остава невидим за потребителя: Howто преди, повикващият просто получава желания резултат.