设计模式之美学习笔记10: 组合优于继承
📅 2019-11-25
今天继续打卡学习极客时间上的专栏“设计模式之美”, 本篇是专栏第9节的学习笔记,第10节是专栏中介绍"面向对象"这一设计原则和设计思想的一节。
笔记 #
组合优于继承,多用组合少用继承是面向对象编程中非常经典的一条设计原则。
继承虽然是面向对象的四大特性之一,使用继承可以解决代码复用的问题,但也有其缺点: 继承层次过深、过于复杂会影响到代码的可维护性
...今天继续打卡学习极客时间上的专栏“设计模式之美”, 本篇是专栏第9节的学习笔记,第10节是专栏中介绍"面向对象"这一设计原则和设计思想的一节。
组合优于继承,多用组合少用继承是面向对象编程中非常经典的一条设计原则。
继承虽然是面向对象的四大特性之一,使用继承可以解决代码复用的问题,但也有其缺点: 继承层次过深、过于复杂会影响到代码的可维护性
...今天继续打卡学习极客时间上的专栏“设计模式之美”, 本篇是专栏第9节的学习笔记,第9节是专栏中介绍"面向对象"这一设计原则和设计思想的一节。
基于接口编程(Interface-based programing)
是一个设计原则,理解这条原则里的接口
两字,接口
是一组协议
或约定
。
接口这个词在不同场景下有不同的含义,比如后端服务提供给前端服务的"接口"、类库提供的"接口"、而一组自定义的私有通信协议也可以被称作"接口",而具体编程语言中的接口一般指的是这种编程语言中的"接口或抽象类"的语法特性。我们再来看一下维基百科中“基于接口编程”的定义:
基于接口编程也称基于接口的架构,它是一种在没有模块系统的面向对象程序设计语言中的组件层面实现模块化编程的架构模式。
今天继续打卡学习极客时间上的专栏“设计模式之美”, 本篇是专栏第8节的学习笔记,第8节是专栏中介绍"面向对象"这一设计原则和设计思想的一节。
很多面向对象的语言都提供"抽象类"和"接口"这两个语法特性。抽象类和接口是实现面向对象四大特性、很多设计模式、设计思想、设计原则的基础。 但并不是所有编程语言都支持者两个语法特性,我们可以通过一些手段来模拟这它们。
...今天继续打卡学习极客时间上的专栏“设计模式之美”, 本篇是专栏第7节的学习笔记,第7节是介绍"面向对象"这一设计原则和设计思想的一节。
本节主要介绍了几种在使用面向对象语言进行编程时违反面向对象编程风格的代码设计(作者主要从Java开发的角度):
...今天继续打卡学习极客时间上的专栏“设计模式之美”, 本篇是专栏第6节的学习笔记,第6节是专栏中介绍"面向对象"这一设计原则和设计思想的一节。
本节主要对比了面向对象与面向过程的优势,是偏理论性的一节。提到了大家比较熟知的三种编程范式: 过程式
、面向对象
、函数式
。
因为函数式编程和GOF设计模式
的套路关系不大,所以作者王争老师也说了在专栏中不会涉及函数式编程。
另外在编程语言中还有一种面向消息
的编程方式,本节没有提及。
最近在学极客时间上的专栏“设计模式之美”,决定跟随专栏的更新,立一个flag,坚持打卡每节都写一篇笔记,作为对学习过程的巩固,以加深理解和思考。本篇是专栏第5节的学习笔记,第5节是专栏中介绍"面向对象"这一设计原则和设计思想的一节。
在过去我们学习各种面向对象编程语言(比如java)时,一般多会说面向对象有三大特性: 封装、继承和多态。而专栏中也将"抽象"作为第四个特性加入其中。
封装即信息隐藏或数据保护,“数据结构"通过暴露有限的访问接口,授权外部仅能通过"数据结构"提供的方法(函数)来访问其内部的数据。
...frp是一个使用go语言开发的反向代理服务,可用于内网穿透,支持tcp, udp协议,为http和https协议提供了额外的能力,且尝试性支持了点对点穿透。 由于ngrok 2.x已经闭源,ngrok 1.x已不再维护,所以这里尝试使用frp替代ngrok作为个人的内网穿透工具。
...ngrok是使用go语言开发的反向代理服务,可以在公共的端点和本地内网的Web服务之间建立一个安全通道,实现内网穿透功能。 虽然ngrok 2.x的版本已经闭源,但ngrok 1.x还是开源的,版本停留在了1.7不再开发和维护,但它作为个人平时开发和调试的内网穿透工具偶尔使用还是够用的。之前小白的ngrok部署在个人的一台AWS EC2主机上已有好几年,最近这台EC2释放掉了,小白需要在新的主机上部署ngrok服务,正好借着这个机会整理一下ngrok的部署和配置过程。
...DDD中根据问题域将问题划分为领域
、子域
、通用语言
、界限上下文
、架构风格
等概念
领域是一个业务范围以及这个业务范围内的软件活动。领域层是具体的业务领域层,是发生业务频繁发生变化的地方,是业务系统最核心的一层,是DDD关注的焦点和难点。
...Service Mesh即服务网格,是云原生核心技术之一。
Service Mesh伴随着微服务技术发展而产生,由于微服务架构的复杂性,对微服务的治理在服务注册与发现、负载均衡、故障处理与恢复、动态路由请求、协议转换、分布式链路追踪、RPC调用、统一认证授权、服务监控、故障注入、安全加密等方面面临着严峻的挑战。在微服务架构中服务组件复杂、服务治理等都成为了痛点,需要对业务开发人员"隐藏"微服务基础组件和服务治理的复杂性,使其对业务开发人员透明。 微服务本身虽然复杂,但很多的这些复杂性和服务的业务没有关系,即微服务的业务和微服务之间的通信没有关系,那么能否把微服务的技术栈往下移动到通信层呢?Service Mesh随之出现,Service Mesh通过独立进程的方式隔离微服务基础组件,那么对这个独立进程进行运维要比传统的微服务内的基础组件的方式简单的多了。
...