Activity
对象,具有属性,例如name
和due_date
,方法例如load()
和save()
,并且还有像getParent()
,getContributors()
和getTeam()
这样返回其他对象(数组)的方法。这违反了单一职责原则,那么这是“糟糕”的面向对象编程吗?Activity
对象,具有属性,例如name
和due_date
,方法例如load()
和save()
,并且还有像getParent()
,getContributors()
和getTeam()
这样返回其他对象(数组)的方法。这违反了单一职责原则,那么这是“糟糕”的面向对象编程吗?load()
和save()
? 或者你是否将这些任务委托给其他用于多个类功能的对象在load()
和save()
中进行? 这样做可以一定程度上遵循SRP, 且符合你的设计。load()
和save()
中类似的代码重构到达到上述描述的情况,以便:
load()
和save()
的代码重用是一个很好且重要的主题,但这只是另一个问题。模型可以根据需要与数据库一起工作 - 使用代码重用(ORM,Mapper),或者不使用 - 取决于具体情况下哪个更好。在这个问题中,我认为主要的主题是与其他模型的协作、依赖关系和责任。 - OZ_load()
方法中,我只运行(特定于类的)查询来获取数据,对文本属性(如name
)中的HTML字符进行一些预处理,并将数据分配给对象的属性。 - Rijk嗯...现在很难说。你可以将整个类粘贴到pastbin上,但是...
是的,看起来这是糟糕的面向对象编程。你有同一个类负责与数据库和领域逻辑交互。这会导致类发生两种完全不同的变化原因。
你可能会从探索DataMapper模式中受益。
也许我只是在瞎猜(因为我不是专家),但:
领域对象内的load()和save()方法被称为Active Record(另一种描述)。这并不是坏事(尽管我不喜欢它),因为那些可能在你之后或与你一起工作的人将更容易解决如何持久化这些对象的问题。
关于其他方法。如果它在对象领域中并且代表对象行为,那么情况就不会太糟糕。如果设计得好,它可以非常好。领域驱动设计鼓励使用丰富的领域模型,这与贫血的领域模型相反。贫血的领域模型具有仅具有属性和getter和setter的领域对象。因此,只要它在您的对象领域内,将其他方法放入其中并不被认为是坏事。
这是我从阅读的书籍和文章中理解这些概念的程度。
希望能有所帮助..
你所描述的是ActiveRecord,众所周知它违反了SRP原则。此外,只有当表行与对象紧密匹配时,ActiveRecord才能正常工作。一旦阻抗失配过大,将使系统更改变得更加困难。
这不一定是坏的面向对象编程,但由于持久性逻辑和领域逻辑之间缺乏分离,因此它是技术债务的一种形式。违反任何SOLID原则通常会导致难以更改的代码、脆弱的代码和不可重用的代码。
其中一些债务并不是问题。当这些债务开始积累利息,例如开始影响其他设计决策时,就会成为问题。换句话说,当您注意到更改系统变得更加困难时,请尝试偿还一些债务,例如重构为更易维护的解决方案。
我认为停止认为模型只应该是逻辑和数据库之间的层是很重要的。模型可以与数据库和其他模型一起工作,所有的逻辑都应该在模型中。
我认为有两种方法:
getContributors()
方法中返回ID数组,然后您可以创建一个新对象(可能是工厂),将这些ID转换为对象。new
关键字,而是通过工厂或依赖容器(我更喜欢DC)。