对象设计原则

现在我们面对的是让人恶心的现实，被人总结起来有如下几条：

1，僵化性：很难对系统进行改动，因为每个改动都会牵一发动全身

2，脆弱性：同上，但是具体指改了一个地方，其他地方出问题了

3，牢固性：应该是顽固，我想重用某个比较好的模块，发现居然扯不下来

4，黏粘性：难以做正确的事情

5，不必要的复杂性：过分设计，错误投资，就像我们的政府一样，花4万亿养利益集团

6，不必要的重复：滥用鼠标，大量的剪切粘贴，这是因为开发人员忽视了抽象

7，晦涩性：混乱的表达，比如用中文拼音做类名，乱作一团，保持代码清晰和富有表现力应该是我们不断的追求。

有人曾经有形象的比喻，我们的软件开发就像女人怀孕，本来应该是要细心照料，生怕胎儿营养不够会出什么问题，可叹的是现在的客户和开发商总是前方百计来压缩开发成本和开发时间，没有经过母体十月孕育的孩子那就是早产儿，那是发育不健全的。或早或晚都会暴露出来身体的缺陷，也许有些缺陷是能够通过后天的哺育可以弥补的，但是对于很多缺陷可能就是无法弥补的。是根子上的问题，再补也无济于事，能弥补的，将花费巨大的代价。

程序员开发，设计和测试人员每一个都应该高薪，因为软件成本本质就是很高的，好的软件公司应该绝对的尊重技术人员。


要做好的软件必须遵守行业里的基本原则，这些都是老前辈头破血流换来的经验，而我们有几个知道或者珍惜？

1，单一职责原则

就一个类而言，应该仅有一个引起他变化的原因，通俗点就是绝对的不要多管闲事，做你最能够做的事情，高标准高质量完成，如果你只能够非常优秀操作PS,你就不要去对Java程序员指手画脚。

2，开放封闭原则

软件实体（类，模块，函数等等）应该是可以扩展的，但是不可修改。这似乎是个伪命题，要扩展居然不准修改，其中的奥妙就是抽象，你只要稳定的抽象了变化，你就可以做到。就像如来的五指山，你逃不过我的抽象。

3，里氏替换原则

子类型必须能够替换掉他们的基类型，在和父亲对象交互的时候，如果以后变成他的儿子，也是可以的，比如和富一代谈生意签合同，如果换做富二代也是可行的，可是现在富二代不行了，那就违背了这个原则。

4，依赖倒置原则

为什么要特别注重倒置？肯定是原来做错了，我们必须倒过来纠正，原来怎么做的? 上依赖下，抽象依赖实现，我们应该让下依赖于上，比如数据库依赖于领域模型，实现依赖于抽象，这样的软件才足够健壮和可扩展。

5，接口隔离原则

不应该强迫客户依赖于他们不用的方法，就是不要把胖的肥的香的辣的打包给你吃，而是要一刀一刀切开来喂你，这样就可以让很多人组合口味，而不是你说这团不好吃，就把别个觉得好吃的组合扔了。这个原则和单一职责原则比较相似，都是提高内聚性的原则。