Class 单一责任原则与构建目标树_Class_Oop_Design Patterns_Single Responsibility Principle

Class 单一责任原则与构建目标树

class oop design-patterns

Class 单一责任原则与构建目标树,class,oop,design-patterns,single-responsibility-principle,Class,Oop,Design Patterns,Single Responsibility Principle,让类Rel表示两个表之间的一种SQL关系（即Rel可以是HasA或HasMany，等等）如果这个类的实例对象也是SQL表关系树的节点，那么它是否会矛盾（“类或模块应该有一个，而且只有一个，更改的原因”）？节点将包括表名、用于SELECT查询的字段列表等我认为会的，因为修改树结构（比如在树中的子查询中添加添加ORDER BY的可能性）和修改关系（比如允许/禁止空关系）都是更改的原因然后，如果这违反了单一责任原则，我假设关系应该只有类方法，树的节点（每个节点都有一个表和一个要从SQL检索的字段

让类

Rel

表示两个表之间的一种SQL关系（即

Rel

可以是

HasA

或

HasMany

，等等）

如果这个类的实例对象也是SQL表关系树的节点，那么它是否会矛盾（“类或模块应该有一个，而且只有一个，更改的原因”）？节点将包括表名、用于

SELECT

查询的字段列表等

我认为会的，因为修改树结构（比如在树中的子查询中添加添加

ORDER BY

的可能性）和修改关系（比如允许/禁止空关系）都是更改的原因

然后，如果这违反了单一责任原则，我假设关系应该只有类方法，树的节点（每个节点都有一个表和一个要从SQL检索的字段列表）应该仅仅是方法的参数，而不是对象或类本身。对吧?

但是，由于树的节点是关系类的实例，语法很短：

$Node->unbowhere（）

（从树的根节点

$Node

返回SQL查询生成的

WHERE

部分）

如果$Nodes不再是此类的对象，则此函数调用可能会变得更长：

$Node->{CLASS}->展开其中的（$Node）

（这里的字段

CLASS

是对关系类的引用，或者在不支持传递类的语言中，是对此类对象的引用）

有没有办法既不破坏基本的OOP原则，又使代码简短易懂？

Hm，而且即使将$Node作为参数而不是调用的对象传递，它似乎仍在破坏SRP，因为

展开，其中不仅严格依赖于关系，而且还依赖于树的特定结构。因此，我认为没有办法在编写代码时不破坏SRP:-（嗯，我的两个变体都违反了SRP。但我觉得代码的第二个变体没有违反第一个变体违反的某些原则。它可能是哪一个原则？