面向实体的开发

今日不肯埋头，明日何以抬头！每日一句努力自己的话哈哈~哈喽，今天我将给大家带来一篇《面向实体的开发》，主要内容是讲解等等，感兴趣的朋友可以收藏或者有更好的建议在评论提出，我都会认真看的！大家一起进步，一起学习！

在软件开发中，代码维护、扩展和灵活性对于项目的长期成功非常重要。 solid 原则的制定是为了指导开发人员创建更易于理解、修改和扩展的代码。在本文中，我们将分别讨论 solid 五个原则以及如何通过 java 中的实际示例来使用它们。

1. 单一职责原则

单一职责原则（srp）规定一个类必须只有一个改变的理由，即它在系统内必须具有单一职责。

// antes de aplicar o srp
class productservice {
    public void saveproduct(product product) {
        // lógica para salvar o produto no banco de dados
    }

    public void sendemail(product product) {
        // lógica para enviar um email sobre o produto
    }
}

// após aplicar o srp
class productservice {
    public void saveproduct(product product) {
        // lógica para salvar o produto no banco de dados
    }
}

class emailservice {
    public void sendemail(product product) {
        // lógica para enviar um email sobre o produto
    }
}

在示例中，我们将在数据库中保存产品的责任与发送有关产品的电子邮件的责任分开。这使得未来的更改更加容易，因为电子邮件发送的更改不再影响产品保存逻辑。

2. 开闭原理

开放/封闭原则（ocp）建议软件实体（类、模块、函数等）应该对扩展开放，但对修改关闭。这是通过使用抽象和继承来实现的。

// exemplo inicial violando o ocp
class areacalculator {
    public double calculatearea(rectangle[] rectangles) {
        double area = 0;
        for (rectangle rectangle : rectangles) {
            area += rectangle.width * rectangle.height;
        }
        return area;
    }
}

// exemplo após aplicar o ocp
interface forma {
    double calculatearea();
}
class rectangle implements forma {
    private double width;
    private double height;

    public rectangle(double width, double height) {
        this.width = width;
        this.height = height;
    }
    @override
    public double calculatearea() {
        return width * height;
    }
}

class areacalculator {
    public double calculatearea(forma [] formas) {
        double area = 0;
        for (forma formas: formas) {
            area += forma.calculatearea();
        }
        return area;
    }
}

在第二个示例中，最初 areacalculator 类直接依赖于 rectangle 类。这意味着如果您想添加其他类型的形状，例如圆形或三角形，则需要修改 areacalculator 类，从而违反 ocp。通过创建 shape 接口，areacalculator 类能够在不修改现有代码的情况下接收新的几何形状。

3.里氏替换原理

里氏替换原则（lsp）规定超类的对象必须可以被其子类的对象替换，而不影响系统的完整性。换句话说，子类的行为必须与超类的行为一致。

// classe base
class bird {
    public void fly() {
        // método padrão que imprime "flying"
        system.out.println("flying");
    }
}

// classe derivada que viola o lsp
class duck extends bird {
    @override
    public void fly() {
        // sobrescrita que imprime "ducks cannot fly"
        system.out.println("ducks cannot fly");
    }
}

问题：duck 类重写了 fly() 方法来打印“鸭子不能飞”，从而改变了 bird 基类中定义的默认行为，即所有鸟都会飞（“flying”）。这违反了 lsp，因为任何期望 bird 对象或其子类会飞的代码都无法与 duck 一起正常工作，而我们已经知道 duck 不会飞。

// classe derivada que respeita o lsp
interface bird {
    void fly();
}
class eagle implements bird {
    @override
    public void fly() {
        system.out.println("flying like an eagle");
    }
}
class duck implements bird {
    @override
    public void fly() {
        throw new unsupportedoperationexception("ducks cannot fly");
    }
}

通过这种方法，eagle 和 duck 可以在需要 bird 的地方互换，而不会破坏 bird 接口设定的期望。 duck 抛出的异常显式地传达了鸭子不会飞的信息，而没有以可能导致代码中出现意外问题的方式修改超类的行为。

4. 接口隔离原则

接口隔离原则（isp）建议类的接口应该特定于使用它们的客户端。这避免了需要实现客户端未使用的方法的“胖”接口。

// exemplo antes de aplicar o isp
interface worker {
    void work();
    void eat();
    void sleep();
}

class programmer implements worker {
    @override
    public void work() {
        // lógica específica para programar
    }
    @override
    public void eat() {
        // lógica para comer
    }
    @override
    public void sleep() {
        // lógica para dormir
    }
}

// exemplo após aplicar o isp
interface worker {
    void work();
}
interface eater {
    void eat();
}
interface sleeper {
    void sleep();
}
class programmer implements worker, eater, sleeper {
    @override
    public void work() {
        // lógica específica para programar
    }
    @override
    public void eat() {
        // lógica para comer
    }
    @override
    public void sleep() {
        // lógica para dormir
    }
}

在示例中，我们将 worker 接口拆分为更小的接口（work、eat、sleep），以确保实现它们的类只具有它们需要的方法。这可以防止类必须实现与它们不相关的方法，从而提高代码的清晰度和内聚性。

5. 依赖倒置原则

依赖倒置原则（dip）建议高层模块（例如实现主要业务规则的业务或应用程序类）不应该依赖于低层模块（基础设施类，例如数据访问和外部服务，它们实现了主要业务规则）。支持高层操作）。两者都必须依赖于抽象。

// exemplo antes de aplicar o dip
class backenddeveloper {
    public void writejava() {
        // lógica para escrever em java
    }
}
class project {
    private backenddeveloper developer;

    public project() {
        this.developer = new backenddeveloper();
    }
    public void implement() {
        developer.writejava();
    }
}

// Exemplo após aplicar o DIP
interface Developer {
    void develop();
}
class BackendDeveloper implements Developer {
    @Override
    public void develop() {
        // Lógica para escrever em Java
    }
}
class Project {
    private Developer developer;

    public Project(Developer developer) {
        this.developer = developer;
    }
    public void implement() {
        developer.develop();
    }
}

project 类现在依赖于抽象（developer）而不是具体实现（backenddeveloper）。这允许不同类型的开发人员（例如 frontenddeveloper、mobiledeveloper）轻松注入 project 类，而无需修改其代码。

结论

采用 solid 原则不仅可以提高代码质量，还可以增强您的技术技能，提高工作效率，并促进您作为软件开发人员的职业道路。

今天关于《面向实体的开发》的内容就介绍到这里了，是不是学起来一目了然！想要了解更多关于的内容请关注golang学习网公众号！