谈谈book.Save()到底OO还是不够OO
在之前争论贫血还是充血的时候,有Tx提出这样一个观点book.Save()用起来很怪,有人认为这样子的用法不够OO,因为保存书不是书所具有的行为,而是书籍管理员:BookManager来发出比较合理。这里来说说我的看法,还是OO,继续接砖。
首先是我的看法,book.Save() 是不是符合OO的精神,关键是看怎么用。打个比方。如果是EditBook.aspx.cs中出现了book.Save()那么我觉得是不符合OO设计的思想的,因为保存书的行为确实不是书本身发出的。但是,如果有一个用户类User,在User里有个UpdateBook的方法,在这个方法里出现了book.Save(),那么我认为这是很OO的,因为修改后保存书的行为确实是用户发出的。但是有人可能会问了,那为什么不直接把book的属性读出来生成Sql去update数据库(也就是BookManager的做法,个人不赞同此做法)呢?很简单,根据OO的封装性原则,Book类的实例对自身状态的改变必须是由自己完成,所以我们需要对持久化book的属性这个改变book状态(未持久化状态到持久化状态的改变),如果是交给BookManager去完成那么就破坏了Book类的封装性,自然也就不OO了。
所以OO与否是看你设计的时候所用的思想是否遵循了OO的原则,而不是但看某行代码,book.Save()能OO也可以不OO,贫血模型不够OO的地方在于将事件序列的发起者交给了Service从而破坏了类本身的封装性。
论证完毕,劈砖大大的欢迎,写得很短,是因为快要下班了。
首先是我的看法,book.Save() 是不是符合OO的精神,关键是看怎么用。打个比方。如果是EditBook.aspx.cs中出现了book.Save()那么我觉得是不符合OO设计的思想的,因为保存书的行为确实不是书本身发出的。但是,如果有一个用户类User,在User里有个UpdateBook的方法,在这个方法里出现了book.Save(),那么我认为这是很OO的,因为修改后保存书的行为确实是用户发出的。但是有人可能会问了,那为什么不直接把book的属性读出来生成Sql去update数据库(也就是BookManager的做法,个人不赞同此做法)呢?很简单,根据OO的封装性原则,Book类的实例对自身状态的改变必须是由自己完成,所以我们需要对持久化book的属性这个改变book状态(未持久化状态到持久化状态的改变),如果是交给BookManager去完成那么就破坏了Book类的封装性,自然也就不OO了。
所以OO与否是看你设计的时候所用的思想是否遵循了OO的原则,而不是但看某行代码,book.Save()能OO也可以不OO,贫血模型不够OO的地方在于将事件序列的发起者交给了Service从而破坏了类本身的封装性。
论证完毕,劈砖大大的欢迎,写得很短,是因为快要下班了。