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

Автор Dmitry dziuba задал вопрос в разделе Другие языки и технологии

Чем отличается имплементация от наследования? =) Программирование. Чем отличается имплементация от наследования? и получил лучший ответ

Ответ от Ирина В[гуру]
Имплементация: это реализация методов, те. то, что фактически работает в классе. А наследование, это создание нового класса на основе старого, при этом реализация методов может отличаться, от базового класса.
Но чаще, слово имплементация употребляют для интерфейсов: это то, что может делать интерфейс, и методы, и свойства.

Имплементация чего-то (какого-либо
подробнее.

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

Общее понятие

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

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

Три способа

Понять, что значит «имплементация», поможет изучение способов ее осуществления.

К таким способам относят:

  1. Инкорпорацию.
  2. Трансформацию.
  3. Отсылки: общую, частную, конкретную.
  • В результате применения способа инкорпорации международные нормы воспроизводятся дословно, без всяких изменений в законодательство государства, которое их имплементирует.
  • В случае трансформации при внедрении международных норм, прописанных в договоре, в национальное законодательство осуществляется некоторая их переработка. Как правило, это практикуется, когда есть необходимость учитывать национальные стандарты юридической техники и правовые традиции.
  • Когда используют отсылки, подразумевается, что содержание международных норм не включается в сам текст закона. В нем лишь содержится указание на них. Тем самым предполагается, что применение национальных правовых норм невозможно без обращения к первоисточнику, то есть к тексту международного документа.

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

Международно-правовой механизм

Он представляет собой комплекс международных средств, в который входят:

  1. Система конференций, органов и организаций, других структур международного характера, обеспечивающих внедрение международных норм. Например, реализация норм Концепции по морскому праву, подписанной в 1982 году, производится Международным трибуналом по морскому праву.
  2. Совокупность норм МП, которые содействуют реализации прочих международных договоренностей. В качестве примера можно привести прецедент, когда в 1987 году Советский Союз и Соединенные Штаты подписали договор, предусматривающий ликвидацию ракет средней и малой дальности. При этом также были заключены соглашения СССР с рядом государств об инспекциях, связанных с договором, среди которых были Бельгия и Италия.

В завершение изучения вопроса о значении слова «имплементация» рассмотрим второй механизм.

Национально-правовой механизм

В него входит совокупность внутригосударственных средств, которые призваны обеспечивать реализацию норм МП. К ним относятся:

  1. Система органов, принимающих участие в имплементации международных норм. Например, Министерство юстиции РФ – центральный орган РФ, который в соответствии с Указом Президента от 2004 года несет ответственность в вопросе обеспечения реализации норм Конвенции ООН, направленной против транснациональной оргпреступности, от 2000 года.
  2. Свод установлений национального права, которые обеспечивают эффективность осуществления норм МП внутри страны. Например, закон от 2006 года № 40-ФЗ, регулирующий процесс ратификации и имплементации Конвенции ООН по противодействию коррупции.

Не могу понять, как проходит (и есть ли она) тонкая грань между следующими типами связей на диаграмме классов UML:

  • generaliztion (обобщение)
  • realization (реализация)
  • implementation (имплементация)

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

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

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

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

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

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

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

  • Вопрос задан более трёх лет назад
  • 12772 просмотра

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

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

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

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

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

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

Implementation как декомпозиция объекта на составляющие мне тоже нравится. Только не понял, почему у тебя implementation в UML конфликтует с implementation в программировании. Если судить по синтаксису, например, Java или PHP, то для того, чтобы показать, что класс реализует интерфейс, используется именно ключевое слово implement. Один класс в свою очередь может реализовывать множество интерфейсов (например, IComparable, IMovable и > В мануале 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).