Що мають на увазі програмісти, коли кажуть: "Код проти інтерфейсу, а не об'єкта"?

Question 1

Я розпочав дуже довгий і важкий пошук, щоб вивчити та застосувати TDD до свого робочого процесу. У мене складається враження, що TDD дуже добре відповідає принципам IoC.

Переглянувши деякі запитання з тегами TDD у SO, я прочитав, що непогано програмувати проти інтерфейсів, а не об’єктів.

Чи можете ви навести прості приклади коду, що це таке, і як застосовувати його у реальних випадках? Прості приклади є ключовим для мене (та інших людей, які хочуть вчитися), щоб зрозуміти ці поняття.

Question 2

Розглянемо:

class MyClass
{
    //Implementation
    public void Foo() {}
}

class SomethingYouWantToTest
{
    public bool MyMethod(MyClass c)
    {
        //Code you want to test
        c.Foo();
    }
}

Оскільки MyMethodприймає лише a MyClass, якщо ви хочете замінити MyClassна макетний об’єкт для модульного тестування, ви не можете. Краще використовувати інтерфейс:

interface IMyClass
{
    void Foo();
}

class MyClass : IMyClass
{
    //Implementation
    public void Foo() {}
}

class SomethingYouWantToTest
{
    public bool MyMethod(IMyClass c)
    {
        //Code you want to test
        c.Foo();
    }
}

Тепер ви можете протестувати MyMethod, оскільки він використовує лише інтерфейс, а не конкретну конкретну реалізацію. Тоді ви можете застосувати цей інтерфейс, щоб створити будь-який макет чи підробку, яку ви хочете для тестових цілей. Існують навіть такі бібліотеки, як Rhino Mocks ' Rhino.Mocks.MockRepository.StrictMock<T>(), які беруть будь-який інтерфейс і створюють вам макетний об’єкт на льоту.

Question 3

Все це питання близькості. Якщо ви кодуєте реалізацію (реалізований об'єкт), ви знаходитесь у досить близьких стосунках із цим "іншим" кодом, як його споживач. Це означає, що ви повинні знати, як його сконструювати (тобто які залежності він має, можливо, як параметри конструктора, можливо, як сеттери), коли ним розпоряджатися, і ви, мабуть, не можете багато чого зробити без нього.

Інтерфейс перед реалізованим об’єктом дозволяє зробити кілька речей -

Для одного ви можете / повинні використовувати фабрику для побудови екземплярів об'єкта. Контейнери МОК дуже добре роблять це для вас, або ви можете зробити власні. Оскільки будівельні обов'язки поза вашою відповідальністю, ваш код може просто припустити, що він отримує те, що йому потрібно. З іншого боку фабричної стіни ви можете або створити реальні екземпляри, або знущатись над екземплярами класу. У виробництві ви, звичайно, використовували б реальне, але для тестування вам може знадобитися створити приховані або динамічно висміювані екземпляри для тестування різних системних станів без необхідності запускати систему.
Вам не потрібно знати, де знаходиться об’єкт. Це корисно в розподілених системах, де об’єкт, з яким ви хочете поговорити, може бути локальним для вашого процесу чи навіть системи. Якщо ви коли-небудь програмували Java RMI або old skool EJB, ви знаєте рутину "розмови з інтерфейсом", яка приховувала проксі-сервер, який виконував обов'язки віддаленої мережі та маршалінгу, про що вашому клієнтові не довелося дбати. WCF має подібну філософію "спілкування з інтерфейсом" і дозволяє системі визначати спосіб взаємодії з цільовим об'єктом / службою.

** ОНОВЛЕННЯ ** Був запит на приклад контейнера МОК (завод). Існує багато таких систем для майже всіх платформ, але в своїй основі вони працюють так:

Ви ініціалізуєте контейнер у програмі запуску програм. Деякі фреймворки роблять це за допомогою конфігураційних файлів або коду або обох.
Ви "реєструєте" реалізації, які ви хочете, щоб контейнер створив для вас, як фабрику для інтерфейсів, які вони реалізують (наприклад: зареєструйте MyServiceImpl для інтерфейсу служби). Під час цього процесу реєстрації зазвичай існує певна поведінкова політика, наприклад, якщо кожен раз створюється новий екземпляр або використовується один (тон) екземпляр
Коли контейнер створює для вас об'єкти, він вводить будь-які залежності в ці об'єкти як частину процесу створення (тобто, якщо ваш об'єкт залежить від іншого інтерфейсу, реалізація цього інтерфейсу, в свою чергу, надається тощо).

Псевдокодично це може виглядати так:

IocContainer container = new IocContainer();

//Register my impl for the Service Interface, with a Singleton policy
container.RegisterType(Service, ServiceImpl, LifecyclePolicy.SINGLETON);

//Use the container as a factory
Service myService = container.Resolve<Service>();

//Blissfully unaware of the implementation, call the service method.
myService.DoGoodWork();

Question 4

При програмуванні проти інтерфейсу ви пишете код, який використовує екземпляр інтерфейсу, а не конкретний тип. Наприклад, ви можете використовувати наступний шаблон, який включає введення конструктора. Інжектор конструктора та інші частини інверсії управління не потрібно програмувати проти інтерфейсів, однак, оскільки ви виходите з точки зору TDD та IoC, я підключив його таким чином, щоб дати вам певний контекст. знайомий з.

public class PersonService
{
    private readonly IPersonRepository repository;

    public PersonService(IPersonRepository repository)
    {
        this.repository = repository;
    }

    public IList<Person> PeopleOverEighteen
    {
        get
        {
            return (from e in repository.Entities where e.Age > 18 select e).ToList();
        }
    }
}

Об'єкт сховища переданий і є типом інтерфейсу. Перевагою передачі інтерфейсу є можливість "заміни" конкретної реалізації без зміни використання.

Наприклад, можна припустити, що під час виконання контейнер IoC буде вводити сховище, яке підключено до бази даних. Під час тестування ви можете передати макет або сховище заглушок, щоб здійснити свій PeopleOverEighteenметод.

Question 5

Це означає думати загальне. Не конкретні.

Припустимо, у вас є програма, яка повідомляє користувача, що надсилає йому якесь повідомлення. Наприклад, якщо ви працюєте з використанням інтерфейсу IMessage

interface IMessage
{
    public void Send();
}

Ви можете налаштувати для кожного користувача спосіб отримання повідомлення. Наприклад, хтось хоче отримати повідомлення за допомогою електронної пошти, і тому ваш IoC створить конкретний клас EmailMessage. Деякі інші хочуть SMS, а ви створюєте екземпляр SMSMessage.

У всіх цих випадках код сповіщення користувача ніколи не буде змінено. Навіть якщо ви додасте ще один конкретний клас.

Question 6

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

Прикладом, про який я вже згадував тут десь, є використання інтерфейсу для доступу до значень конфігурації. Замість того, щоб дивитись безпосередньо на ConfigurationManager, ви можете надати один або кілька інтерфейсів, що дозволяють отримати доступ до значень конфігурації. Зазвичай ви пропонуєте реалізацію, яка читається з конфігураційного файлу, але для тестування ви можете використовувати таку, яка просто повертає тестові значення або видає винятки або щось інше.

Враховуйте також рівень доступу до даних. Завдяки тісній взаємодії вашої бізнес-логіки з конкретною реалізацією доступу до даних важко тестувати, не маючи цілої бази даних під рукою з необхідними даними. Якщо ваш доступ до даних прихований за інтерфейсами, ви можете надати лише ті дані, які потрібні для тесту.

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

Question 7

Перевірте свій код, як хтось, хто використовував би його після прочитання документації. Не перевіряйте нічого на основі знань, які у вас є, тому що ви написали або прочитали код. Ви хочете переконатися, що ваш код поводиться належним чином.

У найкращому випадку ви повинні мати змогу використовувати свої тести як приклади, а тести на Python - хороший приклад для цього.

Якщо ви дотримуєтесь цих вказівок, зміна впровадження не повинна бути проблемою.

Також на моєму досвіді хорошою практикою є тестування кожного "шару" вашого додатка. У вас будуть атомні одиниці, які самі по собі не мають залежностей, і ви будете мати одиниці, які залежать від інших одиниць, поки врешті не дійдете до програми, яка сама по собі є одиницею.

Вам слід протестувати кожен шар, не покладайтесь на той факт, що тестуючи блок A, ви також тестуєте блок B, від якого залежить блок A (правило стосується також успадкування.) Це теж слід трактувати як деталь реалізації, навіть хоча ви можете почуватися так, ніби повторюєтеся.

Майте на увазі, що колись письмові тести навряд чи зміняться, тоді як код, який вони тестують, зміниться майже напевно.

На практиці також існує проблема вводу-виводу та зовнішнього світу, тому ви хочете використовувати інтерфейси, щоб при необхідності можна було створювати макети.

У більш динамічних мовах це не така велика проблема, тут ви можете використовувати набір качок, множинне успадкування та міксини для складання тестових кейсів. Якщо ви починаєте не любити спадщину взагалі, ви, мабуть, робите це правильно.

Question 8

Цей скринкаст пояснює гнучку розробку та TDD на практиці для c #.

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