Почему я должен идти на интерфейсы в C#, когда я могу реализовать методы напрямую



Я знаю, что это очень простой вопрос, но интервьюер задал мне очень хитрый способ, и я был беспомощен : (



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



Я тоже не понимаю одну вещь в интерфейсе. то есть, например, мы используем



conn.Dispose(); в блоке finally. Но я не вижу, что класс реализует или наследование IDisposable интерфейс (SqlConnection класс) я имею в виду. Мне интересно, как я могу просто назвать имя метода. Кроме того, я не понимаю, как работает метод Dispose, потому что нам нужно реализовать тело функции с нашей собственной реализацией для всех методов интерфейса. Итак, как интерфейсы принимаются или называются контрактами? Эти вопросы продолжали крутиться в моей голове до сих пор, и, честно говоря, я никогда не видел хорошей нити, которая объяснила бы мои вопросы так, как я могу понимать.



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



интервьюер сказал:



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



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

618   13  

13 ответов:

интерфейсы отличные, когда вы хотите создать что-то вроде этого:

 using System;

namespace MyInterfaceExample
{
    public interface IMyLogInterface
    {
        //I want to have a especific method that I'll use in MyLogClass
        void WriteLog();       
    }

    public class MyClass:IMyLogInterface
    {

        public void WriteLog()
        {
            Console.Write("MyClass was Logged");
        }
    }

    public class MyOtherClass :IMyLogInterface
    {

        public void WriteLog()
        {
            Console.Write("MyOtherClass was Logged");
            Console.Write("And I Logged it different, than MyClass");
        }
    }

    public class MyLogClass
    {
        //I created a WriteLog method where I can pass as parameter any object that implement IMyLogInterface.
        public static void WriteLog(IMyLogInterface myLogObject)
        {
            myLogObject.WriteLog(); //So I can use WriteLog here.
        }
    }

    public class MyMainClass
    {
        public void DoSomething()
        {
            MyClass aClass = new MyClass();
            MyOtherClass otherClass = new MyOtherClass();

            MyLogClass.WriteLog(aClass);//MyClass can log, and have his own implementation
            MyLogClass.WriteLog(otherClass); //As MyOtherClass also have his own implementation on how to log.
        }
    }
}

в моем примере, я мог бы быть разработчиком, который пишет MyLogClass, и другие разработчики, могут создавать свои классы, и когда они хотят войти, они реализуют интерфейс IMyLogInterface. Это как они спрашивали меня, что им нужно реализовать, чтобы использовать WriteLog() метод MyLogClass. Ответ они найдут в интерфейсе.

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

Почему Интерфейс

  • у вас нет реализации по умолчанию или общего кода
  • вы хотите поделиться контрактами данных (веб-службы, SOA)
  • у вас есть разные реализации для каждого реализатора интерфейса (IDbCommand и SqlCommand и OracleCommand которые реализуют интерфейс определенным образом)
  • вы хотите поддержка множественного наследования.

Почему Аннотация

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

  public void DoSomething(Account account) {
  // Do awesome stuff here.
}

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

public void DoSomething(IAccount account) {
  // Do awesome stuff here.
}

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

одним словом - из-за полиморфизм!

Если вы "программируете интерфейс, а не реализацию", то вы можете вводить в метод в качестве аргумента разные объекты, которые имеют один и тот же интерфейс(тип). Таким образом, ваш код метода не связан с какой-либо реализацией другого класса, что означает, что он всегда открыт для работы с вновь созданными объектами того же интерфейса. (Открыть/Закрыть Принцип)

  • посмотрите на инъекцию зависимостей и определенно читайте шаблоны проектирования-элементы многоразового объектно-ориентированного программного обеспечения by GOF.

enter image description here

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

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

C# не имеет duck typing-просто потому, что вы знаете, что определенный метод реализован в наборе конкретных классов, не означает, что вы можете относиться к ним одинаково в отношении вызова этого метода. Реализация интерфейса позволяет рассматривать все классы, реализующие его, как один и тот же тип вещи, в отношении того, что определяет этот интерфейс.

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

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

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

1) создать отдельные интерфейсы, которые предлагают различные сокращения вашей реализации, что позволяет более сплоченный интерфейс.

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

3) Вы можете версия и улей от вашего интерфейса независимо от вашей реализации, обеспечивая контракт является встретились.

4) Ваш код может полагаться на абстракцию, а не на конкрецию, что позволяет использовать интеллектуальную инъекцию зависимостей, включая инъекционные тестовые насмешки и т. д.

есть еще много причин, я уверен, это всего лишь несколько.

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

как абстрактный класс, так и интерфейс являются контрактами.

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

выбор абстрактного над interrface.

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

и

любой класс, реализующий интерфейс, реализует контракт.

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

Я считаю, что много крови уже пролилось, задавая эти вопросы, и многие пытаются решить эти проблемы, объясняя роботоподобные термины, которые не может понять ни один нормальный человек.

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

теперь давайте покопаемся в базе по ссылке, которую я уже дал.

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

public class clsBike:IChoice
{
   #region IChoice Members
    public string Buy()
    {
       return ("You choose Bike");
    }
    #endregion
}

и

public class clsCar:IChoice
{
   #region IChoice Members
    public string Buy()
    {
       return ("You choose Car");
    }
    #endregion
}

и у обоих есть контракт IChoice, который просто говорит, что мой класс должен иметь метод покупки

public interface IChoice
{
    string Buy();
}

теперь вы видите, что интерфейс только применять метод Buy() но пусть унаследованный класс решает, что делать, когда они реализуют его. Это ограничение интерфейса, используя чисто интерфейс, вы можете в конечном итоге повторить некоторые задачи, которые мы можем реализовать автоматически с помощью abstact. На нашем примере Пусть говорят, что покупка каждого автомобиля имеет скидку.

public abstract class Choice
{
    public abstract string Discount { get; }
    public abstract string Type { get; }
    public string Buy()
    {
       return "You buy" + Type + " with " + Discount;
}
public class clsBike: Choice
{
    public abstract string Discount { get { return "10% Discount Off"; } }
    public abstract string Type { get { return "Bike"; } }
}

public class clsCar:Choice
{
    public abstract string Discount { get { return " K Less"; } }
    public abstract string Type { get { return "Car"; } }
}

теперь, используя класс Factory, вы можете достичь того же, но при использовании абстрактного, вы позволяете базовому классу выполнять Buy() метод.

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

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

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

Как вы знаете, интерфейсы не могут иметь никакого кода, поэтому dis-vantage довольно прост для понимания.

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

поэтому в очень общем случае вы должны предпочесть абстрактный класс интерфейсам, когда вам нужно предоставить клиенту конструктор или любой код, который будет наследовать/расширять ваш класс

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

будет выглядеть следующим образом

   Interface             
   ____|____
  |        |
Animal   Human



  Animal (Abstract class)
   __|___
  |      |
Tiger   Lion

Comments

    Ничего не найдено.