在面向对象编程时对于类的划分有哪些心得?

有时候一些东西可以写成一个类也可以多个类,如何兼顾各种约束,找到一个合适的平衡点?例如python自有的cgi.escape和htmlparser.htmlparser,混入帕斯卡命名法不说,将这两个功能这样封装是出于何种考虑?回复内容:

以容易写unittest又绝对不会破坏封装为准

首先是方法学:基于用例分析(use case analysis)的方法基于crc方法(class responsibility collaborator)其次了解面向对象的原则抽象原则遵循高内聚,低耦合的原则遵循solid 原则特别是开闭原则(open/closed principle)和单一责任原则(single responsibility principle)最后,持续进行重构
经验之谈。前期的需求分析的时候,把需求、功能划分细致一点。然后,把要做的功能分几堆。某一堆功能专注做某一类事情,比如数据库读,数据库写,接口交互,数据计算等。你看,天然的不就出来“类”这个东西了么。设计的时候,重点注意两个方面。第一,接口必须隔离。solid里提到了单一职责、接口隔离两个原则。单一职责确实很难,有时候打破它的性价比更高。但接口隔离一定要做到。接口不隔离,就不可能单一职责,就很难遵守开闭、里氏等原则。第二,考虑开闭原则。开闭原则是一切软件设计的核心思想。但是要严格做到真的太难了。首先没人能在刚开始的时候就考虑到所有以后可能的变化;其次即使考虑到了,实现起来的成本也会居高不下。所以,在可以接受的工作量范围内,以你和业务、需求方的经验来做一些开闭的设计就行。开发的时候,主要靠经验和技巧来做一些重构。这里可以提一点,就是有些看起来很无聊的代码规范有时候真的很有帮助。比如一个方法不能超过30行,一个类不能超过300行这种。当行数超过规范的时候,你自然就会想重构、拆分子类。另外 @vczh 说到了以unittest为准,这也是一个很好的思路,尤其是在tdd实践中。
如果针对实体的话,按照面向对象对类的定义,一组相同特性的对象可以归一个类就算一个类,如果多个类共用一组属性的,将共用属性组归为一个继承类,然后具体类继承为子类再实现差异。如果能全部归一类又可以分多类,应该没处理好公共属性。
这个问题必须要分开讨论。对于需求变化不频繁的,当然是以test是否方便为依据。至于需求变化频繁的,相信我,只要能跑就行。所以我从来都是尽可能不干业务逻辑层的活,我向来是努力写核心功能。举例来说,对于典型的后端mvc的项目,我一般主要写m,顶多写一点m和c之间的接口。但是c和v的主要部分我一点都不想动。这个时候,我写完我的接口就可以好好以test为依据写类了。
纯靠感觉…
this is why we need design patterns. you may want to refer to gof(“design patterns: elements of reusable object-oriented software”).=============================好吧我没啥写大型项目的经验,还是看以上各位答主答的吧。
solid(单一功能、开闭原则、里氏替换、接口隔离以及依赖反转)
根据业务吧,如果从面相对象的思路去思考,无非是把概念进行封装,概念可以分为物件,行为和状态,当然,还有一些是自己认为它是一个完整的概念,也可以划分出去,单独描绘,有点像画画。
类要封装变化。把容易根据需求变化的地方封装起来,这也对应设计模式的开闭原则(对派生开放,对修改封闭)

Posted in 未分类