Что вы подразумеваете под «программированием для интерфейса» и «программированием для реализации»?

Question

В книге Head First Design Patterns автор часто говорит, что нужно программировать для взаимодействия, а не для реализации?

Что это значит?

Answer 1

Давайте проиллюстрируем это следующим кодом:

namespace ExperimentConsoleApp
{
    class Program
    {
        static void Main()
        {
            ILogger loggerA = new DatabaseLogger();

            ILogger loggerB = new FileLogger();

            loggerA.Log("My message");
            loggerB.Log("My message");
        }
    }

    public interface ILogger
    {
        void Log(string message);
    }

    public class DatabaseLogger : ILogger
    {
        public void Log(string message)
        {
            // Log to database
        }
    }

    public class FileLogger : ILogger
    {
        public void Log(string message)
        {
            // Log to File
        }
    }

}

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

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

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

Answer 2

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

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

Answer 3

Это все о сцеплении. Низкая связь является очень важным свойством * архитектуры программного обеспечения. Чем меньше вам нужно знать о вашей зависимости, тем лучше.

Связь может быть измерена с помощью количества предположений , которые вы должны сделать, чтобы взаимодействовать / использовать свою зависимость (перефразируя M Фаулера здесь).

Таким образом, при использовании более общих типов мы более слабо связаны. Например, мы отделены от конкретной стратегии реализации коллекции: связанный список, двойной связанный список, массивы, деревья и т. Д. Или от классической ОО-школы: «какая это точная форма: прямоугольник, круг, треугольник», когда мы просто хотим зависеть от формы (в ОО старой школы мы применяем здесь полиморфизм)

Answer 4

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

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

В мире .NET одним из примеров является использование интерфейсов IEnumerable/IEnumerator - они позволяют перебирать коллекцию, не беспокоясь о том, какКоллекция была реализована.