03 | 面向对象、设计原则、设计模式、编程规范、重构，这五者有何关系？

再好的理论，应用不到实际中也是白费。所以对于提升代码质量，最有效的是编码规范，其次是设计原则，再次是代码重构，最后才是面向对象和设计模式。 整个排序是按照我理解的难易程度来进行的。一般一个项目都是多人开发，多人并行开发中，考虑到团队中技术水平不一，保持代码质量最好的方式就是先制定编码规范，大家最容易达成一致并遵守。其次是设计原则，因为它相对来讲更明确，违反设计原则基本等于硬伤，更容易得到认同。代码重构是需要长期去做的，甚至不是在开发过程中而是在维护过程中去做的，所以排在第三位。后面两项更多的要考虑实际情况，不同水平的人甚至相同水平的人都会有自己不同的理解，比较难以达成统一，项目排期足够还好，一旦排期不足，很可能在当时没那个成本去谈论这些。 第二个问题老师已经回答了，因为面向对象的特性是其他的基石。 建议老师在后续课程中，除了讨论如何提升自己的代码质量，也讨论一下在一个多人团队中如何提升团队的代码质量，有哪些比较好的手段可以去应用。包括在项目排期比较紧的时候，可以有哪些方式去保证代码质量。

面向对象的特征也未必包含“继承”这一点吧，比如 Go 语言就没有提供“继承”这个特性，取而代之的是，推荐使用“组合”。但不能说它不支持面向对象编程。那么我们在探讨“面向对象”这个范式时，需要更深刻的去思考“面向对象”的本质是什么。而不是用Java 中的概念来一以概之。希望王争老师参考。

争哥，设计模式有三种类型： 创建型：这个好理解，就是用来创建对象的一些模式 结构型和行为型不好理解，结构体现在哪里？行为又体现在哪里？能否说的更具体点？

我看到设计原则中还有迪米特法则(Law of Demeter, LoD)，这个也是解决God类的一种方式。另外这个法则，好像跟组合复用相背呢。帮忙解释一下。

对于重构，我有话（槽）要说（吐）：我是做企业项目外包的，我们给客户交付的项目大多在客户方面庞杂缺少弹性的IT合规性要求和业务快速变动的现实的双重夹击下痛苦地演进着。重构意味着不改变系统已有功能的情况下优化项目代码，但面临着合规性和流程的限制导致这类无业务功能更新的发布不会被甲方IT放行；另一方面不断的新需求的变更又不断地劣化着已有代码的系统架构以及业务代码的设计。不知道有没有面临同样问题的同学，在无法改变现有大环境的前提下进行有限的优化？我们现在能做的也就是在每一次追加的新需求变更时进行小幅度的改善，但这无法受到任何工作流程的保护和管理，仅能靠程序员个人的良心来做。另外，如何保证重构不会因为代码结构的变化引入新的bug呢？单元测试以及覆盖率较高的自动化测试吗？

一直跟着pojo，controller，service转写不出好的代码

设计原则是指导设计模式的更抽象的理论（这么说应该对吧） 另外有个困惑就是在编码规范的时候，自我感觉英语还可以，但是函数，变量命名的时候经常会犯纠结症和强迫症。。。不知道怎么命名才好。

我觉得编程规范是最有效的一种方法，选择它就表示认可了可读性是代码质量最核心的一点。因为它不仅好学、好上手，用起来效果还明显。不像其它的方法对个人经验的依赖性强。还有个例子证明它的重要性，听说Google入职前几个月最先做的事情是把他们的编程规范熟记于心。

面向对象的特性，有些地方说是4个，有些地方说是3个，一脸懵逼

老师我有疑问，在没有充分必要的情况下是不是不采用面向对象编程（继承+多态），大多数情况下使用基于对象的方式进行编程（封装+组合）？