Является ли контракт для интерфейса как объекта классу?
В чем заключается необходимость различать идентичные вещи, например, от кода до исполняемого кода? Я как бы понимаю идею присвоения классу класса и экземпляра исполняемого класса объекту, но в целом это единственная причина для этих полу-избыточных терминов?
Не совсем. Здесь есть четыре условия, поэтому я рассмотрю каждый из них:
Интерфейс представляет собой абстрактный класс (в таких языках, как Java, где нет множественного наследования, иногда существуют другие ограничения, такие как отдельный тип данных), который предназначен для использования в качестве общей базы для доступа к ряду аналогичных -обновление объектов. Концептуально, нет требования к абстрактности, но обычно интерфейс имеет хотя бы один абстрактный метод. Интерфейс - это метод, позволяющий вашей программе взаимодействовать с рядом подобных классов, каждый из которых имеет разную семантику, но имеет ту же общую цель.
Контракт - это неявное соглашение, которое вы делаете между пользователями и разработчиками класса или интерфейса. Например, предварительные условия и постусловия (инварианты обычно являются контрактом внутри реализации класса), как правило, такие вещи, как отношение между внутренними членами, не нужно раскрывать). Спецификация возвращаемого значения или аргумента также может быть частью контракта. Он в основном представляет, как использовать функцию/класс/интерфейс и вообще не может быть полностью представлен на любом языке (некоторые языки, например Eiffel, позволяют вам заключать явные контракты, но даже они не всегда могут полностью удовлетворить требования). Когда вы реализуете интерфейс или извлекаете из класса, вы всегда должны удовлетворять требованиям интерфейса или, переопределяя не-абстрактный класс, вести себя настолько же, что внешний зритель не замечает разницы (это Лисков Принцип замещения, производный объект должен быть способен заменить базу без различия в поведении с внешней точки зрения).
Класс не нуждается в большом переходе, поскольку вы явно использовали их раньше. Класс - это тип данных, а на некоторых языках - это надмножество интерфейсов (которые не имеют формального определения, как в С++), а в других - независимы (например, в Java).
Объект - это экземпляр типа класса (или любого неклассического типа, обычно). Точное определение объекта очень специфично для языка, но общее определение - это фактическая вещь, на которую ссылаются несколько ссылок/указателей на одно и то же - например, на некоторых языках, таких как Java, == сравнивает, являются ли две переменные тот же объект, не обязательно, являются ли они семантически одинаковыми. Объекты не зависят от классов или интерфейсов - они представляют собой один экземпляр. Другой способ думать о том, что класс или интерфейс - это форма, а объект - физический объект, который выходит из формы (довольно плохая аналогия, но это лучшее, что я могу придумать прямо сейчас).
Нет, не совсем. Класс - это шаблон, который вы определяете. Каждый объект, который создает экземпляр этого класса, следует шаблону. Они не являются излишними условиями, потому что две вещи не идентичны. Вы можете рассматривать класс как пользовательский тип данных. Классы и объекты отличаются друг от друга точно так же, как и примитивный тип данных int отличается от литерального значения 3.
Интерфейс определяет набор методов, которые должны поддерживаться всеми реализующими классами. Сам интерфейс - это контракт, который вы определяете для реализующих классов. Он просто говорит, что любой класс, реализующий интерфейс, должен иметь этот набор интерфейсов общих методов.
Ну, я думаю... если интерфейс указывает контракт, чем класс, указывает (или несколько) экземпляр конкретного объекта.
Терминология менее важна, чем приложение.
На самом деле, интерфейс - это контракт, когда объект является экземпляром класса - это разные вещи, которые не имеют слишком много общего.
Интерфейс просто предоставляет фасад для объектов или гарантию для вызывающего, что объект может выполнять некоторую операцию, даже не зная его реализации.
Например, вы можете иметь два класса, реализующих один и тот же интерфейс/контракт, но делать разные вещи (хотя смысл их выполнения может быть одинаковым).
Возьмите интерфейс IDisposable, например: каждый объект может освободить ресурсы, которые он использует, но он может делать это разными способами, он может выбрать не выпускать ничего. Это выбор объекта.
По крайней мере, это будет POV в .NET.
Для завершения предыдущих ответов слово об интерфейсах:
Если класс больше, чем шаблон для объекта (из-за его глобальных характеристик, не зависящих от каких-либо экземпляров), интерфейс можно также описать как точку зрения
Класс, реализующий несколько интерфейсов:
"Точка зрения" означает, что вы можете использовать объект, фокусируясь исключительно на контракте, определяемом этим интерфейсом.
Именно в этом аспекте интерфейс является "абстрактным классом", как в "абстракции" (что-то, что берет за некоторые характеристики класса, но оставляет других). В java-интерфейсе интерфейс практически не работает, поскольку он может применяться только для определения контракта, а не для статических методов или функций.
"Класс" и "Объект" представляют две разные вещи; они связаны друг с другом, но то, что они представляют IS разные, довольно сильно.
Лучший способ описать это - посмотреть на Static. Класс может иметь статические члены, которые полностью отделены от любой INSTANCE этого класса. Объекты этого класса могут или не могут использовать эти статические элементы; но экземпляр объекта этого класса полностью отделен от любых статических применений этого класса (или должен быть, по крайней мере).
Или подумайте об одноэлементном шаблоне. Хранение экземпляра объекта класса в статическом аксессуаре класса является обычной практикой и показывает разницу. Вы ссылаетесь на статический аксессор класса, чтобы получить экземпляр объекта одного класса; если class static member не имеет экземпляра объекта для ссылки, класс создает экземпляр объект.
Поставьте другой путь; объект есть экземпляр класса; но класс может быть больше, чем просто шаблон, из которого создаются объекты. Статические члены классов имеют представление в памяти, которое полностью не зависит от экземпляров объектов этих классов.