每个架构师都应该研究下康威定律

本文出处:http://36kr.com/p/5042735.html

今天的分享主要来自我之前的工作经验以及平时的学习总结和思考。我之前的背景主要是做框架、系统和平台架构,之前的工作过的公司eBay、携程、唯品会都是平台型互联网公司,所以今天主要带着平台架构视角和大家分享心得体会。架构的视角每个人都不一样,可以说一万种眼光,有业务架构、安全架构、平台架构、数据架构,各不相同,这里仅是我的一家之言,欢迎大家加入『聊聊架构』社群参与讨论。今天聊的话题主要包括以下几点:

  • 我对架构定义的理解
  • 架构的迭代和演化性
  • 构建闭环反馈架构(Architecting for closed loop feedback)
  • 谈谈微服务架构和最新主题
  • 架构和组织文化关系
  • 架构师心态和软技能
  • 我对一些架构师争议主题的看法
我对架构定义的理解

大概在7~8年前,我曾经有一个美国对口的架构师mentor,他对我讲架构其实是发现利益相关者(stakeholder),然后解决他们的关注点(concerns),后来我读到一本书《软件系统架构:使用视点和视角与利益相关者合作》,里面提到的理念也是这样说:系统架构的目标是解决利益相关者的关注点。

每个架构师都应该研究下康威定律

这是从那本书里头的一张截图,我之前公司分享架构定义常常用这张图,架构是这样定义的:

  • 每个系统都有一个架构
  • 架构由架构元素以及相互之间的关系构成
  • 系统是为了满足利益相关者(stakeholder)的需求要构建的
  • 利益相关者都有自己的关注点(concerns)
  • 架构由架构文档描述
  • 架构文档描述了一系列的架构视角
  • 每个视角都解决并且对应到利益相关者的关注点。

架构系统前,架构师的首要任务是尽最大可能找出所有利益相关者,业务方,产品经理,客户/用户,开发经理,工程师,项目经理,测试人员,运维人员,产品运营人员等等都有可能是利益相关者,架构师要充分和利益相关者沟通,深入理解他们的关注点和痛点,并出架构解决这些关注点。架构师常犯错误是漏掉重要的利益相关者,沟通不充分,都会造成架构有欠缺,不能满足利益相关者的需求。利益相关者的关注点是有可能冲突的,比如管理层(可管理性)vs技术方(性能),业务方(多快好省)vs 技术方(可靠稳定),这需要架构师去灵活平衡,如何平衡体现了架构师的水平和价值。

关于架构的第二点定义是说架构主要关注非功能性需求(non-functional requirements),即所谓的-abilities。

每个架构师都应该研究下康威定律

这个是我上次公司内分享的一个图。

每个架构师都应该研究下康威定律

这个是slideshare一个ppt里头截取的,两个图都是列出了架构的非功能性关注点;关于架构的水平该如何衡量,去年我看到一句话,对我影响很大。

Architecture represents the significant design decisions that shape a system, wheresignificant is measured by cost of change.

翻译为中文就是,架构表示对一个系统的成型起关键作用的设计决策,架构定系统基本就成型了,这里的关键性可以由变化的成本来决定。这句话是Grady Booch说的,他是UML的创始人之一。

进一步展开讲,架构的目标是用于管理复杂性、易变性和不确定性,以确保在长期的系统演化过程中,一部分架构的变化不会对架构的其它部分产生不必要的负面影响。这样做可以确保业务和研发效率的敏捷,让应用的易变部分能够频繁地变化,对应用的其它部分的影响尽可能地小。

我刚入软件开发这个行业之出,谈的架构主要是性能,高可用等等。现在,见过无数遗留系统,特别是国内企业IT的现状,无数耦合性系统的遗留系统,不良的架构象手铐一样牢牢地限制住业务,升级替换成本非常巨大, 所以我更加关注可理解,可维护性,可扩展性,成本 。我想补充一句,创业公司创业之初获得好的架构师或技术CTO非常重要。

架构的迭代和演化性

我是属于老一代的架构师,99年参加工作。职业初学了很多RUP,统一软件过程的理念。RUP的理念对我的架构有很深的影响,RUP总结起来就是三个特点:

  • 用例和风险驱动Use Case and risk driven
  • 架构中心Architecture centric
  • 迭代和增量Iterative and incremental

RUP很注重架构,提倡以架构和风险驱动,该开始一定要做端到端的原型prototype;通过压测验证架构可行性,然后在原型基础上持续迭代和增量式开发,开发->测试->调整架构->开发,循环,如下图所示:

每个架构师都应该研究下康威定律

从上图可以看出架构师要尽可能写代码,做测试,纸上谈兵式做架构而后丢给团队的作法非常不靠谱(除非是已经非常清晰成熟的领域)。另外,做技术架构的都有点完美主义倾向,一开始往往喜欢求大求全,忽视架构的演化和迭代性,这种倾向易造产品和用户之间不能形成有效快速反馈,产品不满足最终用户需求,继续看下面两个图:


每个架构师都应该研究下康威定律

每个架构师都应该研究下康威定律

第一个图是讲最小可用产品(Minimum Viable Product, MVP)理念,做出最小可用产品,尽快丢给用户试用,快速获取客户反馈,在此基础上不断迭代和演化架构和产品。第二个图是过度工程(Over Engineering)的问题,其实也是讲产品架构和用户之间没有形成有效的反馈闭环,架构师想的和客户想的不在一个方向上,通过最小可用产品,快速迭代反馈的策略,可以避免这种问题。注意,在系统真正地投入生产使用之前,再好的架构都只是假设,产品越晚被使用者使用,失败的成本和风险就越高,而小步行进,通过MVP快速实验,获取客户反馈,迭代演化产品,能有效地减少失败的成本和风险。

另外,多年的经验告诉我,架构,平台不是买来的,也不是用一个开源就能获得的,也不是设计出来,而是长期演化才能落地生根的给大家推荐两篇不错的微信文章(微信不能插入链接,根据题目Google下即可):

  • 58同城沈剑:好的架构源于不停地衍变,而非设计
  • 宜人贷系统架构–高并发下的进化之路

两篇文章其实都是讲架构的迭代和演化性,值得每个架构师学习吸收。

构建闭环反馈架构

先分享一个链接,这几年对我架构影响最深的一篇文章。这篇文章是关于DevOps的,但对系统架构同样适用:http://itrevolution.com/the-three-ways-principles-underpinning-devops/ 

每个架构师都应该研究下康威定律

第一条道路,系统思维,开发驱动的组织机体,其能力不是制作软件,而是持续的交付客户价值,架构师需要有全局视角和系统思维(System Thinking),深入理解整个价值交付链,从业务需求、研发、测试、集成,到部署运维,这条价值链的效率并不依赖于单个或者几个环节,局部优化的结果往往是全局受损,架构师要站在系统高度去优化整个价值交付链,让企业和客户之间形成快速和高效的价值传递。

每个架构师都应该研究下康威定律

聊聊架构第二条道路,强化反馈环,任何过程改进的目标都是加强和缩短反馈环。刚入行的工程师,也是中国学生的普遍问题,就是生产运维意识不足(监控是系统反馈的重要环节)。有两种化这样讲的:

  • no measurement, no improvement没有测量,就没有改进和提升
  • What your measure is what you get你测量什么,就得到什么

没有监控或者监控不完善的系统相当于裸奔,开车上高速无仪表盘。有一篇很多错的关于测量驱动开发的文章,在InfoQ上的,向大家推荐:

http://www.infoq.com/cn/articles/metrics-driven-development

这篇文章提出了度量驱动开发的理念,即所谓MDD,在系统,应用和业务,通过三级监控,构建三个反馈环,在监控测量基础上持续改进系统和架构,我最近也在参考这个理念设计一个电商平台的技术架构,见下图:

每个架构师都应该研究下康威定律

这是一个电商平台的架构,整个体现了闭环架构的思想,右侧是整个平台的反馈监控环节。具体如下:

  • 系统层监控计算网络存储,构建系统层的反馈环
  • 应用服务层,监控业务、应用、服务,甚至整个研发流程,构建应用和服务层的反馈环
  • 客户体验层,监控端用户和分析网站用户的行为,构建和客户的反馈环

下面这个图展示了系统提升和改进的一般方法:

每个架构师都应该研究下康威定律

收集->测量->调整->闭环重复,在有测量数据和反馈的基础上,系统、应用、流程和客户体验才有可能获得持续的提升和改善,否则没有数据的所谓改进只能靠拍脑袋或者说猜测。

每个架构师都应该研究下康威定律

第三条道路,鼓励勇于承担责任,冒险试错和持续提升的文化。这点是最难的,一般和企业人才密度有关。工具,技术,流程只是一个公司的冰山浮出水面的部分,而真正对企业效能影响大的则是冰山水下的部分,即企业的人和文化,架构师作为技术和架构的布道者,有责任义务鼓励和推动试错文化。

架构师要深入领会这三条道路,关注整个价值交付链的效率,关注每个环节的闭环反馈,鼓励和推动公司的试错文化,打造全系统的闭环架构(Architecting for closed loop feedback),提升整个系统效能。下图的DevOps和每日交付是每一个互联网系统架构师的梦想和努力的方向。

每个架构师都应该研究下康威定律

谈谈微服务架构微服务

我想大家都听得很多了,我本人也非常关注和推崇微服务,从技术角度讲,我认为微服务主要体现的是单一职责和关注分离的思想,从单进程模块化进一步拓展到跨进程分布式的模块化。微服务是独立的开发、测试、部署和升级单元,正如我在第一点架构定义中提到的,微服务中每个服务可以独立演变,它的cost of change比较小,整体架构比较灵活,是一种支持创新的演化式架构。去年MartinFowler写了两篇文章,给微服务泼冷水的,建议大家好好读下。

  • http://martinfowler.com/bliki/MicroservicePrerequisites.html
  • http://martinfowler.com/bliki/MicroservicePremium.html

每个架构师都应该研究下康威定律

这个图讲什么时候该引入微服务。微服务有额外成本的,需要搭建框架、发布、监控等基础设施。初创和小规模团队不建议采用。主要决定因素系统复杂性和团队规模,当到达一个点,单块架构严重影响效率才考虑 。另外补充一点,微服务更多是关于组织和团队,而不是技术。

架构和组织文化关系

再谈一下康威定律:

Conway’s law: Organizations which design systems[...] are constrained to produce designs which are copies of the communication structures of these organizations.

(设计系统的组织,其产生的设计和架构等价于组织间的沟通结构。 )

从单块架构到微服务架构是这个定律的很到体现。

每个架构师都应该研究下康威定律

团队是分布式的,系统架构是单块的,开发,测试,部署协调沟通成本大,严重影响效率,严重时团队之间还容易起冲突conflict。

每个架构师都应该研究下康威定律

将单块架构解耦成微服务,每个团队开发,测试和发布自己负责的微服务,互不干扰,系统效率得到提升。

可见,组织和系统架构之间有一个映射关系(1 ~ 1 mapping),两者不对齐就会出各种各样的问题,一方面,如果你的组织结构和文化结构不支持,你也无法成功建立高效的系统架构,例如集中式和严格职能(业务, Dev, QA, Deployment, Ops)的企业,很难推行微服服务和DevOps,推行Docker/PaaS平台也会比较困难,这样的组织职能之间都倾向于局部优化(local optimization),无法形成有效和合作和闭环。

反过来也是成立的,如果你的系统设计或者架构不支持,那么你就无法成功建立一个有效的组织;作为系统架构师,一定要深入领会康威定律,设计系统架构之前,先看清组织结构,也要看组织文化(民主合作式,集权式,丛林法则式,人才密度),再根据情况调整系统架构或者组织架构。

架构师心态和软技能

空杯,或者说开放心态(open minded)是一个成熟架构师的应有心态,stay hungry, stay foolish, 心态有多开放,视野就有多开阔。来自《高效能人士的七个习惯~史蒂芬~柯维》的一句话送给每一个架构师 :

如果一位具有相当聪明才智的人跟我意见不同,那么对方的主张必有我尚未体会的奥秘,值得加以了解。与人合作最重要的是,重视不同个体的不同心理、情绪与智能,以及个人眼中所见的不同世界。与所见略同的人沟通,益处不大,要有分歧才有收获。

另外再推荐一个本书《软件架构师的12项修炼》,这书中三个观点很值得每个架构师学习领会:

  • soft skills are always hard than hard skills,软技能比硬技能难
  • choosing relationship over correctness ,注重关系重于谁对谁错
  • 架构的政治性,在中大型公司里混的架构师尤其要学习

政治指的是和他人协作将事情搞定的艺术,架构是一种社交活动,在技术的世界里,个人主义很容易被打败,即使你的目的是好的技术是最优的,技术决策是政治决策(technical decisions are political decisions),一个技术产品,一波人可以做,另一波人也可以做,到底谁做的好,真不好说,不管谁做,都给业务套上了一副手铐。

架构师如何提升?实战,实战,实战!规划职业,找好的团队和项目,总结分享,学习GitHub开源项目,尽可能参与和开创自己的开源项目和产品,并长期积累。

我对一些架构师争议主题的看法

主要争议是两个话题:

  • 技术和业务的关系。
  • 架构师要写代码吗?

架构师怎么回答这类问题?一个成熟架构师的口头禅:视情况而定,不一定,是也不是,it depends。技术和业务,架构师要理解业务吗,看产品和客户,如果是业务性产品,肯定要理解业务,如果是技术型产品,就不一定。

架构师要写代码?也不一定,个人觉得尽可能要写,如果你写过十年以上代码了,每年不少于2万行,都玩通了,可以不写。另外架构师如果写代码,要把控度,不要一头钻入代码,花大量时间解决细节和复杂性问题,忽视全局和系统性问题。

最后

我想说中国现在的互联网发展趋势很好,越来越多的人加入架构师这个行业,这个行业正在“万物生长”。 但是我们现在还没有马丁福勒,adrian cockcroft这样的架构牛人物,我辈需不断努力,期待中国10~20年后出现超过十个马丁福勒,adrian cockcroft这样的大牛神级人物。我们必不可停止探索,而一切探索的尽头,就是重回起点,并对起点有首次般的认识。

展开阅读全文

每个程序员都应该知道的福利

04-22

眼下正是年后跳槽的黄金时期,园里的大牛小牛拿了去年的年终奖后,有些肯定想给自己加点工资。园里的大牛小牛都是我们中国软件业的精英,跳槽的时候 肯定手里握着好几个Offer, 不知道选择哪家。先不管工作的内容和前途,就工作本身的待遇,我们还是可以比较的。 HR是专门负责谈薪资的, 当我们跟HR讨价还价的时候, HR会介绍公司有的福利,而回避公司没有的福利。 作为程序员,我们一定要对跟我们利益息息相关的各种福利细节了如指掌, 各项福利都要跟HR询问清楚,才能比较公司之间的总体福利。 同时还需要掌握些技巧,别让我们的利益会受到损害。rnrn工资每个月多少rnrn工资是需要谈的,我见过很多优秀的人工资很低,就是因为他们不懂谈工资。公司之所以要求薪资保密,就是说明同等职位的工资存在较大的差异rnrn入职时候的工资可能在很长的一段时间内都不会变, 不要指望你入职后,再涨工资。rnrn例如:公司招了两个程序员,程序员A 5000,程序B 8000,用了一年。感觉两个人水平差不多,工资还是那样维持着。如果非要公司做解释,公司会说当初就是那么谈的。rnrn年底奖金有多少rnrn我们在计算自己的年薪都是用 (月工资*一年发多少个月)来算的, 年底的奖金非常重要, 这个一定要跟HR问清楚。 有奖金和没奖金的收入区别非常大, 没奖金的话,你过年怎么过?rnrn一般的公司都会在1月份的时候,农历新年之前发一个月的奖金。 好的公司会发两个月甚至更多, 一些变态的公司竟然发十几个月工资的奖金。rnrn那些年底没奖金的公司,最好别去。rnrn情景对话:rnrn程序员A说: “请问贵公司,年底发几个月的年终奖呢?”rnrnHR说: “奖金是跟绩效挂钩的, 有的人只能拿1个月,有的人能拿五六个月的”。rnrn程序员A说: "那请问我这个职位,表现一般的, 年底一般能拿多少个月呢?"rnrnHR说: “大概一个月吧”rnrn程序员A说: “这样啊, 明白了”rnrn程序员A心里想: “年终奖才一个月,我还以为有几个月,差点被她忽悠了”。rnrn股票期权rnrn上市公司可能会给员工股票,这是个好东西啊,很多人因为这个发财。rnrn试用期几个月,以及试用期工资多少rnrn很多大公司对试用期几个月,以及试用期工资是多少,有着明文规定, 不能谈的。rnrn有些小公司是可以谈的。rnrn试用期最好不超过3个月,试用期的工资应该和转正后的工资一样, 而且试用期内其他福利也应该和转正后一样。rnrn试用期如果是6个月会有比较大风险rnrn1. 试用期被裁。 公司被收购,或者你所在的项目缩减,都很有可能造成试用期被裁。按照法律规定,公司只需要提前3天通知你, 就可以了。不需要给你支付任何赔偿金。 这时候你会直接失业, 一下子陷入困境。rnrn2. 拿不到年终奖。 假如你是7月15日入职,那么1月15日你才转正。 公司在1月5日的时候发年终奖,而你还在试用期,就没有权利获得年终奖。rnrn住房公积金基数是多少,是否有补充住房公积金rnrn首先大家要知道。 住房公积金基数,社保基数,还有你纳税的基数。这三个基数是有可能不一样的。rnrn比如你的工资是8000,你的公积金可能按3000的基数交, 而你的社保可能按5000来交。rnrn在正规的公司,公积金基数和社保基数都是以你的工资基数来交的。rnrn住房公积金在我们买房子的时候用来贷款和还贷款的,所以对大部分人都是有用的。rnrn所以住房公积金是越高越好, 如果有补充公积金就更好了rnrn社保基数多少rnrn社保是指养老保险,医疗保险,失业保险,生育保险,工伤保险。 对于外地人来说,这些纯粹是剥削人的。你听说过有人拿过失业保险的赔偿么?交了这么多年的养老保险,以后打回原籍,一点都拿不到退休金。rnrn社保基数越低越好rnrn纳税基数是多少,是否有避税措施rnrn辛辛苦苦的赚来工资,很大一部分被别人拿走了。rnrn纳税很难避免的,还没发工资就被扣了。 不过听说过有些公司可以拿发票去顶税。rnrn入职日期rnrn入职日期最好是年后2月到4月. 好处在于rnrn1. 机会比较多,行情好rnrn2. 已经拿了去年的年终奖,rnrn3. 年过完了,年假也休得差不多了。rnrn4. 在心态上, 期望新的一年有个新的开始。rnrn5. 如果3月入职, 到了年底1月份,你共工作10个月,你能拿10/12的奖金rnrn公司加薪的制度rnrn大部分人都是靠跳槽来加薪, 如果公司的每年加薪幅度有10%以上, 就不用老跳槽了rnrn问清楚公司的加薪制度,公司每年有几次的加薪机会,平均加薪幅度有多大,在什么月份加薪.rnrn商业医疗保险rnrn如果公司给员工购买了商业医疗保险, 员工去看病,只要药品和治疗属于医保范围之类,100%报销,包括门诊和住院。 子女的医疗费用也能报销50%.。 女员工生孩子的费用也可以全报销。rnrn案例1:rnrn小王的公司给员工购买了商业医疗保险。 一天,小王感冒了,带着上海医保卡来到三甲医院看病。 医生开了400元的消炎药。 小王用医保卡付了400元。 小王把发票交给公司去报销。 最后公司将400元现金交给小王。 通过商业医疗保险,小王看病一分钱都没花,而且把医保卡中的钱,变成了手里的现金。rnrn案例2:rnrn老李的公司给员工购买了商业医疗保险。 有次小李的儿子生病住院,花了3000元。小李先用社会保险报销了1500元。 剩下的1500交给公司去商业医疗保险报销。 通过商业医疗报销。 老李儿子的医药费全都报销了,自己一分钱都不用拿出来。rnrn案例3:rnrn张小姐的公司给员工购买了商业医疗保险。 张小姐前段时间破腹产,花了8000多元。 还好有商业保险,全都报销了。 因为是独生子女, 商业医疗报销还奖励了1千元.rnrn通过这几个案例,我们可以看出商业医疗保险是个很好的福利。rnrn年假多少天rnrn按国家法律规定,满一年后有5天年假。 所以很多一般的公司都是按这个来的, 实在是年假太少了(满一年才有5天年假)。rnrn年假太少非常不爽,过年回老家都没假,平常要是有什么事。没年假了说不定还要请事假(扣工资的)rnrn有些外企,第一年10天年假, 工作满3年有15天年假。 而且是入职就有年假, 不用满一年。rnrn带薪病假多少天rnrn带薪病假就是:指跟公司请病假(不需要开病假单),不扣工资的。 这个福利很爽的哦rnrn一般外企会有这个福利。 这带薪病假跟年假差不多, 只不过带薪病假一般不能连续请几天。rnrn案例1:rnrn小志计划周三带女朋友去杭州玩,行程早就安排好了。 到了周三早上,小志给他领导打电话,说他女朋友身体不舒服,需要请一天病假。 领导说: "好的,你好好照顾你女朋友吧". 然后小志高高兴兴陪女朋友在杭州玩,不用担心扣工资。rnrn每年旅游机会rnrn小福利, 出国旅游才是较大的福利,rnrn有无出国的机会rnrn能出国是很多人考虑的因素,有海外工作经验会对自己的职业生涯有很大的帮助。rnrn稳定性rnrn现在虽不是技术牛人,就是正在成为技术牛人的人,不担心找不到工作。就算碰到裁员,拿了赔偿金后,还能迅速找到更好的工作。rnrn一般女生比较注重稳定性。rnrn过节的福利rnrn小福利,不用考虑,比如端午节发个粽子, 中秋节发个月饼票rnrn培训机会rnrn有没有英语培训,或者技术培训。rnrn健身补助,饭补,交通补助rnrn可遇不可求。rnrn企业文化和工作氛围rnrn最怕碰到那种有办公室政治的公司了,同事之间勾心斗角,拉帮结派,排挤新人,搞得乌烟瘴气。rnrn大家开开心心在一起工作多好,何必搞这么多名堂呢?rnrn喜欢领导和同事都很Nice的公司。rnrn上班的路程rnrn当然是公司离住所越近越好,谁都不想早上挤地铁挤公交。1个多小时下来,赶到公司歇口气才能缓过来rnrn定期的体育活动rnrn健康的重要性不言而喻,大部分程序员的身体都处于亚健康的姿态,坐在电脑面前一坐就是一天。除了休息和健康的饮食外,运动是我们保持健康的唯一的方法。rnrn去健身房办卡很难坚持,很多人办了卡只去过一两次,如果公司有定期的体育活动,比如篮球,羽毛球。我们就很容易坚持。rnrn最后算算到手能拿多少rnrn每个月拿到手的,才是你真正的工资。不要把税前的工资当成是你的工资。 论坛

每个初学者都应该搞懂的问题(4)

03-23

对于这个系列里的问题,每个学Java的人都应该搞懂。当然,如果只是学Java玩玩就无所谓了。如果你认为自己已经超越初学者了,却不很懂这些问题,请将你自己重归初学者行列。rnrnrnfinal关键字到底修饰了什么?rn要理解此问题,请首先理解本系列第二个问题所阐述的概念。http://expert.csdn.net/Expert/topic/2868/2868492.xml?temp=.3966181rnrnfinal使得被修饰的变量"不变",但是由于对象型变量的本质是“引用”,使得“不变”也有了两种含义:引用本身的不变,和引用指向的对象不变。rnrn引用本身的不变:rnfinal StringBuffer a=new StringBuffer("immutable");rnfinal StringBuffer b=new StringBuffer("not immutable");rna=b;//编译期错误rnrn引用指向的对象不变:rnfinal StringBuffer a=new StringBuffer("immutable");rna.append(" broken!"); //编译通过rnrn可见,final只对引用的“值”(也即它所指向的那个对象的内存地址)有效,它迫使引用只能指向初始指向的那个对象,改变它的指向会导致编译期错误。至于它所指向的对象的变化,final是不负责的。这很类似==操作符:==操作符只负责引用的“值”相等,至于这个地址所指向的对象内容是否相等,==操作符是不管的。rnrn理解final问题有很重要的含义。许多程序漏洞都基于此----final只能保证引用永远指向固定对象,不能保证那个对象的状态不变。在多线程的操作中,一个对象会被多个线程共享或修改,一个线程对对象无意识的修改可能会导致另一个使用此对象的线程崩溃。一个错误的解决方法就是在此对象新建的时候把它声明为final,意图使得它“永远不变”。其实那是徒劳的。rnrnrn 论坛

每个初学者都应该搞懂的问题(2)

03-21

论坛上甚至有一些带星的同志都没弄清楚这个问题。此问题在论坛上也被提过很多次了。如果你弄不清楚,请把自己归为“初学者”一类。rnrnrn请参看本系列帖子的前一篇。http://expert.csdn.net/Expert/topic/2868/2868335.xml?temp=.493664rnrn"=="和equals方法究竟有什么区别?rnrn==操作符专门用来比较变量的值是否相等。比较好理解的一点是:rnint a=10;rnint b=10;rn则a==b将是true。rn但不好理解的地方是:rnString a=new String("foo");rnString b=new String("foo");rn则a==b将返回false。rnrn根据前一帖说过,对象变量其实是一个引用,它们的值是指向对象所在的内存地址,而不是对象本身。a和b都使用了new操作符,意味着将在内存中产生两个内容为"foo"的字符串,既然是“两个”,它们自然位于不同的内存地址。a和b的值其实是两个不同的内存地址的值,所以使用"=="操作符,结果会是false。诚然,a和b所指的对象,它们的内容都是"foo",应该是“相等”,但是==操作符并不涉及到对象内容的比较。rn对象内容的比较,正是equals方法做的事。rnrn看一下Object对象的equals方法是如何实现的:rnboolean equals(Object o)rnrnreturn this==o;rnrnrnObject对象默认使用了==操作符。所以如果你自创的类没有覆盖equals方法,那你的类使用equals和使用==会得到同样的结果。同样也可以看出,Object的equals方法没有达到equals方法应该达到的目标:比较两个对象内容是否相等。因为答案应该由类的创建者决定,所以Object把这个任务留给了类的创建者。rnrn看一下一个极端的类:rnClass Monsterrnprivate String content;rn...rnboolean equals(Object another) return true;rnrnrn我覆盖了equals方法。这个实现会导致无论Monster实例内容如何,它们之间的比较永远返回true。rnrn所以当你是用equals方法判断对象的内容是否相等,请不要想当然。因为可能你认为相等,而这个类的作者不这样认为,而类的equals方法的实现是由他掌握的。如果你需要使用equals方法,或者使用任何基于散列码的集合(HashSet,HashMap,HashTable),请察看一下java doc以确认这个类的equals逻辑是如何实现的。rn 论坛

没有更多推荐了,返回首页