技术

go设计哲学 ceph学习 学习mesh kvm虚拟化 学习MQ go编译器 学习go 为什么要有堆栈 汇编语言 计算机组成原理 运行时和库 Prometheus client mysql 事务 mysql 事务的隔离级别 mysql 索引 坏味道 学习分布式 学习网络 学习Linux go 内存管理 golang 系统调用与阻塞处理 Goroutine 调度过程 重新认识cpu mosn有的没的 负载均衡泛谈 单元测试的新解读 《Redis核心技术与实现》笔记 《Prometheus监控实战》笔记 Prometheus 告警学习 calico源码分析 对容器云平台的理解 Prometheus 源码分析 并发的成本 基础设施优化 hashicorp raft源码学习 docker 架构 mosn细节 与微服务框架整合 Java动态代理 编程范式 并发通信模型 《网络是怎样连接的》笔记 go channel codereview gc分析 jvm 线程实现 go打包机制 go interface及反射 如何学习Kubernetes 《编译原理之美》笔记——后端部分 《编译原理之美》笔记——前端部分 Pilot MCP协议分析 go gc 内存管理玩法汇总 软件机制 istio流量管理 Pilot源码分析 golang io 学习Spring mosn源码浅析 MOSN简介 《datacenter as a computer》笔记 学习JVM Tomcat源码分析 Linux可观测性 学习存储 学计算 Gotty源码分析 kubernetes operator kaggle泰坦尼克问题实践 kubernetes垂直扩缩容 神经网络模型优化 直觉上理解深度学习 如何学习机器学习 神经网络系列笔记 TIDB源码分析 什么是云原生 Alibaba Java诊断工具Arthas TIDB存储——TIKV 《Apache Kafka源码分析》——简介 netty中的线程池 guava cache 源码分析 Springboot 启动过程分析 Spring 创建Bean的年代变迁 Linux内存管理 自定义CNI IPAM 副本一致性 spring redis 源码分析 kafka实践 spring kafka 源码分析 Linux进程调度 让kafka支持优先级队列 Codis源码分析 Redis源码分析 C语言学习 《趣谈Linux操作系统》笔记 docker和k8s安全访问机制 jvm crash分析 Prometheus 学习 容器日志采集 Kubernetes 控制器模型 Kubernetes监控 容器狂占资源怎么办? Kubernetes资源调度——scheduler 时序性数据库介绍及对比 influxdb入门 maven的基本概念 《Apache Kafka源码分析》——server Kubernetes类型系统 源码分析体会 《数据结构与算法之美》——算法新解 Kubernetes源码分析——controller mananger Kubernetes源码分析——apiserver Kubernetes源码分析——kubelet Kubernetes介绍 ansible学习 Kubernetes源码分析——从kubectl开始 jib源码分析之Step实现 jib源码分析之细节 线程排队 跨主机容器通信 jib源码分析及应用 为容器选择一个合适的entrypoint kubernetes yaml配置 《持续交付36讲》笔记 mybatis学习 程序猿应该知道的 无锁数据结构和算法 CNI——容器网络是如何打通的 为什么很多业务程序猿觉得数据结构和算法没用? 串一串一致性协议 当我在说PaaS时,我在说什么 《数据结构与算法之美》——数据结构笔记 PouchContainer技术分享体会 harbor学习 用groovy 来动态化你的代码 精简代码的利器——lombok 学习 《深入剖析kubernetes》笔记 编程语言的动态性 rxjava3——背压 rxjava2——线程切换 spring cloud 初识 《深入拆解java 虚拟机》笔记 《how tomcat works》笔记 hystrix 学习 rxjava1——概念 Redis 学习 TIDB 学习 分布式计算系统的那些套路 Storm 学习 AQS1——论文学习 Unsafe Spark Stream 学习 linux vfs轮廓 《自己动手写docker》笔记 java8 实践 中本聪比特币白皮书 细读 区块链泛谈 比特币 大杂烩 总纲——如何学习分布式系统 hbase 泛谈 forkjoin 泛谈 看不见摸不着的cdn是啥 《jdk8 in action》笔记 程序猿视角看网络 bgp初识 calico学习 AQS——粗略的代码分析 我们能用反射做什么 web 跨域问题 《clean code》笔记 《Elasticsearch权威指南》笔记 mockito简介及源码分析 2017软件开发小结—— 从做功能到做系统 《Apache Kafka源码分析》——clients dns隐藏的一个坑 《mysql技术内幕》笔记 log4j学习 为什么netty比较难懂? 回溯法 apollo client源码分析及看待面向对象设计 学习并发 docker运行java项目的常见问题 Scala的一些梗 OpenTSDB 入门 spring事务小结 分布式事务 javascript应用在哪里 《netty in action》读书笔记 netty对http2协议的解析 ssl证书是什么东西 http那些事 苹果APNs推送框架pushy apple 推送那些事儿 编写java框架的几大利器 java内存模型 java exception Linux IO学习 netty内存管理 测试环境docker化实践 netty在框架中的使用套路 Nginx简单使用 《Linux内核设计的艺术》小结 Go并发机制及语言层工具 Linux网络源代码学习——数据包的发送与接收 《docker源码分析》小结 docker namespace和cgroup Linux网络源代码学习——整体介绍 zookeeper三重奏 数据库的一些知识 Spark 泛谈 链式处理的那些套路 netty回顾 Thrift基本原理与实践(二) Thrift基本原理与实践(一) 回调 异步执行抽象——Executor与Future Docker0.1.0源码分析 java gc Jedis源码分析 Redis概述 深度学习泛谈 Linux网络命令操作 JTA与TCC 换个角度看待设计模式 Scala初识 向Hadoop学习NIO的使用 以新的角度看数据结构 并发控制相关的硬件与内核支持 systemd 简介 quartz 源码分析 基于docker搭建测试环境(二) spring aop 实现原理简述 自己动手写spring(八) 支持AOP 自己动手写spring(七) 类结构设计调整 分析log日志 自己动手写spring(六) 支持FactoryBean 自己动手写spring(九) 总结 自己动手写spring(五) bean的生命周期管理 自己动手写spring(四) 整合xml与注解方式 自己动手写spring(三) 支持注解方式 自己动手写spring(二) 创建一个bean工厂 自己动手写spring(一) 使用digester varnish 简单使用 关于docker image的那点事儿 基于docker搭建测试环境 分布式配置系统 JVM执行 git maven/ant/gradle使用 再看tcp kv系统 java nio的多线程扩展 《Concurrency Models》笔记 回头看Spring IOC IntelliJ IDEA使用 Java泛型 vagrant 使用 Go常用的一些库 Python初学 Goroutine 调度模型 虚拟网络 《程序员的自我修养》小结 Kubernetes存储 访问Kubernetes上的Service Kubernetes副本管理 Kubernetes pod 组件 Go基础 JVM类加载 硬币和扑克牌问题 LRU实现 virtualbox 使用 ThreadLocal小结 docker快速入门

架构

《动手学深度学习》笔记 python与线性回归 多活 volcano 特性源码分析 推理服务 kubebuilder 学习 mpi pytorch client-go学习 tensorflow 提高gpu 利用率 GPU与容器的结合 GPU入门 AI云平台 tf_operator源码分析 k8s批处理调度 喜马拉雅容器化实践 Kubernetes 实践 学习rpc BFF 生命周期管理 openkruise学习 可观察性和监控系统 基于Kubernetes选主及应用 《许式伟的架构课》笔记 Kubernetes webhook 发布平台系统设计 k8s水平扩缩容 Scheduler如何给Node打分 Scheduler扩展 controller 组件介绍 openkruise cloneset学习 controller-runtime源码分析 pv与pvc实现 csi学习 client-go源码分析 kubelet 组件分析 调度实践 Pod是如何被创建出来的? 《软件设计之美》笔记 mecha 架构学习 Kubernetes events学习及应用 CRI 《推荐系统36式》笔记 资源调度泛谈 系统设计原则 grpc学习 元编程 以应用为中心 istio学习 下一代微服务Service Mesh 《实现领域驱动设计》笔记 serverless 泛谈 概率论 《架构整洁之道》笔记 处理复杂性 那些年追过的并发 服务器端编程 网络通信协议 《聊聊架构》 书评的笔记 如何学习架构 《反应式设计模式》笔记 项目的演化特点 反应式架构摸索 函数式编程的设计模式 服务化 ddd反模式——CRUD的败笔 研发效能平台 重新看面向对象设计 业务系统设计的一些体会 函数式编程 《左耳听风》笔记 业务程序猿眼中的微服务管理 DDD实践——CQRS 项目隔离——案例研究 《编程的本质》笔记 系统故障排查汇总及教训 平台支持类系统的几个点 代码腾挪的艺术 abtest 系统设计汇总 《从0开始学架构》笔记 初级权限系统设计 领域驱动理念入门 现有上传协议分析 移动网络下的文件上传要注意的几个问题 推送系统的几个基本问题 用户登陆 做配置中心要想好的几个基本问题 不同层面的异步 分层那些事儿 性能问题分析 当我在说模板引擎的时候,我在说什么 用户认证问题 资源的分配与回收——池 消息/任务队列

标签


重新看面向对象设计

2018年10月01日

简介

我一直有一个比方,如果把程序员写程序比作史官写历史,那么面向过程就是编年体通史,而面向对象更像是纪传体通史。编年体通史以时间(或一段时间)为中心,而纪传体通史则以人物为中心,譬如《史记》的《高祖本纪》等。类似的,面向过程多认为程序由一个个函数组成(依照顺序先后调用),譬如历史由一件件大事组成。而面向对象倾向于认为程序由一个个对象组成,譬如历史由一个个人的故事组成。

Is Inheritance Dead? A Detailed Look Into the Decorator Pattern未读完

抽象

程序员必备的思维能力:抽象思维

抽象层次/分层抽象:抽象是以概念(词语)来反映现实的过程,每一个概念都有一定的外延和内涵.概念的外延就是适合这个概念的一切对象的范围,而概念的内涵就是这个概念所反映的对象的本质属性的总和.例如“平行四边形”这个概念,它的外延包含着一切正方形、菱形、矩形以及一般的平行四边形,而它的内涵包含着一切平行四边形所共有的“有四条边,两组对边互相平行”这两个本质属性。一个概念的内涵愈广,则其外延愈狭;反之,内涵愈狭,则其外延愈广,泛化能力越强。然而,其代价就是业务语义表达能力越弱。 例如,“平行四边形”的内涵是“有四条边,两组对边互相平行”,而“菱形”的内涵除了这两条本质属性外,还包含着“四边相等”这一本质属性。“菱形”的内涵比“平行四边形”的内涵广,而“菱形”的外延要比“平行四边形”的外延狭。所谓的抽象层次就体现在概念的外延和内涵上,这种层次性,基本可以体现在任何事物上。每一个抽象层次都有它的用途,对于我们工程师来说,如何拿捏这个抽象层次是对我们设计能力的考验,抽象层次太高和太低都不行。

我经常开玩笑说,你把所有的类都叫Object,把所有的参数都叫Map的系统最通用,因为Object和Map的内涵最小,其延展性最强,可以适配所有的扩展。从原理上来说,这种抽象也是对的,万物皆对象嘛。但是这种抽象又有什么意义呢?它没有表达出任何想表达的东西,只是一句正确的废话而已。越抽象,越通用,可扩展性越强,然而其语义的表达能力越弱。越具体,越不好延展,然而其语义表达能力很强。所以,对于抽象层次的权衡,是我们系统设计的关键所在,也是区分普通程序员和优秀程序员的关键所在。

编程就是压缩

  1. static compression 的目标:给定所有的当前需求,最小化整体的实现代码量。方法就是能复用就复用,不能简单的复用的,创造条件也要强行复用。
  2. generalization ability 的目标:给定过去的需求,进行合理的预测,最小化迁移到未来可能的新需求的成本。其实现手段就是保持代码整洁,有结构。但是问题在于什么叫“有结构”很难学习。相反,最小化整体的实现代码量是一个更容易销售,也更容易学习的目标。这里“合理的预测”似乎和不要预先设计是矛盾的。然而所有的“泛化”都是某种预测。整洁有结构的代码“赌”的是什么呢?赌的就是新需求大概率是 localized 的。
  3. 压缩的前提是对象本身具有内在的规律性。压缩的过程就是把规律性的部分和特异性的部分分离出来。这个也就体现在了各种“中台”,“低代码”,“DSL”的说辞之中,所谓一部分人搞定 80%,剩下的领域专家(也就是处理特异性的人)去搞定特异性的 20%。然而这里的前提是处理 20% 的人要先知道之前的工序做了哪部分的 80%,才能知道自己要做哪 20%。wetware 相比 hardware 就是自然进化的速度太慢,千兆网,万兆网,升级速度杠杠的。但是人与人的沟通还是要靠非常低效率的文字理解和声波通信。除非需求内在的 Regularity 非常强,可以用极其少量的参数组合已有功能来表达新需求,否则大概率写这 20% 代码的人会非常痛苦。这也是为什么“低代码”无法流行的根本原因。
  4. 一部分人处理 Regularity,一部分人处理 Specificity:这就是所谓“中台”,“低代码”,“DSL”。核心是 specificity 部分要足够小,才能弥补沟通成本。人类来提供 Regularity,机器处理 Specificity:一开始是 logical programming,人类要提供非常多的 regularity。后来是 probabilistic programming,人类需要提供 generating function 来编码专家经验到概率分布里。到后来 deep neural network,人类需要用 convolution filter 来用所谓 inductive bias 的方式 encourage 神经网络往某个方向学习。越来越多的程序员会从直接编码规则来驾驭机器,变成“声明式编程”。把规律性的部分提取成 what,让机器去找到 how。

继承 vs 组合

对于继承,子类通过super 可以访问父类的相关方法。对于java8 interface,也是类似。从这个角度看,如果将 this、super 理解为 类成员,继承父类、实现接口,像是组合的一种特殊形态。在c++里面,子类拥有父类的数据拷贝。那么java的内存对象模型和c的内存对象模型,研究一下,做个对比,还是蛮有意思的。以下图为例,UML 在展示PriorityKafkaProducer的继承和聚合关系时,将父类AbstractPriorityKafkaProducer和聚合类/成员KafkaProducer做了平级的处理。

分解是设计的第一步,而且分解的粒度越小越好。当你可以分解出来多个关注点,每一个关注点就应该是一个独立的模块。最终的类是由这些一个一个的小模块组合而成,这种编程的方式就是面向组合编程。它相当于换了一个视角:类是由多个小模块组合而成。

如果用 Ruby,组合的表现形式就会是一个 module;而在 Scala 里,就会成为一个 trait。使用 C++ 的话,表现形式则会是私有继承。学习多种程序设计语言的重要性:Java 只有类这种组织方式,所以,很多有差异的概念只能用类这一个概念表示出来,思维就会受到限制,而不同的语言则提供了不同的表现形式,让概念更加清晰。

许式伟:继承是个过度设计,其实继承实现了代码复用和多态两个东西,揉在一起。在 Go 里面,组合实现代码复用,接口实现多态,彼此完全独立,非常清晰。

面向对象和基于对象——多态

《解密java虚拟机》面向对象编程之所以要实现多态这一特性,最主要的目的是为了消除类型之间的耦合,也就是解耦,进而有一定余度应对变化。多态得以实现的一大前提是编程语言必须是面向对象的,否则哪来的对象与函数互相绑定一说呢?函数属于对象的一部分,便具备了封装的特性,有封装才有对象。一个函数能绑定多个不同的对象,意味着多个不同的对象有相同的行为,这是抽象/继承的含义,封装、继承成全了多态

大部分人写出的java 代码,可能只是基于对象。基于对象,通常指的是对数据的封装,以及提供一组方法对封装过的数据操作。比如 C 的 IO 库中的 FILE * 就可以看成是基于对象的。

面向对象的程序设计语言必须有描述对象及其相互之间关系的语言成分。这些程序设计语言可以归纳为以下几类:

  1. 系统中一切事物皆为对象;
  2. 对象是属性及其操作的封装体;《effective java》:尽可能地使每个类或者成员不被外界访问。
  3. 对象可按其性质划分为类,
  4. 对象成为类的实例;
  5. 实例关系和继承关系是对象之间的静态关系;
  6. 消息传递是对象之间动态联系的唯一形式,也是计算的唯一形式;
  7. 方法是消息的序列。

《软件设计之美》只使用封装和继承的编程方式,我们称之为基于对象(Object Based)编程,而只有把多态加进来,才能称之为面向对象(Object Oriented)编程。也就是说,多态是一个分水岭,将基于对象与面向对象区分开来。软件设计是一门关注长期变化的学问,只有当你开始理解了多态,你才真正踏入应对长期变化的大门。

既然多态这么好,为什么很多程序员不能在自己的代码中很好地运用多态呢?因为多态需要构建出一个抽象。构建抽象,需要找出不同事物的共同点,而这是最有挑战的部分。而遮住程序员们双眼的,往往就是他们眼里的不同之处。在他们眼中,鸡就是鸡,鸭就是鸭。寻找共同点这件事,地基还是在分离关注点上。只有你能看出来,鸡和鸭都有羽毛,都养在家里,你才有机会识别出一个叫做“家禽”的概念。在构建抽象上,接口扮演着重要的角色。首先,接口将变的部分和不变的部分隔离开来。不变的部分就是接口的约定,而变的部分就是子类各自的实现。在软件开发中,对系统影响最大的就是变化。有时候需求一来,你的代码就要跟着改,一个可能的原因就是各种代码混在了一起。比如,一个通信协议的调整需要你改业务逻辑,这明显就是不合理的。对程序员来说,识别出变与不变,是一种很重要的能力。

很多程序员在接口中添加方法显得很随意,因为在他们心目中,并不存在实现者和使用者之间的角色差异。这也就造成了边界意识的欠缺,没有一个清晰的边界,其结果就是模块定义的随意,彼此之间互相影响也就在所难免。要想理解多态,首先要理解接口的价值,而理解接口,最关键的就是在于谨慎地选择接口中的方法。相对于封装和继承而言,多态对程序员的要求更高,需要你有长远的眼光,看到未来的变化,而理解好多态,也是程序员进阶的必经之路。

只要能够遵循相同的接口,就可以表现出来多态,所以,多态并不一定要依赖于继承。比如,在动态语言中,有一个常见的说法,叫 Duck Typing,就是说,如果走起来像鸭子,叫起来像鸭子,那它就是鸭子。“多态依赖于继承”只是某些程序设计语言自身的特点。你也看出来了,在面向对象本身的体系之中,封装和多态才是重中之重,而继承则处于一个很尴尬的位置。

以 Linux 文件系统接口为例

struct file_operations {
  loff_t (*llseek) (struct file *, loff_t, int);
  ssize_t (*read) (struct file *, char __user *, size_t, loff_t *);
  ssize_t (*write) (struct file *, const char __user *, size_t, loff_t *);
  int (*open) (struct inode *, struct file *);
  int (*flush) (struct file *, fl_owner_t id);
  int (*release) (struct inode *, struct file *);
  ...
}

假设你写一个 HelloFS,那你可以这样给它赋值:

const struct file_operations hellofs_file_operations = {
    .read = hellofs_read,
    .write = hellofs_write,
};

只要给这个结构体赋上不同的值,就可以实现不同的文件系统。但是,这种做法有一个非常不安全的地方。既然是一个结构体的字段,那就有可能改写了它,像下面这样:

void silly_operation(struct file_operations* operations) {
  operations.read = sillyfs_read;
}

如此一来,本来应该在 hellofs_read 运行的代码,就跑到了 sillyfs_read 里,程序很容易就崩溃了。对于 C 这种非常灵活的语言来说,你根本禁止不了这种操作,只能靠人为的规定和代码检查。到了面向对象程序设计语言这里,这种做法由一种编程结构变成了一种语法。给函数指针赋值的操作下沉到了运行时去实现

强制类型转换是抽象层次有问题我们在写代码的过程中,什么时候会用到强制类型转换呢?子类的方法超出了父类的类型定义范围,为了能使用到子类的方法,只能使用类型强制转换将类型转成子类类型。举个例子,在苹果(Apple)类上,有一个isSweet()方法是用来判断水果甜不甜的;西瓜(Watermelon)类上,有一个isJuicy()是来判断水分是否充足的;同时,它们都共同继承一个水果(Fruit)类。我们需要挑选出甜的水果和有水分的习惯,因为pick方法的入参的类型是Fruit,所以为了获得Apple和Watermelon上的特有方法,我们不得不使用instanceof做一个类型判断。这里问题出在哪里?对于这样的代码我们要如何去优化呢?仔细分析一下,我们可以发现,根本原因是因为isSweet和isJuicy的抽象层次不够,站在更高抽象层次也就是Fruit的视角看,我们挑选的就是可口的水果,只是具体到苹果我们看甜度,具体到西瓜我们看水分而已。因此,解决方法就是对isSweet和isJuicy进行抽象,并提升一个层次,在Fruit上创建一个isTasty()的抽象方法,然后让苹果和西瓜类分别去实现这个抽象方法就好了。

面向对象的渊源——限定修改影响的范围

面向对象的编程产生的历史原因:由于面向过程编程在构造系统时,无法解决重用,维护,扩展的问题,而且逻辑过于复杂,代码晦涩难懂。PS:笔者第一次看到这句话时没有感觉,后来忘记了,看《左耳听风》时自己总结了这句,再看到这句早就看到的话时,知己二字不能形容。

《面向对象分析与设计》读书笔记 (1)- 关键的思想 要点如下

  1. 复杂性是面向对象主要解决的问题,复杂系统的5个属性

    • 层次结构,复杂性常常以层次结构的形式存在,层次结构的形式

      • 组成(”part of“)层次结构
      • 是一种“(“is a”)层次结构
    • 相对本原,这里是指构建系统的最小单位。你不需要担心基础组件是如何实现的,只要利用其外部行为即可。举个例子,你要盖一个房子,你需要砖,水泥等,这些都是一些基础组件,但是你不要自己去生产砖,水泥。
    • 分离关注,组件内的联系通常比组件间的联系更强。这一事实实际上将组件中高频率的动作(涉及组件的内部结构)和低频率的动作(涉及组件间的相互作用)区分开来
    • 共同模式,复杂系统具有共同的模式。比如小组件的复用,比如常用方案提炼为设计模式等
    • 稳定的中间形式(注意不是中间件),复杂系统是在演变中诞生的,不要一开始就期望能够构建出一个复杂的系统。要从简单系统逐步迭代到复杂的系统。
  2. 思考分解的方式

    1. 系统中每个模块代表了某个总体过程的一个主要步骤。邮寄快递时,我们先将物品准备好,找到快递员,填写快递信息,进行邮寄。在这个过程中,我们分成了4个步骤,我们更注重的是事件的顺序,而非主要关注参与者。
    2. 根据问题域中的关键抽象概念对系统进行分解。针对上面的快递邮寄的例子,采用面向对象分解时,我们分解成4个对象:物品,快递单,快递员,我。我拥有物品,然后向快递员发出请求,快递员给我快递单让我填写快递信息。然后快递员进行邮递。
  3. 编程风格,Bobrow将编程风格定义为“一种组织程序的方式,基于某种编程概念模型和一种适合的语言,其目的是使得用这种风格编写的程序很清晰”

  4. 对象模型的4个主要要素:抽象;封装;模块化;层次结构;3个次要要素:类型、持久、并发

  5. Shaw对于抽象的定义:”对一个系统的一种简单的描述或指称,强调系统的某些细节或属性同时抑制另一些细节或属性。好的抽象强调了对读者或者用户重要的细节,抑制了那些至少是暂时的非本质细节或枝节” (我以前的思维漏洞 就是不知道 抑制非本质细节)
  6. 封装的意义,复杂系统的每一部分,都不应该依赖于其他部分的内部细节。要让抽象能工作,必须将实现封装起来
  7. 模块化的意义
  8. 层次结构的意义

实现

对象的概念是它的基础,然后语言的设计者再把类型体系、软件重用机制和信息封装机制给体现出来。在这个过程中,不同的设计者会有不同的取舍。所以,希望你不要僵化地理解面向对象的概念。比如,以为面向对象就必须有类,就必须有继承;以为面向对象才导致了多态,等等。这些都是错误的理解。

要实现一门面向对象的语言,我们重点要了解三个方面的关键工作:一是编译器在语法和语义处理方面要做哪些工作;二是运行期对象的内存布局的设计;三是在存在多态的情况下,如何实现方法的绑定。

编译器前端的工作

  1. 从语法角度来看,语言的设计者要设计与类的声明和使用有关的语法。
  2. 在语义分析阶段,每个类会作为自定义类型被加入到符号表里。这样,在其他引用到该类型的地方,比如用该类型声明了一个变量,或者一个方法的参数或返回值里用到了该类型,编译器就能够做正确的引用消解。
  3. 使用类型系统的信息,在变量赋值、函数调用等地方,会进行类型检查和推断。 对象的内存布局
  4. 像 Java、Python 和 Julia 的对象,一般都有一个固定的对象头。对象头里可以保存各种信息,比如到类定义的指针、与锁有关的标志位、与垃圾收集有关的标志位,等等。
  5. 对象头之后,通常就是该类的数据成员。如果存在父类,那么就既要保存父类中的成员变量,也要保存子类中的成员变量。在生成的汇编代码里,如果要访问一个类的成员变量,其实都是从对象地址加上一个偏移量,来得到成员变量的地址。

方法的静态绑定和动态绑定

  1. 方法带有 private、static 或 final 关键字的时候。在编译期就知道去执行哪段字节码
  2. 对于重载(Overload)的情况,也就是方法名称一样、参数个数或类型等不一样的情况,也是可以在编译期就识别出来的,所以也可以通过静态绑定。
  3. 动态绑定一般通过vtable

其它

左耳听风

来自陈皓《左耳听风》付费课程,建议先看下java 语言的动态性

在面向对象编程里,计算机程序会被设计成彼此相关的对象,独立而又相互调用。传统程序主张将程序看做一系列指令,或一系列函数。面向对象设计中的每一个对象 都应该能够接受数据、处理数据并将数据传递给其它对象。

面向对象的缺点:通过对象来达到抽象效果, 把代码分散在不同的类里面。那要让它们执行起来,就需要将这些类粘合起来。设计模式以及ioc 等虽然精巧,但不得不怀疑点歪了科技树。一段代码的执行路径 obj1.func1 ==> obj2.func2 ==> obj3.func3 在函数式编程中 func1(func2(func3)) 就解决了。

换个角度想一下,架构设计从单体演化到微服务架构,固然一部分是单机无法负载,另一个原因就是单体 在维护和运维上的困难,比如一个小改动导致整个项目的重启。也就是说,架构设计之初,就越来越考虑可维护性和扩展性。架构设计不只考虑实现功能,可维护性和扩展性影响了架构设计,对应的,可维护性和扩展性影响了代码结构。指令序列或函数序列被解构,分散在各个对象中,以减少修改对整体的影响。但从上图可以看到,面向对象的优点 也直接导致了其缺点。

宏观上的系统设计与类设计

可以认为,db 就是controller-service-dao 这些类的状态。

微观上的类实现与系统模块实现

你设计一个controller-service-dao 项目 制定http api 时,肯定会想业务层面会有哪些调用,绝不会一个http api 干了一半的活儿 然后让调用方自己 访问两个 http api 自己聚合数据。对应的,我们在设计类时,根据类持有的数据/状态,一个对象可以访问数据库、可以内部操作线程,但其对外提供的interface function 应该是自洽的(对外隐藏掉不必要的细节)。类似的概念可以看 ddd(一)——领域驱动理念入门

多线程与对象的 关系

我以前的认知,线程只是一个 驱动者,驱动代码执行,对象跟线程没啥关系。一个典型的代码是

class XXThread extends Thread{
    private Business business;
    public XXThread(Business business){
        this.business = business;
    }
    public void run(){  
        // 一般适用于 task之间没有关联,线程内可以闭环掉所有逻辑,无需共享数据,线程之间无需协作
        business code
    }
}

在apollo client 中,RemoteRepository 内部聚合线程 完成配置的周期性拉取,线程就是一个更新数据的手段,只是周期性执行下而已。

class Business{
    private Data data;
    public Business(){
        Executors.newSingleThread().execute(new Runnable(){
            public void run(){
                acquireDataTimely();
            }
        });
    }
    public void acquireDataTimely(){}
    public void useData(){}
    public void transferData(){}
}

从两段代码 看,线程与对象的 主从关系 完全相反。程序的本质复杂性和元语言抽象指出:程序=control + logic。 同步/异步 等 本质就是一个control,只是拉取数据的手段。因此,在我们理解程序时,同步异步不应成为本质的存在。

喷一喷面向对象

不要为了面向对象而面向对象

2019.1.2 补充如此理解面向对象编程,有一个需求:代码检查操作系统类型,若是linux 输出:linux很不错;若是windows,输出windows 很差

  1. 过程化的方案
  2. 一般面向对象方案(os 抽象为class,一个具体os 对应一个子class)
  3. 面向对象进化:不仅弄子类,还弄一map 保存os 和 子类的关系
  4. 大神 Rob Pike 对此的评论是:根本就不需要什么Object,只需要一张小小的配置表格,里面配置了对应的操作系统和你想输出的文本。这不就完了。所谓的代码进化相当疯狂和愚蠢的,这个完全误导了对编程的认知。

还有的人喜欢用Object来替换所有的if-else语句,他们甚至还喜欢把函数的行数限制在10行以内 programming in the twenty-first century

  1. 那23个经典的设计模式和OO半毛钱关系没有,只不过人家用OO来实现罢了。设计模式就三个准则:1)中意于组合而不是继承,2)依赖于接口而不是实现,3)高内聚,低耦合。你看,这完全就是Unix的设计准则。

Don’t Distract New Programmers with OOPThe shift from procedural to OO brings with it a shift from thinking about problems and solutions to thinking about architecture. That’s easy to see just by comparing a procedural Python program with an object-oriented one. The latter is almost always longer, full of extra interface and indentation and annotations. The temptation(诱惑) is to start moving trivial bits of code into classes and adding all these little methods and anticipating(预料) methods that aren’t needed yet but might be someday. 封装对象、类、接口等对很多简单代码来说是不必要的。

When you’re trying to help someone learn how to go from a problem statement to working code, the last thing you want is to get them sidetracked(转移话题) by faux(人造的)-engineering busywork(作业、额外工作). Some people are going to run with those scraps(点滴) of OO knowledge and build crazy class hierarchies and end up not as focused on on what they should be learning. Other people are going to lose interest because there’s a layer of extra nonsense(无意义的) that makes programming even more cumbersome(笨重的).

面向对象逼着你除了思考问题本身外,还要思考结构、设计,很多人无此意识或功力不足, 滥用面向对象的特性,整出大量无意义的代码,使得代码复杂度大大超过了问题本身的复杂度。

走偏的controller-service-dao

controller-service-dao说白了,跟面向对象没啥关系,说面向过程也不算错。web 开发其实是在进行数据处理,这估计也是现在在倡导异步处理、反应式处理的初衷,而进行逻辑处理的框架,对代码设计是非常讲究的。习惯了Controller-service-dao这种思维,在关键领域不会用类解决问题,所有的代码都是把字段取出来计算,然后再塞回去。各种不同层面的业务计算混在一起,将来有一点调整,所有的代码都得跟着变,其实就是面向过程的代码。

面向对象几个基本概念:抽象、封装、继承、多态等,现在看,最难的就是抽象,抽象是在说啥?在厘定边界,什么活该什么类干是精确的,变动被局限在一个很小的范围内(比如,我把map 改成guava cache,变动越小越优秀)。理论上,不违背基本设计的变动,修改起来应该是很容易的。没有抽象,写出来的都是方法和方法的组合

一个类,有几个方法,有几个字段,叫啥名,哪些对外可见的,很重要,绝不是随意的,反应了你的设计理念。尤其是在重逻辑,轻数据处理的项目中。Controller-service-dao 给了很不好的恶习。

在一些从结构化编程起步的程序员的视角里,面向对象就是数据加函数。虽然这种理解不算完全错误,但理解的程度远远不够。面向对象是解决更大规模应用开发的一种尝试,它提升了程序员管理程序的尺度。谈到面向对象,你可能会想到面向对象的三个特点:封装、继承和多态。封装,则是面向对象的根基。对象之间就是靠方法调用来通信的。但这个方法调用并不是简单地把对象内部的数据通过方法暴露。因为,封装的重点在于对象提供了哪些行为,而不是有哪些数据。也就是说,即便我们把对象理解成数据加函数,数据和函数也不是对等的地位。函数是接口,而数据是内部的实现,正如我们一直说的那样,接口是稳定的,实现是易变的。“封装”的要点是行为,数据只是实现细节,而很多人习惯性的写法是面向数据的,这也是导致很多人在设计上缺乏扩展性思考的一个重要原因。

一个模型的封装应该是以行为为基础的。PS: 一个类不应该只当数据类用,除非目的就是数据类。

理解了这一点,我们来看一个很多人都有的日常编程习惯。他们编写一个类的方法时,把这个类有哪些字段写出来,然后,生成一大堆 getter 和 setter,将这些字段的访问暴露出去。这种做法的错误就在于把数据当成了设计的核心,这一堆的 getter 和 setter,是对于封装的破坏,它把一个类内部的实现细节暴露了出来。请注意,方法的命名,体现的是你的意图,而不是具体怎么做。所以,getXXX 和 setXXX 绝对不是一个好的命名。不过,在真实的项目中,有时确实需要暴露一些数据,所以,等到你确实需要暴露的时候,再去写 getter 也不迟,你一定要问问自己为什么要加 getter。至于 setter,首先,大概率是你用错了名字,应该用一个表示意图的名字;其次,setter 通常意味着修改,一个好的设计应该尽可能追求不变性。所以,setter 也是一个提示符,告诉我们,这个地方的设计可能有问题。

setter 的出现,是对于封装的破坏,它把一个类内部的实现细节暴露了出来。面向对象的封装,关键点是行为,而使用 setter 多半只是做了数据的聚合,缺少了行为的设计。setter 通常还意味着变化,一个好的设计应该尽可能追求不变性。所以,setter 也是一个提示符,告诉我们,这个地方的设计可能有问题。

小结

本文着重从面向对象渊源的角度来说明:面向过程编程在构造系统时,无法解决重用,维护,扩展的问题,进而说明面向对象将 重用、维护、扩展加入了设计理念中,进而体现在语言的方方面面。