php – SOLID原则中的SRP是否导致了Lasagna Code？

有了SOLID原则,特别是SRP,我们有很多类……
我的意思是,就像你想要构建一个数据库类一样
然后,你有
处理数据库的DatabaseHandler类(选择,插入,更新,删除等),
DatabaseAdapter类,它是一个扩展的PDO类(可以在构造中设置首选的默认模式,一个新的prepare方法直接准备语句,将它与param绑定,然后执行它,

QueryBuilder类,它是SelectStatementBuilder类的父类,InsertStatementBuilder类,DeleteStatementBuilder类,UpdateStatementBuilder类(构建SQLStatement),
Expression类,用于构建WHERE子句中所需的表达式
SQLStatement类(它的行为就像一个普通的字符串,但它的接口是SQLStatementInterface,所以我们可以知道它是一个SQL语句等等.

而且,我知道如果我深入挖掘并重新进行重构,将会有更多的课程.

SRP原则实施是否导致了Lasagna代码？
烤宽面条的代码好吗？

解决方法:

一般而言,SRP是一项设计原则,要求您考虑系统的不同职责(改变AKA的原因).其目标是帮助提高您的系统凝聚力.换句话说,一起变化的事物,保持在一起.

Uncle Bob defined SRP作为：

A class should have only one reason to change.

当采用错误的粒度级别时,SRP可以被解释为一个类应该只做一个非常小的,低级别的事情,导致过度抽象而没有明显的好处.通过阅读他的论文,您会注意到“改变的原因”是在用户/客户/消费者需求级别定义的.一个简单的例子是,如果我的UI要求的变化导致我改变包含一些数据访问层代码的类,则该类具有多个违反SRP的改变原因(即UI和数据访问).

在您的情况下,除非您正在构建数据库管理工具,否则没有理由将原始数据库类分解为这些许多较小的类.如果这是一个典型的(Web)应用程序,那么如果您想要更改底层数据库实现(例如在测试期间从MySQL到内存数据库),那么无论如何都必须替换所有这些类.不妨保持简单.

标签：php,oop,solid-principles,single-responsibility-principle,software-quality
来源： https://codeday.me/bug/20190519/1137649.html