пятница, 25 октября 2013 г.

Протоколы vs интерфейсы

По мотивам - http://18delphi.blogspot.ru/2013/10/interlockedincrementinterlockeddecrement.html?showComment=1382650171837#c3431462197280892242

Протоколы vs интерфейсы.

Это кстати - ГЕНИАЛЬНАЯ идея.

На месте разработчиков компиляторов/языков я бы к ней прислушался бы.

TmyObject = class(TParent, IInterface)
end;

vs.

TmyObject = class(TParent, protocol PProtocol)
end;

Что в итоге?

Supports(myObject, IInterface, l_Interface);
-- тут взводится счётчик ссылок..

GetProtocol(myObject, PProtocol, l_Protocol); (и БЕЗ ВСЯКИХ QueryInterface, только лишь аналог GetInterface)
-- тут НЕ взводится счётчик ссылок.. Да и - НЕЗАЧЕМ.

Объяснять - ПОЧЕМУ?

P.S. Duck-typing только БЕЗ Duck-typing'а. ДАВНО мне такого не хватает.

6 комментариев:

  1. >>Объяснять - ПОЧЕМУ?

    Обязательно!

    Хороша ли неявная типизация? Является ли она следствием невозможности (во всех смыслах) воссоздать наследственную связь понятий?

    Т.е. мы, знатоки кода, отказываем человеческому разуму в способности применить отображение реального мира на картину в сознании относительно программных единиц?

    Я бы даже сказал, что "не объяснять", а "иллюстрировать" надо. Проблематика инженерных практик в том, чтобы "палкой и верёвкой" решить текущие задачи функциональной поддержки. Я уже боролся с этим :)

    Определение "потребительских" качеств объекта по формальным признакам важно. Будет ли этим формальным набором "генетика" класса объекта, соответствие сигнатуре, доливом интерфейса или поддержкой некого протокола - вопрос красоты реализации в контексте разработке и сопровождения кода. Полезность красоты подтверждается сокращением времени в рамках компетенции конкретного специалиста - вот главный вопрос. Если по иерархии сознание "скользит" в рамках привычных схем (включая поддерживающие графические нотации), то неявная типизация порождает некие кульбиты мозга. Выходит на поверхность задача "распознавания". Оно нам надо?
    Ответ в конкретном примере, если Вы, Александр, дадите нам ситуацию применения.

    Пока ситуация выглядит так. Сначала мы с головой окунаемся в разрушение иерархий (=отказ от графичеких нотаций, иначе как неявная типизация будет выглядеть? если она динамическая и не определяется структурой кода - что будем рисовать? пунктирную линию в никуда?). Потом придумываем методы проверки этой типизации. Потом сетуем на то, что отсутствуют стандартные методы решения коррекции проблем в мышлении?

    Я начинаю думать о полезности разделения моделей по функциональному признаку - пусть будет MVC. Пусть интерфейсное (пользовательско-интерфейсное) представление будет "объект, как пользователь его видит", а где-то глубоко в памяти (компьютера) будет "объект, как он представляется относительно предметной области".

    И далее выплывает другой момент: а что главнее? То, как потребитель видит оъект И управляет его поведением, или же квази-реальный объект? Может, тогда не стоит "надумывать", а реально физиологически задавать жёсткие конструкции?

    Или суть поста - лишь побороть "взведение ARC-а"? Мы оставляем право взвести курок, но не производить выстрел?


    ОтветитьУдалить
    Ответы
    1. Всеволод, отвечу. Чуть позже. Много вопросов задали. А я сейчас "в другом мире". Мире xCode. Сложно мозги переключать. Я немного написал в блоге. Но это далеко не полный ответ.

      Удалить
    2. "Или суть поста - лишь побороть "взведение ARC-а"?"
      -- суть поста - СОВСЕМ не в этом.

      Удалить
    3. "Я начинаю думать о полезности разделения моделей по функциональному признаку - пусть будет MVC. Пусть интерфейсное (пользовательско-интерфейсное) представление будет "объект, как пользователь его видит", а где-то глубоко в памяти (компьютера) будет "объект, как он представляется относительно предметной области". "

      Логично :-) Если я правильно вас понял :-)

      Удалить
    4. "Определение "потребительских" качеств объекта по формальным признакам важно. Будет ли этим формальным набором "генетика" класса объекта, соответствие сигнатуре, доливом интерфейса или поддержкой некого протокола - вопрос красоты реализации в контексте разработке и сопровождения кода. Полезность красоты подтверждается сокращением времени в рамках компетенции конкретного специалиста - вот главный вопрос. Если по иерархии сознание "скользит" в рамках привычных схем (включая поддерживающие графические нотации), то неявная типизация порождает некие кульбиты мозга. Выходит на поверхность задача "распознавания". Оно нам надо?"

      Во-первых - про НЕЯВНУЮ типизацию - никто не говорил. Говорил как раз про ЯВНУЮ. :-)
      Во-вторых - ДАЖЕ НЕЯВНАЯ типизация на чертежах (слово UML - с некоторых пор - я стараюсь изживать из лексикона) - рисуется.
      В-третьих - я вот ОТНЮДЬ НЕ СТОРОННИК неявной типизации :-) Скорее - противник. Она да - где-то решает "локальные задачи". Но ставить "во главу архитектуры" её как в xCode или Python - считаю ПРИНЦИПИАЛЬНОЙ ошибкой.

      Кстати - проще бы встретиться :-) Я вот коллеге сегодня тезисы в курилке за 5 мин изобразил.

      Удалить
    5. "если она динамическая и не определяется структурой кода - что будем рисовать? пунктирную линию в никуда?"

      Ещё "куда КУДА" :-) считайте это "вбросом" :-)

      Удалить