Имплементация что это простыми словами в программировании

Что такое имплементация: значение, виды и сферы применения

Здравствуйте, уважаемые читатели блога KtoNaNovenkogo.ru. В XXI веке учёные стали чаще затрагивать в своих работах темы, связанные с глобализацией (это как?).

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

Что означает этот сложный термин? Как международное право соотносится с внутригосударственным? И как сами государства относятся к процессу сближения? Ответы на эти вопросы вы найдёте в статье.

Английское слово implementation официально переводится ООН (что это за организация?) как «осуществление». Впервые термин употребил Комитет по правам человека в 1981 году.

Первоначальное значение слова «имплементировать» – претворять что-либо в жизнь.

Например, идею, концепцию, документ.

Сейчас термин в основном применяется в двух сферах:

С точки зрения права, имплементация – это реализация на внутригосударственном уровне обязательств, закреплённых в международных соглашениях.

Например, главы двух государств подписывают конвенцию (что это такое?) о правовой помощи по уголовным делам.

А в дальнейшем стороны предпринимают следующие шаги:

Учёные-правоведы рассматривают термин в узком и широком значении.

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

А имплементация в программировании – что это? Если говорить простыми словами, выражение технологии, алгоритма или функции в исходном коде.

По сути, имплементировать – это реализовывать в ПО какой-либо функционал.

Виды имплементации в международном праве

В большинстве интернет-источников вы найдёте упоминание об инкорпорации, трансформации и отсылке. Однако правоведы выделяют и другие виды имплементации.

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

Некоторые учёные (в частности, В.А.Вдовин) делят имплементацию на общую и специальную.

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

Так, в ч. 4 ст. 15 Конституции записано, что составной частью правовой системы выступают общепризнанные принципы и нормы международного права, а также международные договоры РФ.

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

Какое право важнее: международное или национальное

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

На первый план выйдут проблемы, решение которых требует совместных усилий:

Это приведёт к превалированию международных норм права над национальными. Уже сейчас многие страны закрепили в основных законах положение о таком приоритете (это как?).

Согласно Конституции РФ, в случае противоречия закона и международного договора должны применяться положения последнего. Поэтому многие юристы пришли к выводу о примате международного права над национальным.

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

Заключение

Итак, имплементация – это практическая реализация внутри государства международно-правовых норм в целях исполнения взятых на себя обязательств.

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

Автор статьи: Белоусова Наталья

Удачи вам! До скорых встреч на страницах блога KtoNaNovenkogo.ru

Эта статья относится к рубрикам:

Комментарии и отзывы (1)

О боги, каких только замысловатых слов не придумают. Неужели нельзя как-то попроще всё называть. А это слово ещё попробуй выговори.

Источник

Название имплементации и название результата

Я хотел написать этот пост ещё в июле, но никак не мог, о ирония, решить, как его назвать. Удачные термины пришли мне в голову только после доклада Кейт Грегори на CppCon, и теперь я наконец могу рассказать вам, как не надо называть функции.

Пример 1: std::log2p1()

То есть для любого натурального числа функция возвращает его двоичный логарифм плюс 1, а для 0 возвращает 0. И это не школьная задачка на оператор if/else, это действительно полезная вещь — минимальное число бит, в которое поместится данное значение. Вот только догадаться об этом по названию функции практически невозможно.

Пример 2: std::bless()

Сейчас будет не про названия

Небольшое отступление: в С++ арифметика указателей работает только с указателями на элементы массива. Что, в принципе, логично: в общем случае набор соседних объектов неизвестен и “в десяти байтах справа от переменной i ” может оказаться что угодно. Это однозначно неопределённое поведение.

Но такое ограничение объявляет неопределённым поведением огромное количество существующего кода. Например, вот такую упрощённую имплементацию std::vector ::reserve() :

Мы выделили память, перенесли все объекты и теперь пытаемся убедиться, что указатели указывают куда надо. Вот только последние три строчки неопределены, потому что содержат арифметические операции над указателями вне массива!

Разумеется, виноват тут не программист. Проблема в самом стандарте C++, который объявляет неопределённым поведением этот очевидно разумный кусок кода. Поэтому P0593 предлагает исправить стандарт, добавив некоторым функциям (вроде ::operator new и std::malloc ) способность создавать массивы по мере необходимости. Все созданные ими указатели будут магическим образом становиться указателями на массивы, и с ними можно будет совершать арифметические операции.

Всё ещё не про названия, потерпите секундочку.

Название std::bless было временным.

Мне эти варианты не понравились.

Пример 3: std::partial_sort_copy()

Кейт утверждает, что std::partial_sort_copy — так себе название, и я с ней согласен.

Название имплементации и название результата

Ни одно из перечисленных названий не является, строго говоря, неверным: они все прекрасно описывают то, что делает функция. std::log2p1() действительно считает двоичный логарифм и прибавляет к нему единицу; implicitly_create_objects() имплицитно создаёт объекты, а std::partial_sort_copy() частично сортирует контейнер и копирует результат. Тем не менее, все эти названия мне не нравятся, потому что они бесполезны.

Точно так же никому не надо “имплицитно создавать объекты” или “проводить частичную сортировку копии вектора” — им нужно переиспользовать память или получить 5 наибольших значений в порядке убывания. Что-то типа recycle_storage() (что тоже предлагали в качестве названия std::bless ) и top_n_sorted() было бы гораздо понятнее.

Называть функцию на основании её спецификации — значит создавать на ровном месте непонимание между разработчиком библиотеки и её пользователем. Всегда нужно помнить, когда и как функция будет использоваться.

Пример 4: std::popcount()

С другой стороны, std::popcount() идеально подходит для этой функции, потому что она вызывает ассемблерную инструкцию popcount. Это не то что название имплементации — это полное её описание.

Тем не менее, в данном случае разрыв между разработчиками языка и программистами не так уж и велик. Инструкция, считающая количество единиц в двоичном слове, называется popcount с шестидесятых. Для человека, хоть сколько-нибудь разбирающегося в операциях с битами, такое название абсолютно очевидно.

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

Хэппи-энд?

Разумеется, std::partial_sort_copy() уже не переименуют — под этим названием она вошла в стандарт ещё в 1998. Но хотя бы std::log2p1 исправили, и то неплохо.

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

Источник

Имплементация катсцен и последовательностей действий в играх

В этом посте я расскажу о том, как можно имплементировать последовательности действий и катсцены в видеоиграх. Эта статья является переводом вот этой статьи и по этой же теме я делал доклад на Lua in Moscow, так что если вам больше нравится смотреть видео, то можете посмотреть вот здесь.

Код статьи написан на Lua, но легко может быть написан на других языках (за исключением метода, который использует корутины, т.к. они есть далеко не во всех языках).

В статье показывается, как создать механизм, позволяющий писать катсцены следующего вида:

Вступление

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

1. Открывается дверь
2. Персонаж заходит в дом
3. Дверь закрывается
4. Экран плавно темнеет
5. Меняется уровень
6. Экран плавно светлеет
7. Персонаж заходит в кафе

Последовательности действий также могут использоваться для скриптования поведения NPC или для реализаций битв с боссами, в которых босс выполняет какие-то действия одно за другим.

Проблема

Структура стандартного игрового цикла делает имплементацию последовательностей действий непростой. Допустим, у нас есть следующий игровой цикл:

Мы хотим имплементировать следующую катсцену: игрок подходит к NPC, NPC говорит:«You did it!», а затем после короткой паузы говорит:«Thank you!». В идеальном мире, мы бы написали это вот так:

И вот тут мы и встречаемся с проблемой. Выполнение действий занимает некоторое время. Некоторые действия могут даже ожидать ввода от игрока (например, чтобы закрыть окно диалога). Вместо функции delay нельзя вызвать тот же sleep — это будет выглядеть так, будто игра зависла.

Давайте взглянем на несколько походов к решению проблемы.

bool, enum, машины состояний

Самый очевидный способ для имплементации последовательностей действий — это хранить информацию о текущем состоянии в bool’ах, строках или enum’ах. Код при этом будет выглядеть примерно так:

Данный подход легко приводит к спагетти-коду и длинным цепочкам if-else выражений, так что я рекомендую избегать такой способ решения проблемы.

Action list

В катсцене, которую мы хотим реализовать, нам нужно имплементировать следующие действия: GoToAction, DialogueAction и DelayAction.

Для дальнейших примеров я буду использовать библиотеку middleclass для ООП в Lua.

Вот, как имплементируется DelayAction :

Функция ActionList:update выглядит так:

И наконец, имплементация самой катсцены:

Советую посмотреть презентацию Шона Миддлдитча (Sean Middleditch) про action list’ы, в которой приводятся более сложные примеры.

Action list’ы в целом очень полезны. Я использовал их для своих игр довольно долгое время и в целом был счастлив. Но и этот подход имеет недостатки. Допустим, мы хотим реализовать чуть более сложную катсцену:

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

Корутины Lua делают этот код реальностью.

Корутины

Основы корутин в Lua

Корутина — это функция, которую можно поставить на паузу и затем позже возобновить её выполнение. Корутины выполняются в том же потоке, как и основная программа. Новые потоки для корутин не создаются никогда.

Создание катсцен с помощью корутин

Вот, как будет выглядеть базовый класс Action в новой системе:

Подход похож на action list’ы: функция update действия вызывается до тех пор, пока действие не завершилось. Но здесь мы используем корутины и делаем yield в каждой итерации игрового цикла ( Action:launch вызывается из какой-то корутины). Где-то в update игрового цикла мы возобновляем выполнение текущей катсцены вот так:

И наконец, создание катсцены:

Вот, как реализована функция delay :

Создание таких врапперов значительно повышает читаемость кода катсцен. DelayAction реализован вот так:

Эта реализация идентична той, которой мы использовали в action list’ах! Давайте теперь снова взглянем на функцию Action:launch :

Давайте теперь посмотрим на функцию goTo :

Корутины отлично сочетаются с событиями (event’ами). Реализуем класс WaitForEventAction :

Просто и читаемо. Когда диалоговое окно закрывается, оно посылает событие с типом ‘DialogueWindowClosed`. Действие «say» завершается и своё выполнение начинает следующее за ним.

С помощью корутин можно легко создавать нелинейные катсцены и деревья диалогов:

Чуть более сложные примеры

С помощью корутин можно легко создавать туториалы и небольшие квесты. Например:

Корутины также можно использовать для AI. Например, можно сделать функцию, с помощью которой монстр будет двигаться по какой-то траектории:

Когда монстр увидит игрока, мы можем просто перестать выполнять корутину и удалить её. Поэтому бесконечный цикл ( while true ) внутри followPath на самом деле не является бесконечным.

Ещё с помощью корутин можно делать «параллельные» действия. Катсцена перейдёт к следующему действию только после завершения обоих действий. Например, сделаем катсцену, где девочка и кот идут к какой-то точке другу с разными скоростями. После того, как они приходят к ней, кот говорит «meow».

Можно сделать этот класс более мощным, если позволить синхронизацию N-ного количества действий.

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

Достоинства и недостатки корутин

Корутины — это очень полезный механизм. С помощью них можно писать катсцены и геймплейный код, который легко читается и модифицируется. Катсцены такого вида легко смогут писать моддеры или люди, которые не являются программистами (например, дизайнеры игр или уровней).

И всё это выполняется в одном потоке, поэтому нет проблем с синхронизацией или состоянием гонки (race condition).

У подхода есть недостатки. Например, могут возникнуть проблемы с сохранениями. Допустим, в вашей игре будет длинный туториал, реализованный с помощью корутин. Во время этого туториала игрок не сможет сохраняться, т.к. для этого нужно будет сохранить текущее состояние корутины (что включает весь её стек и значения переменных внутри), чтобы при дальнейшей загрузке из сохранения можно было продолжить выполнение туториала.

(Примечание: с помощью библиотеки PlutoLibrary корутины можно сериализовать, но библиотека работает только с Lua 5.1)

Эта проблема не возникает с катсценами, т.к. обычно в играх сохраняться в середине катсцены не разрешается.

Проблему с длинным туториалом можно решить, если разбить его на небольшие куски. Допустим, игрок проходит первую часть туториала и должен идти в другую комнату, чтобы продолжить туториал. В этот момент можно сделать чекпоинт или дать игроку возможность сохраниться. В сохранении мы запишем что-то вроде «игрок прошёл часть 1 туториала». Далее, игрок пройдёт вторую часть туториала, для которого мы уже будем использовать другую корутину. И так далее… При загрузке, мы просто начнём выполнение корутины, соответствующей части, которую игрок должен пройти.

Источник

Интерфейсы в ООП (Java), по-простому?

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

16 ответов 16

Общее определение: Интерфейс — это совокупность методов и правил взаимодействия элементов системы. Другими словами, интерфейс определяет как элементы будут взаимодействовать между собой.

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

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

Предположим, у вас в программе есть следующие типы:

а сейчас посмотрим, как можно пользоваться тем, что у нас есть:

Как видите, используем мы их одинаково, но суть кроется в реализации методов:

Вам может показаться странным, но это именно то, что отличает человека от животного — использование интерфейсов вместо классов. Вы наверняка помните классический опыт с обезьяной, которую приучили гасить огонь водой из ведёрка; а потом поставили ведёрко на плот посреди бассейна, но обезьяна всё равно бегала по мостику на плот и черпала воду из ведёрка, вместо того, чтобы черпать воду прямо из бассейна. То есть обезьянка использовала класс Вода-в-Ведёрке вместо интерфейса Вода (и даже больше, скажу по секрету: вместо интерфейса Средство-для-Тушения).

Когда мы мыслим классами — уподобляемся животным. Люди мыслят (и программируют) интерфейсами.

По простому говорите? Ну ок, правда сейчас тут начнут плеваться всякие товарищи типо гуру 🙂

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

Не будем оригинальны и возьмем для примера дверь.

Что обычный человек может сделать с дверью? Открыть и закрыть.

Соответственно интерфейс для нее будет такой:

А теперь следите за руками. Объекту человек нужно пройти через дверь. Важно ему какая дверь перед ним дверь, деревянная, железная, с окошком, открывается она на себя или от себя, а может вообще сдвигается в бок? Нет, не важно. Ему важно, чтобы ее в принципе можно было открыть.

По этому, в классе «Человек» мы принимаем в метод «Пройти через дверь» не какую-то конкретную дверь, а в принципе «Дверь», потому что знаем, что у нее есть метод «Открыть».

Соответственно ниже пример двух объектов, реализующие интерфейс «Дверь» и которые можно передать «Человеку» в метод «Пройти через дверь», но реализующие разную логику для метола «Открыть».

Интерфейсом** объекта мы назовём набор операций (методов), которые он может совершать или которые можно совершать над ним. Например, интерфейс числа 3 называется, собственно, «Число» и включает в себя набор операций сложения, вычитания, умножения и деления. Реализовать этот интерфейс может любое количество типов/классов, например, типы ЦелоеЧисло, ВещественноеЧисло, КомплексноеЧисло, а также такие неочевидные типы как Интервал или Полином. В то же время, один и тот же тип может реализовать более чем один интерфейс. Так, ЦелоеЧисло кроме интерфейса Число может реализовать интерфейс Перечислимый – для этого в классе ЦелоеЧисло будет необходимо всего лишь доопределить операции «следующий» и «предыдущий».

Объясню без деталей.

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

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

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

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

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

2) В Java в качестве ссылки на переменную может выступать интерфейс. Например, уместен следующий метод:

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

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

Источник

В чем разница между связями «Обобщение», «Реализация» и «Имплементация» на диаграмме классов UML?

Спецификацию UML касательно этого вопроса я понимаю следующим образом:

— связь generalization возникает между классами, когда один класс (наследник) основывается на другом классе (родителе). Судя по всему, здесь родительский класс обязательно должен быть конкретным классом (т.е. можно создавать его экземпляры).

— связь realization возникает между элементами диаграммы классов, когда один класс реализует поведение, определяемое другим классом. Скорее всего здесь речь идет о реализации поведения, определяемого интерфейсом или абстрактным классом.

— связь implementation — это подтип связи realization. Судя по всему, на одном конце связи — конкретный класс, а на другом — интерфейс (interface в Java, чисто виртуальный класс в C++).

Вопрос первый: насколько верна моя трактовка спецификации?
Вопрос второй: можно ли считать realization подтипом связи generalization?
Вопрос третий: если язык поддерживает множественное наследование (C++ например) и класс наследуется от двух конкретных классов — какая в таком случае связь между наследником и суперклассами?

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

Вопрос четвертый: может ли быть такое, что в одном случае наследование от абстрактного класса порождает связь generalization, а в другом случае — realization.

Трактовка не совсем верна, я сейчас изложу свое мнение, а уж сравнить наши взгляды задача не из простых)) Основная проблема различие понятий в UML и ООП.

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

Generalization. Когда у классов совпадает поведение, получается можно свести их интерфейсы к единому — обобщить. Диаграмма обобщения показывает сходство некоторого аспекта поведения и абсолютное сходство интерфейса.

Realization. Когда часть поведения объекта выносится в отдельный класс — это называется реализацией. В программировании такой прием обычно называют делегированием, но UML похоже считает иначе.

Implementation. В терминологии UML это как раз означает декомпозицию некого объекта на составные части. В программировании этот термин означает совсем другое…

Абсолютное сходство интерфейса в Generalization звучит убедительно, а главное очень хочется в это верить. Но напрягает момент, что зачастую в классах-наследниках появляются публичные методы, которых не было у родителя, а в коде можно встретить понижающее приведение типа (downcasting).

Implementation как декомпозиция объекта на составляющие мне тоже нравится. Только не понял, почему у тебя implementation в UML конфликтует с implementation в программировании. Если судить по синтаксису, например, Java или PHP, то для того, чтобы показать, что класс реализует интерфейс, используется именно ключевое слово implement. Один класс в свою очередь может реализовывать множество интерфейсов (например, IComparable, IMovable и IDrawable). Получается, что такой класс — это объединение решения нескольких задач внутри одного класса, интерфейс которого состоит из совокупности всех интерфейсов, им реализуемых ResultingClassInterface = . В таком случае, если теперь двигаться в обратном направлении, рассматривая класс, как единое целое и затем выделяя из него подзадачи с вынесением их в отдельный интерфейс — это и получится декомпозиция.
В мануале IBM по UML про связь implementation написано следующее: The implementation relationship specifies that the realizing classifier must conform to the contract that the provided interface specifies. Это выполняется by design во всех языках программирования, поддерживающих интерфейсы в таком виде, как они понимаются например в Java, PHP или C#.

В том же самом мануале про связь realization написано вот что: You can model the following situations using realization relationships:
A component is realized by a set of classifiers that provide its implementation. Вот это уже действительно похоже на то, что класс предоставляет своим клиентам абстракцию, складывающуюся из сервисов классов, с которыми он находится в отношении realization плюс возможно его собственные публичные методы. При этом не гарантируется, что новый класс будет на 100 % повторять интерфейсы классов, чью реализацию он представляет. Следовательно, никто не запрещает нам realization провернуть за счет делегирования и обойтись вовсе без наследования в этом случае. При этом внешний вид связи (пунктирная линия с пустым треугольником на конце) ничем не отличается от вида связи implementation и напоминает связь generalization, что меня вводит в заблуждение. Делегирование же в свою очередь обычно на диаграммах представляется связью association (собирательно название для agregation или composition). Рискну предположить, что связь realization должна использоваться вместо association при делегировании, когда ВСЕ методы класса, входящего в связь с одной стороны (service provider), имеют свое отражение в публичных методах класса на другой стороне связи (т.е. отношение между методами биективное).

Ну и пока не ясен для меня вопрос, как следует поступать, когда в приложении существует множество разношерстных по своему назначению классов + один интерфейс, который большинство из них (но не все!) должны реализовывать. Причем реализация эта в 99% случаев должна быть по умолчанию одинакова. Писать в каждом из классов реализацию — ад. Отнаследовать все эти класса системы от базового класс MyObject implements IInterface, в котором будет представлена реализация интерфейса по умолчания (а-ля C# или Java) — вроде перебор. И как при этом должна выглядеть диаграмма классов UML?

Сие есть очень занимательно… никогда так глубоко не рыл, и вот…
Даже по-русски «realization» и «implementation» переводятся как реализация — это я вроде знал, а в литературе такого разделения не встречал нигде. Поиск «realization» в вики ничего тоже не дел, что уже настораживает. А вот про implementation написано, что это есть realization 🙂

«Implementation is the realization of an application, or execution of a plan, idea, model, design, specification, standard, algorithm, or policy.»

Ладно, посчитаю, что это одно и то же.
Тогда имеем, что generalization — это просто наследование, не важно, от абстрактного класса или нет.
Implementation — реализация интерфейса (или чисто абстрактного класса).

Итого, про первый вопрос я не знаю, что сказать, но высказал свое мнение.
По второму — можно с некоторым уточнением, что это будет реализован (realized, implemnted) уже реальный метод, который в интерфейсе просто не мог быть реализован просто потому, что это интерфейс.
По третьему — тут будет просто несколько связей, в зависимости от типа — например если реализуется несколько интерфейсов — то будет несколько связей «implementation», то же касается и generalization.
По четвертому — если власс расширяет абстрактный и сам ничего не реализует (т.е. тоже является абстрактным), то тут просто не может быть реализации (implementation, realization) — т.е. тут чисто generalization. А если что-то реально реализуется — то тогда можно говорить о implementation (realization).

Источник