Съществуват интерфейси за поддържане на конкретно поведение

"Здравей, Амиго! Днес бих искал да ти кажа причините, поради които интерфейсите съществуват. Често чуваш, че определен клас, обект or обект поддържа определен интерфейс. Какво означава да поддържаш интерфейс ? "

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

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

1) Всеки интерфейс , точно като клас , има уникално име. И двете страни могат да бъдат 100% сигурни, че другата страна поддържа точния интерфейс, който познават, а не няHowъв подобен интерфейс.

2) Всеки интерфейс налага определени ограничения върху клас, който ще го поддържа. Класът (неговият разработчик) решава Howво ще прави, когато бъдат извикани методите, наследени от даден интерфейс, но резултатът трябва да бъде в границите на разумните очаквания. Ако наредим на куче да „седне“ и след това то се търкаля на място в продължение на 5 minutesи и след това седне, тогава то поддържа интерфейса. Но ако instead of това ви хване за крака, едва ли можем да кажем, че поддържа интерфейса. Изпълнението на командата не доведе до очаквания резултат.

Да приемем, че вие ​​и вашите приятели пишете компютърна игра. И ти беше назначено да програмираш поведението на един герой. Един от вашите колеги вече е написал code за показване на всички знаци на екрана. Втори колега, който отговаря за запазването на играта на диск, е написал code за запазване на всички обекти на играта във файл. Всеки от тях е написал много code и е направил интерфейс за взаимодействие с този code. Например може да изглежда така:

interface Saveable
{
 void saveToMap(Map<String, Object> map);
 void loadFromMap(Map<String, Object> map);
}

interface Drawable
{
 void draw(Screen screen);
}

class PacMan implements Saveable, Drawable
{
…
}

С други думи, за да поддържа всеки интерфейс (група от интерфейси), вашият клас трябва:

1) Наследете ги

2) Имплементирайте декларираните в тях методи

3) Методите трябва да правят това, за което са предназначени.

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

„Защо codeът не знае нищо за моя клас?“

„Да приемем, че сте взели codeа от програма, която някой е написал преди година. Или да предположим, че вашите приятели са закупor/лицензирали двигателя на играта от някой друг. Имате работещ code за играта. Хиляди обекти, които взаимодействат един с друг. И те може лесно да взаимодейства правилно с вашите обекти, ако направите това взаимодействие да се случи чрез интерфейси, които вашите класове са внедрor правилно."

"Далеч! Не знаех, че това е възможно."

"Всички големи проекти работят така. Хората отдавна спряха да пишат от нулата."

Хората също така не преоткриват математиката и азбуката всеки път. Вместо това те изучават всичко, което е измислено преди тях.