解决问题的3W原则

Posted

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了解决问题的3W原则相关的知识,希望对你有一定的参考价值。

参考技术A 参考博客:

http://www.360doc.com/content/17/0531/09/37009981_658634414.shtml

解决普通问题,可能我们大脑一想就知道怎么回事了。根本不需要专门去想什么3W原则。因为在无意识状态下,我们的小脑袋已经迅速完成了3W的思考过程。

对于复杂问题,我们可能并没有明确的思路,像无头苍蝇一样,乱撞。撞得头破血流依然不知道原由。那会,我们的大脑可能已经成为了一锅浆糊,怎么可能找到解决问题的思路呢?

这个时候,我们就需要拿出3W这个大杀器来解决问题了。大招一出,谁能阻挡。😁

3W其实就是三问:what,where,how;

1.what:界定问题,搞清楚问题到底是什么;

2.why:分析问题,结构化分析问题的本质原因是什么;

3.how:解决问题,应用目标导向思维解决问题;

工程师的基本修养 — 面向对象六大原则介绍

技术图片

首先简单说下面向对象。软件在机器中运行,用来解决实际问题,解决一个问题一定有先后顺序,只要把问题拆解开,然后一件一件的顺序完成,问题大都可以解决,这就是面向过程的编程。

但是对于更加复杂的模型,如果继续使用面向过程的编程,一些程序就会变得不容易控制了。为了更好解决问题,需要对这个世界进行抽象,把一个任务、一个程序拆分成更容易控制和理解的小块,小块间定义好使用原则等,然后在大块中,用逻辑把所有模块都运行起来,有相同特性的模块可以通过继承去更好的管理,还可以定义一些接口约束,让模块都具有同样的外观,等等,这大概就是面向对象。

面向对象的基本原则:万物皆对象,最早的面向对象语言应该是 SmallTalk。

这世界中不论具体存在的事务还是虚拟的东西,都可以当它当成对象,比如现实世界中具体存在的轮船、飞机,还有虚拟的东西,比如任务进度、商品评价,都可以把他们当做对象,只需要对它们进行抽象,就可以把一切都构造为对象,然后用编程语言把他们组装在一起,加以逻辑处理,界面展示,用面向对象就可以解决实际问题了。

面向对象三大特征

面向对象有三大特征:封装、继承、多态。这也是整个面向对象的核心,只要理解了这几点,就可以写出面向对象的程序。

封装可以把独立的东西包装成一块,经过封装,一个对象就成型了。比如要封装轮船,它有很多属性,比如重量、大小、速度、使用年限等,还有很多功能,比如启动、停止、装卸等方法,这些所有的属性、方法都包在了一个类里,然后提供出去,这样别人拿到包后,就可以直接使用,这就是封装。

继承可以更好的利用已有的设计、封装。对于有共同特点,有继承关系的对象来说,通过继承可以方便的共享父类逻辑,更好的控制程序。

多态主要通过接口实现,在运行时根据具体类型,调用同样的方法,但是实现由具体实现类控制。用了的人都说好。

面向对象六大原则

面向对象很好,但是同样是面向对象,不同的人可能写出完全不一样的程序,有好有坏。为了让大家写出好的好像对象程序,前辈们总结除了六大原则,只要能够理解并应用这些原则,大家就可以写出不错的面向对象程序。同时这样,大家如果都按照这些原则写,互相看代码、理解代码也就变得更加容易了。

以下六大原则具体说明参考自网络资料,面向对象六大原则和设计模式 | Melo‘s Blog

单一职责

一个类而言,应该仅有一个引起他变化的原因。也就是说一个类应该只负责一件事情。

就是说一个类、一个方法应该只做一件事,这样可以保持类、方法的单纯,没有任何杂乱因素,使用和维护都会变得很容易,Less is more。

开闭原则

尽量通过扩展应用程序中的类、模块和函数来解决不同的需求场景,而不是通过直接修改已有的类、模块和函数。

一个软件实体类,模块和函数应该对扩展开放,对修改关闭。在软件的生命周期内,因为变化、升级和维护等原因,需要对软件原有的代码进行修改时,可能会给旧代码引入错误。因此,当软件需要变化时,我们应该尽量通过扩展的方式来实现变化,而不是通过修改已有的代码来实现。

已有的类、方法可能已经运行了很久,他们也许有问题,但是尽量不要直接去改动它们,风险很大,不如对它们进行包装,通过外部方式提高他们。

里氏替换

里氏替换原则就是依赖于继承、多态这两大特性。里氏替换原则简单来说就是所有引用基类、接口的地方必须能透明地使用其子类的对象。通俗点讲,只要父类能出现的地方子类就可以出现,而且替换为子类也不会产生任何报错或者异常,使用者可能根本就不需要知道是子类还是父类。但是,反过来就不行了,有子类出现的地方,父类未必就能使用。

依赖倒置

高层模块不应该依赖底层模块,两者都应该依赖其抽象;抽象不应该依赖细节;细节应该依赖抽象

  • 高层模块不应该依赖底层模块,两者都应该依赖其抽象。
  • 抽象不应该依赖细节。
  • 细节应该依赖抽象。

接口隔离

客户端应该依赖于它不需要的接口:一个类对另一个类的依赖应该建立在最小的接口上。根据接口隔离原则,当一个接口太大时,我们需要把它分离成一些更细小的接口,使用该接口的客户端仅需知道与之相关的方法即可。

迪米特法则

一个对象应该对其他对象保持最小的了解。

只提供自己该提供的,只了解自己该了解的。这一点具体实践指南就是,不要暴露出过多的方法、属性,优先把它们设计为私有的,只需要需要用到了,再去考虑开放访问权限。

参考链接

以上是关于解决问题的3W原则的主要内容,如果未能解决你的问题,请参考以下文章

java异常总结

可收藏3W字,Docker 从入门到精通

解决SpringBoot多模块发布时99%的问题?SpringBoot发布的8个原则和4个问题的解决

Bug解决过程复盘

解决max解析记录与cname不能共存的问题

十步法原则解决数据质量问题