Контракт на интерфейс, как объект на класс?
Зачем нужно различать подобные вещи, от кода до исполняемого кода? Я как бы понял идею наименования класса как класса, а созданного экземпляра исполняющего класса - как объекта, но в целом, является ли это единственной причиной этих полубезбыточных терминов?
Не совсем. Здесь четыре термина, поэтому я рассмотрю каждый из них:
Интерфейс - это абстрактный класс (в таких языках, как Java, где нет множественного наследования, иногда есть другие ограничения, такие как отдельный тип данных), который предназначен для использования в качестве общей базы для доступа к ряду объектов с аналогичным поведением. . Концептуально абстрактность не требуется, но обычно интерфейс имеет хотя бы один абстрактный метод. Интерфейс - это метод взаимодействия вашей программы с рядом похожих классов, каждый с разной семантикой, но с одним и тем же общим назначением.
Контракт - это неявное соглашение, которое вы заключаете между пользователями и разработчиками класса или интерфейса. Например, предусловия и постусловия (инварианты обычно представляют собой контракт внутри реализации класса - как правило, такие вещи, как отношения между внутренними членами, не нужно раскрывать). Спецификация возвращаемого значения или аргумента также может быть частью контракта. Он в основном представляет, как использовать функцию / класс / интерфейс, и обычно не может быть полностью представлен на каком-либо языке (некоторые языки, такие как Eiffel, позволяют вставлять явные контракты, но даже они не всегда могут полностью конкретизировать требования. ). Когда вы реализуете интерфейс или производите от класса, вы всегда должны соответствовать требованиям интерфейса или, при переопределении неабстрактного класса, вести себя достаточно похоже, чтобы внешний просмотрщик не заметил разницы (это Лисков Принцип подстановки; производный объект должен иметь возможность заменять основание без каких-либо различий в поведении с внешней точки зрения).
Класс не требует частого повторения, поскольку вы явно уже использовали их раньше. Класс - это тип данных, а в некоторых языках - это надмножество интерфейсов (которые не имеют формального определения, как в C ++), а в других - независимые (например, в Java).
Объект - это экземпляр типа класса (или, как правило, любого типа, не являющегося классом). Точное определение объекта очень специфично для языка, но общее определение - это реальная вещь, на которую ссылаются несколько ссылок / указателей на одно и то же - например, в некоторых языках, таких как Java, == сравнивает, являются ли две переменные один и тот же объект, не обязательно, являются ли они семантически одинаковыми. Объекты не зависят от классов или интерфейсов - они представляют собой единственный экземпляр. Другой способ думать об этом заключается в том, что класс или интерфейс - это форма, а объект - это физический объект, который выходит из формы (довольно плохая аналогия, но это лучшее, что я могу придумать прямо сейчас).
interface и abstract class похожи, но это разные концепции; они не совпадают и не всегда могут использоваться как взаимозаменяемые.
- person iliketocode; 07.07.2018
Нет, не совсем. Класс - это шаблон, который вы определяете. Каждый объект, который создает этот класс, следует шаблону. На самом деле это не лишние термины, потому что эти два понятия не идентичны. Вы можете думать о классе как о типе данных, определяемом пользователем. Классы и объекты отличаются друг от друга точно так же, как примитивный тип данных int отличается от буквального значения 3.
Интерфейс определяет набор методов, которые должны поддерживать все реализующие классы. Сам интерфейс - это контракт, который вы определяете для реализующих классов. Он просто говорит, что любой класс, реализующий интерфейс, должен иметь набор общедоступных методов этого интерфейса.
Ну, я думаю ... если интерфейс определяет контракт, чем класс определяет (или несколько) экземпляров определенного объекта.
Однако терминология менее важна, чем применение.
На самом деле интерфейс - это контракт, когда объект является экземпляром класса - это разные вещи, у которых не так много общего.
Интерфейс просто обеспечивает фасад для объектов или гарантию для вызывающего объекта, что объект может выполнять некоторую операцию, даже не зная об ее реализации.
Например, у вас может быть два класса, реализующих один и тот же интерфейс / контракт, но выполняющие совершенно разные вещи (хотя смысл их выполнения может быть одинаковым).
Возьмем, к примеру, интерфейс IDisposable: каждый объект может освобождать ресурсы, которые он использует, но может делать это по-разному, он может ничего не освобождать. Выбор объекта.
По крайней мере, это будет POV в .NET.
Чтобы завершить предыдущие ответы, несколько слов об интерфейсах:
Если класс представляет собой нечто большее, чем шаблон для объекта (из-за его глобальных характеристик, не зависящих от каких-либо экземпляров), интерфейс также можно описать как точку зрения
Класс, реализующий несколько интерфейсов:
«Точка зрения» означает, что вы можете использовать объект, сосредоточившись исключительно на контракте, определяемом этим интерфейсом.
Именно в этом аспекте интерфейс является «абстрактным классом», как и «абстракцией» (что-то, что принимает некоторые характеристики класса, но не учитывает другие). В мире Java интерфейс оставляет на самом деле многое, поскольку его можно применять, например, только для определения контракта, а не для статических методов или функций.
«Класс» и «Объект» представляют две разные вещи; они связаны, но то, что они представляют, совершенно разное.
Лучший способ описать это - посмотреть на Static. Класс может иметь статические члены, которые полностью отделены от любого ЭКЗАМЕНА этого класса. Объекты этого класса могут использовать или не использовать эти статические члены; но экземпляр объекта этого класса полностью отделен от любого статического использования этого класса (или должен быть, по крайней мере).
Или подумайте о шаблоне singleton. Сохранение экземпляра объекта класса в методе доступа статического класса - обычная практика, и это показывает разницу. Вы обращаетесь к статическому аксессору класса, чтобы получить экземпляр объекта одноэлементного класса; если статический член класса не имеет экземпляра объекта для ссылки, класс создает экземпляр объект.
Перефразируй; объект является экземпляром класса; но класс может быть больше, чем просто шаблон, из которого создаются объекты. Статические члены классов имеют представление в памяти, которое полностью не зависит от экземпляров объектов этих классов.
