суббота, 1 января 2022 г.

Интерфейсы

Допустим, есть три экземпляра классов лошадь, машина, лодка. 

Все они могут реализовывать интерфейс "перевозка людей". 

И не важно, каким способом каждый из объектов это делает. 

Главное, что обязан делать. 

Когда надо "перевезти людей", по интерфейсу мы можем обратиться к тем объектам, которые его могут реализовать. 

Кроме того, интерфейсная ссылка, указывая на экземпляр класса, сохраняет его от сборки мусора, когда ссылок на него не осталось.

******************

Допустим, мы создали Framework, который определяет, совершил ли пользователь double-click по экрану.

Там мы определили функцию: что_делать_если_пользователь_кликнул_2_раза_по_экрану().

Но мы решаем не определять поведение этой функции сами, а предоставить эту реализацию программисту, использующему наш фреймворк. Предоставление этой реализации можно сделать через механизм интерфейсов.

Функцию: что_делать_если_пользователь_кликнул_2_раза_по_экрану() засовываем в интерфейс.

И, таким образом, сам момент двойного клика по экрану определяет наш фреймворк, а вот что делать (рисовать звездочки на экране, запустить проигрывание музыки и т.д.) после этого события решает программист, который реализует наш интерфейс.

Польза: программисту не надо думать, как словить double-click. За ним только реализация ответа на это событие.

*********************

Интерфейс это фактически регламент взаимодействия.
Класс который реализует интерфейс обязан реализовывать все его методы.
В интерфейсе вы описываете лишь сигнатуры методов, то есть вы указываете что класс наследник должен уметь делать, но как он будет это делать, тот решает сам.
Таким образом вы уверенны, что если класс реализует тот или иной интерфейс, все объекты данного класса имеют определенный набор методов.

***************************

Да, это сделано именно для восприятия человеком кода. Легкие программы, где не особо много строк кода, не сильно сложны для восприятия человека, а программы которые имеют тысячи строк кода, уже соответственно нужно разделять на файлы в одних файлах лежат условия "что нужно сделать?", а в других "как это сделать?".

Существует еще принцип модульности который говорит, что программа может быть разделена на модули или блоки. В блоке содержится заголовочный файлы и исполняющий файл о которых я говорил раньше.

Если программа огромная и вы об это знаете заранее, то её стоит разбить заранее на модули. Зачем или почему? Первая причина это воспринимаемость кода человеком, о котором уже шла речь, а второе будет намного легче найти ошибки в исходном коде, который вы будете писать и они будут.

P.S. Даже когда пишите что-то или задаете вопросы, можете разделять на блоки текста, как написал я, так воспринимается легче чем то, что написано в куче , не правда ли?

**********************


Комментариев нет:

Отправить комментарий

Паттерн 'Репозиторий' в ASP.NET

  Последнее обновление: 1.11.2015         Одним из наиболее часто используемых паттернов при работе с данными является паттерн 'Репозито...