如果你想成为架构师,那请你仔细思考之间的关系
业务描述 | 生成的代码 |
---|---|
“不管,写代码就好了” 不着边际的写。 |
patient.setShotTypes(ShotTyps.TYPE_FLU) patient.setDoes(dose); patient.setNurse(nurse); |
“我们给病人注射流感疫苗” 好多了,但是丢失了重要的概念。 |
patient.giveFluShot(); |
“护士给病人注射标准剂量的流感疫苗” 这才是我们想要的。 |
Vaccine vaccines = vaccine.standardAdultFluDose(); nurse.administerFluVaccine(patlent,vaccine); |
看到以上的吗,如果你不看中文部分,你有什么感想呢?
如果你是一个项目经理:你会说第一段易读性好、比较直接、关键是实现了功能,出错也好调试。
第二段:属于技术型的程序员。
能做到第三段的人:一定想成为架构师。
当我们的项目中大量充斥第一段代码的时候,我们实际上只是在做项目,不想做产品,认为架构是多余的,画蛇添足的。3行能解决问题,如果用第三个,得多建几个类。更多的是结构化代码,体现不出来【用对象来做事情的思想】。当然:如果代码优化,从第一段走到第三段是提升。从第三段走到第一段就是倒退(实际中有过:项目经理着急了,对架构师说写的什么代码,架构师拒绝修改,PM找了个初级程序员给改回第一段了)。当然都不会有错。客户也不懂代码。这是架构师的滑铁卢。
啊,不知道理解的对不对?:
第一个代码是:病人是对象,注射类型、是否注射、病人都是其属性。显然这些东西作为病人的属性是不“面向对象的”。就比如我们不能说猫是狗的对象,只能说狗有个属性是玩,把对象猫给它,它就能玩了。
第二个代码是:病人是对象,他有个方法是注射疫苗,直接调方法就能实现功能。但是细节未知。
第三个代码是:病人、护士、疫苗都是不同对象,先选出疫苗类型,护士可以做的事是打标准疫苗,只要将疫苗和病人给护士,护士就能完成这个事情。