Каква е същността на програмни интерфейси

Linux системен администратор

Интерфейсът е всъщност правилата на взаимодействие.
Класът, който реализира интерфейса трябва да изпълни всички свои методи.
В интерфейса, който описват метод подписи, това означава, че се посочи, че наследник на класа трябва да бъде в състояние да направи, но той ще направи това, той решава за себе си.






Значи вие сте сигурни, че ако един клас изпълнява определен интерфейс, всички обекти от този клас са с определен набор от методи.
PLO - свят на абстракции :) Нека този, в себе си :) Интерфейси Йеше е една абстракция ни позволява да се разделят на описанието на realziatsii.

"Ела с правилното име на класа" - така че не може да направи на "наследниците" за изпълнение на функционалност.

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

p.s: програмисти ще допълнят и коригирани.

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

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

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

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

Kosvennnym плюс във всичко това е предвидимо поведение на обекта. Знаейки как да го реализира интерфейс, вие вече знаете нещо за поведението му.

Без интерфейс (като понятие) немислимо три от четирите основни концепции на обектно-ориентиран.

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

Да, това се прави, че е четимо код. Light програма, която не е много много реда код, не е твърде сложно за възприемане от човека, както и програми, които имат хиляди реда код, има съответно е необходимо да се разделят на файлове в един файл са условия на "какво да се прави?", А други "как да го направя "?.

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

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

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

Първо трябва да се разбере веднага, че интерфейсът е специален случай на клас. Но в Java, тя има една ключова дума, но C ++ е само един клас, без прилагане. Поради това, интерфейсът просто поставя стандарт за работа с един куп различни приложения.

Например, Iterable интерфейс казва, че класът реализира интерфейса са елементите и може да бъде повече от една линия в обадите следващия метод (). Това означава, че ако се създаде някакъв вид контейнер или събиране, можете да реализирате Iterable. Не е изобретяването на свои собствени методи за работа с контейнер. По този начин, има общ стандарт - интерфейс за работа с контейнери.

И ако се направи игра, можете да създадете Unit интерфейс, като по този начин за създаване на определени класове на поведение. Например, единица трябва непременно метод Atack (), isDead () и т.н.

И тогава, в цикъла направи проверка на всички звена:
линия (.) ако (unit.isDead ())
removeFromMap (единица);
>

И разбира звено може да бъде само един клас или абстрактен клас, който реализира Atack и isDead, но може да се isDead само, защото те атакуват всеки тип единица поотделно и изисква от собствените си изпълнение. Т.е. Ние стигаме до факта, че интерфейсът е също така специален случай на абстрактен клас.

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

И съответно, ако звеното ще имате клас или абстрактен клас, който наследява отдел в Java, можете просто да не даде и наследника Iterable поведение, ако Iterable също ще бъде клас.

OrcWarrior изпълнява Unit, Iterable - така че можете да

OrcWarrior простира Unit, Iterable - както в Java това е невъзможно, но е възможно в C ++, и звеното Iterable и след това винаги ще бъде обявена като клас.

Поради това, в Java не е добре дошъл наследство и състав. Т.е. това, което всеки път да реализира Unit.isDead, ако това е стандарт? Ето защо, тя създава един клас и да кажа UnitAI направи следното:

клас OrcWarrior изпълнява Unit, Iterable UnitAI ай;

интерфейс единица за невалидни атака ();
UnitAI гетите ();
>

Това се нарича състав, т.е. в OrcWarrior, HumanWarrior ви шунтиране UnitAI, която е била вече извършена isDead, и по този начин не е необходимо всеки път да го приложат същия код. В C ++, това не може да се направи, не е подкрепа за множествено наследяване, но тя има и своите недостатъци. Въпреки това, като съставът има плюсове / минуси.