高内聚、低耦合的个人理解

我们在进行软件设计,都是希望达到高内聚、低耦合的目的,但在实际工作中我发现很多程序员没有仔细去想什么时候应该高内聚,什么时候应该要低耦合,而且很多人对这句话更多是关注低耦合,而不是高内聚,感觉只要有依赖就不好,结果造成一些不合理的强行分离,导致写代码时出现不少麻烦。其实,我觉得高内聚、低耦合就是根据客观事物来分析,该依赖就得依赖,该分离就分离。下面以汽车为例,谈下我的理解,希望各位道友指点、指正。
一辆汽车由、车身、轮胎、发动机等组成,那么些对象当然要内聚在一起,如果强行把轮胎分开,那就不是一个完整的汽车了。所以之处应该要内聚。
那另一方面讲,汽车要启动,要有油才行,就需要加油,加油得去加油站,这时,我觉得汽车和加油站就应该低耦合了,不能说没有加油站汽车就开不了啦!而且从软件设计角度讲,汽应该依赖“加油”这个接口,至于你的油是在加油站加的,还是在自己家加的(甚至有可能从别人的车里倒出来的呢?), 另外由具体的实现类去做。所以,上述情况应该要低耦合。
以一辆汽车做为说明,我觉得容易理解。但在具体项目中,业务复杂,比较难找出真正合理的业务实体和功能边界,而不像理伦书上讲的,说可以抽象一个形状,形状又有三角形、四边形、圆形等子类具体形状。

所谓,分久必合,合久必分,分分合合,合合分分。其实,都是在分合之间权衡,人类社会分工这样,对象责任分工亦是如此。
内聚,是没必要每个人都单干,结成群体力量岂不更大。
耦合,内部职能过于复杂,必然效率低下,低耦自不必多说,大家都知道什么道理。
其实,实际业务过程中,也可以和理论一样,业务实体和领域边界的寻找是必须的也是一个漫长的迭代过程,但最终目的,是找到点,线,面,三角,四边,园,正方体,锥,球,,,各自都是刚性的结构,不可拆分,各自独立的完成自己的使命。。。理解不难,做起来难,要做好了更难。