Интерфейсы как тип абстрактного класса c
Перейти к содержимому

Интерфейсы как тип абстрактного класса c

  • автор:

Интерфейсы как тип абстрактного класса c

Один из принципов проектирования гласит, что при создании системы классов надо программировать на уровне интерфейсов, а не их конкретных реализаций. Под интерфейсами в данном случае понимаются не только типы C#, определенные с помощью ключевого слова interface , а определение функционала без его конкретной реализации. То есть под данное определение попадают как собственно интерфейсы, так и абстрактные классы, которые могут иметь абстрактные методы без конкретной реализации.

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

Когда следует использовать абстрактные классы:

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

Когда следует использовать интерфейсы:

  • Если нам надо определить функционал для группы разрозненных объектов, которые могут быть никак не связаны между собой.
  • Если мы проектируем небольшой функциональный тип

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

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

public abstract class Vehicle < public abstract void Move(); >public class Car : Vehicle < public override void Move() < Console.WriteLine("Машина едет"); >> public class Bus : Vehicle < public override void Move() < Console.WriteLine("Автобус едет"); >> public class Tram : Vehicle < public override void Move() < Console.WriteLine("Трамвай едет"); >>

Абстрактный класс Vehicle определяет абстрактный метод перемещения Move() , а классы-наследники его реализуют.

Но, предположим, что наша система транспорта не ограничивается вышеперечисленными транспортными средствами. Например, мы можем добавить самолеты, лодки. Возможно, также мы добавим лошадь — животное, которое может также выполнять роль транспортного средства. Также можно добавить дирижабль. Вобщем получается довольно широкий круг объектов, которые связаны только тем, что являются транспортным средством и должны реализовать некоторый метод Move() , выполняющий перемещение.

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

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

public interface IMovable < void Move(); >public abstract class Vehicle : IMovable < public abstract void Move(); >public class Car : Vehicle < public override void Move() =>Console.WriteLine("Машина едет"); > public class Bus : Vehicle < public override void Move() =>Console.WriteLine("Автобус едет"); > public class Hourse : IMovable < public void Move() =>Console.WriteLine("Лошадь скачет"); > public class Aircraft : IMovable < public void Move() =>Console.WriteLine("Самолет летит"); >

Теперь метод Move() определяется в интерфейсе IMovable, а конкретные классы его реализуют.

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

Например, солнце, костер, батарея отопления и электрический нагреватель выполняют функцию нагревания или излучения тепла. По большому счету выделение тепла — это единственный общий между ними признак. Можно ли для них создать общий абстрактный класс? Можно, но это не будет оптимальным решением, тем более у нас могут быть какие-то родственные сущности, которые мы, возможно, тоже захотим использовать. Поэтому для каждой вышеперечисленной сущности мы можем определить свою систему классификации. Например, в одной системе классов, которые наследуются от общего астрактного класса, были бы звезды, в том числе и солнце, планеты, астероиды и так далее — то есть все те объекты, которые могут иметь какое-то общее с солнцем состояние. В рамках другой системы классов мы могли бы определить электрические приборы, в том числе электронагреатель. И так, для каждой разноплановой сущности можно было бы составить свою систему классов, исходяющую от определенного абстрактного класса. А для общего действия определить интерфейс, например, IHeatable, в котором бы был метод Heat, и этот интерфейс реализовать во всех необходимых классах.

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

Абстрактные классы и интерфейсы

От абстрактных классов и интерфейсов нельзя создавать объекты. Они служат своего рода шаблонами для обычных классов.

Абстрактный класс – это некое обобщение. Например, не существует конкретного объекта, напрямую созданного от класса Млекопитающие. Класс Млекопитающие – обобщение, абстракция. От этого класса создаются дочерние классы – отряды, и только от них уже создаются объекты. Абстрактный класс отвечает на вопрос «что чем является». Например, парнокопытные являются млекопитающими.

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

Один класс может использовать несколько интерфейсов. Этим объясняется их популярность в Java, так как здесь отсутствием множественное наследование классов.

В Java, чтобы объявить класс абстрактным, надо в заголовке прописать слово abstract. Также обычно должен быть хотя бы один абстрактный метод. Рассмотрим пример:

public class AbstrTest  public static void main(String[] args)  UsualClass a = new UsualClass(); a.strPrint(); a.intPrint(); > > abstract class AbstrClass  abstract void strPrint(); void intPrint()  System.out.println(1); > > class UsualClass extends AbstrClass  void strPrint()  System.out.println("hi"); > >

В данном случае

  • Нельзя создавать объекты от класса AbstrClass, так как в его заголовке есть слово abstract. (Однако переменную такого типа можно было бы создать.)
  • Нельзя опустить реализацию метода strPrint() в классе UsualClass, поскольку он наследник абстрактного класса, в котором указанный метод объявлен абстрактным.
  • Абстрактные методы не имеют тел.
  • Если бы класс AbstrClass не содержал абстрактный strPrint(), или метод был бы не абстрактным, то в UsualClass можно было бы не переопределять данный метод. Таким образом, объявляя абстрактные методы, мы заставляем дочерние классы придерживаться определенного стандарта.
  • Абстрактный класс может не иметь абстрактных методов. Отличие такого класса от обычного родительского только в том, что от него нельзя создавать объекты.

При определении интерфейсов вместо class пишется ключевое слово interface. Если есть родительские интерфейсы, они также как в случае классов перечисляются после слова extends. У интерфейсов не может быть родительских классов.

Поскольку все методы интерфейсов по умолчанию абстрактные и публичные, перед их именами не требуется писать соответствующих модификаторов.

Если класс использует интерфейс, имя интерфейса указывается после слова implements (реализует). В случае наследования нескольких интерфейсов они перечисляются через запятую. Наследовать интерфейсы могут как обычные, так и абстрактные классы.

Если класс является наследником как другого класса, так интерфейса, в его заголовке сначала пишется extends имя_класса, затем implements имя_интерфейса.

. interface InterFace  String getStr(); > class UsualClass extends AbstrClass implements InterFace  void strPrint()  System.out.println("hi"); > public String getStr()  return "HI"; > >

Если не указать слово public в реализации метода getStr(), будет ошибка.

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

import java.util.ArrayList; public class ListObjects  public static void main(String[] args)  ArrayListAnimal> house = new ArrayList<>(); house.add(new Cat()); house.add(new Dog()); house.add(new Dog()); for (Animal animal : house)  animal.voice(); > > > abstract class Animal  abstract void voice(); > class Cat extends Animal  void voice()  System.out.println("Meow"); > > class Dog extends Animal  void voice()  System.out.println("Woof"); > >

Приведенная программа один раз мяукнет и два раза гавкнет, так как для каждого животного будет вызвана его реализация метода. Это также пример полиморфизма.

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

. interface Animal  void voice(); > class Cat implements Animal  public void voice()  System.out.println("Meow"); > > class Dog implements Animal  public void voice()  System.out.println("Woof"); > >

В Java над переопределяемыми методами принято писать аннотацию @Override. Так при взгляде на класс сразу понятно, что метод не определяется, а переопределяется.

В последних версиях языка Java в интерфейсах можно писать реализацию методов. Перед такими методами добавляется ключевое слово default:

interface Animal  void voice(); default void drink()  System.out.println("I drink!"); > >

X Скрыть Наверх

Программирование на Java. Курс

Интерфейсы как тип абстрактного класса c

На этом шаге мы приведем общие сведения об интерфейсах .

На предыдущих шагах мы познакомились с базовыми принципами использования абстрактных классов. Как уже несколько раз отмечалось, использование абстрактного класса в качестве базового позволяет создавать производные классы «по одному шаблону» — то есть с одинаковым набором свойств и методов. Вместе с тем здесь имеется один «тонкий момент». Дело в том, что в языке C# запрещено множественное наследование: мы не можем создать производный класс на основе сразу нескольких базовых.

Множественное наследование есть в языке C++ . В языке C++ у производного класса может быть несколько базовых классов. В языках Java и C# от множественного наследования отказались в целях безопасности.

Это не очень хорошо, поскольку часто возникает необходимость «объединить в одно целое» сразу несколько классов. Например, в языке C++ , ставшем «прародителем» для языка C# , такая возможность существует. Это полезная возможность, но одновременно это и небезопасная возможность. Ведь разные классы описывались независимо друг от друга. Их объединение в один класс может привести к конфликтным ситуациям. Поэтому в языке C# от технологии множественного наследования отказались. Вместо множественного наследования используется другая технология, связанная с реализацией интерфейсов.

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

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

interface имя < // Тело интерфейса >

Начинается описание интерфейса с ключевого слова interface , после которого указывается название интерфейса, а в блоке из фигурных скобок объявляются методы, индексаторы и свойства.

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

Для методов указывается только сигнатура: тип результата, название метода и список аргументов. Ключевое слово abstract не указывается, как и ключевое слово virtual . По умолчанию объявленные в интерфейсе методы (а также свойства и индексаторы) считаются абстрактными и виртуальными. Спецификатор уровня доступа также не указывается. Все методы (свойства, индексаторы), объявленные в интерфейсе, являются открытыми (то есть будто бы описанными с ключевым словом public , хотя оно явно не используется).

Свойства и индексаторы в интерфейсе объявляются с пустым телом, в котором указываются ключевые слова get и set . Наличие обоих ключевых слов (после каждого ставится точка с запятой) означает, что при описании у свойства и индексатора должно быть два аксессора. Можно указывать только одно ключевое слово, соответствующее аксессору, который должен быть у свойства или индексатора.

Интерфейс нужен для того, чтобы на его основе создавать классы. Если класс создается на основе интерфейса, то говорят, что класс реализует интерфейс. Реализация интерфейса в классе подразумевает, что в этом классе описаны все методы, свойства и индексаторы, которые объявлены в интерфейсе. Причем при описании методов, свойств и индексаторов в классе ключевое слово override не используется.

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

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

class имя: интерфейс < // Тело класса >

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

class имя: интерфейс1, интерфейс2, . интерфейсN < // Тело класса >

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

class имя: базовый класс, интерфейс1, интерфейс2, . интерфейсN < // Тело класса >

Если так, то в классе должны быть описаны все методы, свойства и индексаторы, объявленные в реализуемых интерфейсах, а если наследуемый базовый класс абстрактный — то и все абстрактные методы из базового класса.

На следующем шаге мы продолжим изучение этого вопроса .

Абстрактный класс или интерфейс?

Чем они отличаются между собой и в чём отличия?
В плане синтаксиса, интерфейс может содержать внутри себя только методы без реализации, свойства, события. В то время как абстрактный класс поддерживает функционал любого другого класса(поля, реализованные методы, делегаты, события, свойства, конструкторы. ), но запрещает создавать экземпляры своего типа. Также нужно помнить, что C# не поддерживает множественное наследование и, соответственно, унаследоваться от нескольких классов не получиться, а вот от нескольких интерфейсов — да.

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

Вот пару советов по определению нужного механизма:

  • Связь потомка с предком. Любой тип может наследовать только одну реализацию. Если производный тип не может ограничиваться отношением типа «является частным случаем» с базовым типом, нужно применять интерфейс, а не базовый тип. Интерфейс подразумевает отношение «поддерживает функциональность». Например, тип может преобразовывать экземпляры самого себя в другой тип (IConvertible), может создать набор экземпляров самого себя (ISerializable) и т. д. Заметьте, что значимые типы должны наследовать от типа System.ValueType и поэтому не могут наследовать от произвольного базового класса. В этом случае нужно определять интерфейс.
  • Простота использования. Разработчику проще определить новый тип, производный от базового, чем создать интерфейс. Базовый тип может предоставлять массу функций, и в производном типе потребуется внести лишь незначительные изменения, чтобы изменить его поведение. При создании интерфейса в новом типе придется реализовывать все члены.
  • Четкая реализация. Как бы хорошо ни был документирован контракт, вряд ли будет реализован абсолютно корректно. По сути, проблемы COM связаны именно с этим — вот почему некоторые COM-объекты нормально работают только с Microsoft Word или Microsoft Internet Explorer. Базовый тип с хорошей реализацией основных функций — прекрасная отправная точка, вам останется изменить лишь отдельные части.
  • Управление версиями. Когда вы добавляете метод к базовому типу, производный тип наследует стандартную реализацию этого метода без всяких затрат. Пользовательский исходный код даже не нужно перекомпилировать. Добавление нового члена к интерфейсу требует изменения пользовательского исходного кода и его перекомпиляции.

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

results matching » «

No results matching » «

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *