让类Rel
表示两个表之间的一种SQL关系(Rel
可以是HasA
或HasMany
等。)
如果此类的实例对象也是关系树的节点,它是否会与single responsibility principle("类或模块应该只有一个,只有一个,更改")相矛盾SQL表?节点将包括表名,SELECT
查询的字段列表等
我认为,它会,因为修改树结构(比如添加ORDER BY
添加到树中的子查询的可能性)和修改关系(比如允许/禁止NULL关系)都是改变的原因。
然后,如果它违反了单一责任原则,我认为关系应该只有类方法,树的节点(每个节点都有一个表和一个从SQL中检索的字段列表)应该只是参数方法,而不是对象或类本身。正确?
但是,由于树的节点是关系类的实例,语法很短:
$Node->unfoldWHERE()
(从我们树的根节点WHERE
返回SQL查询构建的$Node
部分)
如果$ Nodes不再是此类的对象,则此函数调用可能会变长:
$Node->{CLASS}->unfoldWHERE($Node)
(此处字段CLASS
是对关系类的引用,或者是不支持传递类的语言,此类的对象)
有没有办法不打破基本的OOP原则并使这段代码简短易懂?