SOLID准则：Java开发者最佳实践-蒲公英云

SOLID 原则是软件世界中一些最古老的规则。

微信搜索关注《Java学研大本营》，加入读者群，分享更多精彩

SOLID 原则是软件世界中一些最古老的规则。它们使我们能够编写可维护、可读、可重用的代码。在本文中，试图完成一个遵守SOLID原则的现实例子。

1.单一职责

每个类都应该只有一个目的，而不是充满过多的功能。考虑以下示例：

public class PasswordHasher
{
    public String hashAndSavePassword(String password)
    {
        hashPassword();
        savePassword();
    }
    public void hashPassword()
    {
        //hashing implementation
    }
    public void savePassword()
    {
        //save to the db
    }
}

顾名思义，这个类是为散列密码实现的。将它们保存到数据库中不应该是它的责任。每个班级应该有一个单一的责任来履行。

不应该有功能繁多的“神级”，需要完成的任务太多。相反，我们应该尽可能模块化地编写我们的类。在另一个类中实现保存操作。

2.开闭原则

类应该对扩展开放，对修改关闭。

换句话说，您不必重写现有类来实现新功能。

让我们继续我们的密码哈希示例。假设我们希望我们的类能够使用各种算法选项进行散列。

public String hashPassword(String password, HashingType hashingType)
{
    if(HashingType.BASE64.equals(hashingType))
    {
        hashedPassword="hashed with Base64";
    }
    else if(HashingType.MD5.equals(hashingType))
    {
        hashedPassword="hashed with MD5";
    }
    return hashedPassword;
}

如果我们以这种方式实现，我们将破坏 SOLID 中的 O 非常糟糕。每次实现一个新的算法，我们都需要修改已有的类，而且看起来很丑。

感谢 OOP，我们有了抽象。我们应该使我们的初始类成为接口/抽象类，并在具体类中实现算法。

public class Base64Hasher implements PasswordHasher
{
    @Override
    public String hashPassword(String password)
    {
        return "hashed with 64";
    }
}
public interface PasswordHasher
{
    String hashPassword(String password);
}
public class MD5Hasher implements PasswordHasher
{
    @Override
    public String hashPassword(String password)
    {
        return "hashed with SHA256";
    }
}

类的顺序可能会很奇怪，不幸的是，当它们被放在一起时，它们会按字母顺序排列。

通过这种方式，我们可以在不触及现有代码库的情况下添加新算法。

3. Liskov-替代原则

子类应该能够实现其父类的每个功能，并且可以被视为其父类。

为了演示我们的示例，让我们创建模型（数据）类以使用我们的散列算法。

public abstract class Hashed
{
    PasswordHasher passwordHasher;
    String hash;
    public void generateHash(String password)
    {
        hash = passwordHasher.hashPassword(password);
    }
}
public class Base64 extends Hashed
{
    public Base64()
    {
        this.passwordHasher = new Base64Hasher();
    }
}

我们为其他编码实现了相同的…

为了满足 Liskov 规则，Hashed 的每个其他扩展都应该使用有效的散列函数实现并返回一个散列。

例如，如果我们用一个名为“NoHash”的类扩展 Hashed 类，该类使用返回完全相同的密码而不进行任何编码的实现将违反规则，因为 Hashed 的子类应该具有密码的哈希值。

4、接口隔离原则

接口不应该强制类实现它们不能做的事情。大接口应该分成小接口。

考虑我们向接口添加解码功能。

public interface PasswordHasher
{
    String hashPassword(String password);
    String decodePasswordFromHash(String hash);
}

这将违反该定律，因为我们的一种算法 SHA256 实际上是不可解密的（它是单向函数）。相反，我们可以向适用的类添加另一个接口来实现它们的解码算法。

public interface Decryptable
{
    String decodePasswordFromHash(String hash);
}
public class Base64Hasher implements PasswordHasher, Decryptable
{
    @Override
    public String hashPassword(String password)
    {
        return "hashed with base64";
    }
    @Override
    public String decodePasswordFromHash(String hash)
    {
        return "decoded from base64";
    }
}

5.依赖倒置原则

组件应该依赖于抽象，而不是具体化。

我们有如下密码服务：

public class PasswordService
{
    private Base64Hasher hasher = new Base64Hasher();
    void hashPassword(String password)
    {
        hasher.hashPassword(password);
    }
}

我们违反了原则，因为我们将Base64Hasher以及紧密耦合在一起PasswordService。

让我们将它们解耦，让客户端通过构造函数注入所需的哈希服务。

public class PasswordService
{
    private PasswordHasher passwordHasher;
    public PasswordService(PasswordHasher passwordHasher)
    {
        this.passwordHasher = passwordHasher;
    }
    void hashPassword(String password)
    {
        this.passwordHasher.hashPassword(password);
    }
}