你是什​​么意思＆＃34;编程接口＆＃34;和＆＃34;编程实施＆＃34;？

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，并确保它们遵循您为应用程序开发人员提供的界面。

Application开发人员现在正在开发一个接口，而不是一个实现。他不知道或不关心课程的实施方式。他只知道界面。这促进了代码中较少的耦合，并使您能够（例如通过配置文件）轻松切换到另一个实现。

Answer 2

担心课程的内容而不是课程的内容。后者应该是一个实现细节，远离您的类的客户端。

如果从界面开始，您可以在以后注入新实现而不会影响客户端。它们只使用接口类型的引用。

Answer 3

这意味着在使用类时，您应该只针对公共接口进行编程，而不是对其实现方式进行假设，因为它可能会发生变化。

通常，这转换为使用接口/抽象类作为变量类型而不是具体类型，允许在需要时交换实现。

在.NET世界中，一个例子是使用IEnumerable/IEnumerator接口 - 这些允许您迭代集合而不用担心集合是如何实现的。

Answer 4

关于耦合。低耦合是软件架构的一个非常重要的属性。你越不需要了解你的依赖关系就越好。

耦合可以通过为了交互/使用你的依赖关系而必须做出的假设数来衡量（在这里解释M Fowler）。

因此，当使用更多泛型类型时，我们更松散耦合。例如，我们从一个集合的特定实现策略中解耦：链表，双链表，数组，树等。或者来自经典的OO学校：“它的确切形状：矩形，圆形，三角形”，当我们只想依赖一个形状时（在旧学校OO我们在这里应用多态）