如果做网站赚钱视频图站主题 wordpress

当前位置： 首页 > news >正文

如果做网站赚钱,视频图站主题 wordpress,可以给别人做ps设计的网站,天水市网站建设概述 本章#xff0c;先来回顾下整个专栏的知识体系#xff0c;主要包括面向对象、设计原则、编码规范、重构技巧、设计模式五个部分。 面向对象 相对于面向过程、函数式编程#xff0c;面向对象是现在最主流的编程范式。纯面向过程的编程方法#xff0c;现在已经不多见了…概述 本章先来回顾下整个专栏的知识体系主要包括面向对象、设计原则、编码规范、重构技巧、设计模式五个部分。 面向对象 相对于面向过程、函数式编程面向对象是现在最主流的编程范式。纯面向过程的编程方法现在已经不多见了而新的函数式编程因为它的应用场景比较局限所以大多作为面向对象编程的一种补充用在科学技术、大数据处理等特殊领域。 面向对象提供了丰富的特性比如封装、抽象、继承、多态有助于实现复杂的设计思路是很多设计原则、设计模式等编程实现的基础。 在面向对象第一部分需重点掌握面向对象的四大特性封装、抽象、继承、多态以及面向对象编程与面向过程编程的区别。需要特别注意的是在平时的面向对象编程开发中我们要尽量避免写出面向过程风格的代码。 此外还重点学习了面向对象分析OOA、设计OOD、编程OOP。其中面向对象分析就是需求分析面向对象设计就是代码层面设计输出的设计结果是类。面向对象编程就是将设计的结果翻译成代码的过程。 在专栏中重点讲解了面向对象设计这一部分。我们可以把面向对象设计分为四个环节划分职责并识别出有哪些类、定义类的属性和方法、定义类之间的交互关系、组装类并提供执行入口。通过几个案例带你实战了一下设计过程希望你能面向开发需求时不会无从下手做到有章可循按照我们给出的步骤有条不紊地完成设计。 在面向对象这一部分还额外讲到两个思想基于接口而非实现编程设计思想、多用组合少用继承的设计思想。这两个设计思想虽然简单但非常实用应用它们能让代码更加灵活更加容易扩展所以这两个设计思想几乎贯穿在我们整个专栏的代码中。 设计原则 在专栏的开始我们总结了一套评判代码质量的标准比如可读性、可维护性、可扩展性、复用性等这是自从代码整理质量的角度来评判的。但是落实到具体细节我们往往是从是否符合设计原则来对代码进行评判。比如我们说这段代码的可扩展性比较差主要原因是违背了开闭原则。也就是说相对于可读性、可维护性、可扩展性等代码整体质量的评判标准设计原则更加具体能够更加明确地指出代码存在的问题。 在专栏中讲解的设计原则包括SOLID 原则、DRY 原则、KISS 原则、YAGNI 原则、LOD 原则。这些原则的定义都很简单看似很好理解但也都比较抽象比较难落地指导具体的编程。所以学习的重点是透彻理解它们的设计初衷找你给我它们能解决哪些编程问题有哪些常用的应用场景。 SOLID 原则并非一个原则。它包含单一职责原则SRP、开闭原则OCP、里氏替换原则LSP、接口隔离原则ISP、依赖倒置原则DIP。其中里氏替换和接口隔离这两设计原则并不那么常用稍微了解即可。我们重点学习了单一职责、开闭、依赖倒置这三个原则。 单一职责原则是类职责划分的重要参考依据是保证 “高内聚” 的有效手段是面向对象设计前两步划分职责并识别出有哪些类、定义类及其属性和方法的主要指导原则。单一职责原则的难点在于对代码职责是否足够单一的判定。这要根据具体的场景来具体分析。同一个类的设计在不同的场景下对职责是否单一的判定可能是不同的。 开闭原则是保证代码扩展性的重要指导原则是对代码扩展性的具体解读。很多设计模式诞生的初衷都是为了提高代码的扩展性都是以满足开闭原则为设计目的。实际上尽管开闭原则的描述为对扩展开放、对修改关闭但也并不是说杜绝一切代码修改正确的理解是以最小化修改代价来完成新功能的添加。实际上在平时的开发中我们要时刻思考目前的设计在以后应对新功能扩展时是否能做到不需要大的修改比如调整代码接口就能完成。 依赖倒置原则主要用来指导框架层面的设计。高层模块不依赖低层模块它们共同依赖一个抽象。深挖一下的话我们要把它和控制反转、依赖注入、依赖注入框架做区分。实际上比依赖倒置原则更加常用的是依赖注入。它用来指导如何编写可测试性代码换句话说编写可测试代码的诀窍就是依赖注入。 KISS、YAGNI 可以说是两个万金油原则小到代码、大到架构、产品很多场景都能套用这两条原则。其中YAGNI 原则表示暂时不需要的就不要做KISS 原则表示要做就要尽量保持简单。跟单一职责原则类似掌握这两个原则的难点在于对代码是否符合 KISS、YAGNI 原则的判断也需要根据具体的场景来具体分析在某个时间点、某个场景下某段代码符合 KISS、YAGNI 原则换个时间、换个场景可能就不符合了。 DRY 原则主要是体现你不要写重复代码这个倒不难掌握。LOD 原则又叫最小知道原则不该有直接依赖关系的类不要有依赖有依赖关系的类之间尽量只依赖必要的接口。如果说单一职责原则是为了实现 “高内聚”那这个原则就是为了实现 “松耦合”。 编码规范 编码规范很重要特别是对于开发经验不多的程序员遵从哈ode编码规范能让你写出来的代码至少不会太烂。而且编码规范都比较具体不像设计原则、模式、思想那样比较抽象需要融入很多个人的理解和思考。所以它落地执行起来更加容易。 虽然我们讲了很多设计思想、原则、模式但是大部分代码都不需要用到这么复杂的设计即便用到可能也就是用到极个别的知识点而且用的也不会很频繁。但是编码规范就不一样了。编码规范影响到你写的每个类、函数、变量。你编写每行代码的时候都要思考是否符合编码规范。 此外编码规范主要解决代码的可读性问题。在编写代码时我们要把可读性放到首位。只有在代码可读性比较好的情况下再去思考代码的扩展性、灵活性等。一般来说一个可读性比较好的代码对它修改、扩展、重构都不是难事因为这些工作的前提都是先读懂代码。 不过专栏只是总结了一些最常用的、最能明显改善代码质量的编码规范。你可以自己参考其他学习资料比如《重构》、《代码大全》、《代码整洁之道》等书籍。 重构技巧 重构作为保证代码质量不腐化的有效手段利用的是面向对象、设计原则、设计模式、编码规范这些理论。在重构过程中 我们用到代码质量评判标准来评判代码的整体质量然后对照设计原则来发现代码存在的具体问题最后用设计模式或者编码规范对存在的问题进行改善。 持续重构除了能保证代码质量不腐化之外还能有效地避免过度设计。有了持续重构意识我们就不会因为担心设计不足和过度设计。我们先按照最简单的设计思路来设计然后在后续的开发过程中逐步迭代重构。 我们还对重构进行了粗略的分类分为大规模高层次的重构和小规模低层次的重构。不管哪种重构保证重构不出错除了熟悉代码之外还有就是完善的单元测试。 设计模式 如果说设计原则相当于编程心法那设计模式就相当于具体的招式。设计模式是针对软件开发中经常遇到的一些设计问题总结出来的一套解决方案或者设计思路。我们用设计原则来评判代码设计有哪些问题然后再通过具体的设计模式来改善。相对于其他部分来讲设计模式时最容易学习的但也是最容易被滥用的。所以在《实际开发中如何避免过度设计如何避免设计不足》章节专门讲解了如何避免过度设计。 经典的设计模式有 23 中分为三种类型创建型、结构型和行为型。 创建型设计模式主要解决 “对象的创建” 问题结构型设计模式主要解决 “类或对象的组合” 问题行为型设计模式主要解决 “类或对象之间的交互” 问题。 虽然专栏中讲到的设计模式有很多但常用的并不多主要有单例、工厂、建造者、代理、装饰器、适配器、观察者、模板、策略、职责链、迭代器这 11 种所以你只要集中精力把这 11 种搞明白就可以了剩下的那 12 种稍微了解等到真正用到时再深入地去研究学习就可以了