抽象没做好,何谈有类

简介: 抽象没做好,何谈有类

之前写过一篇文章是“面向对象的基础是抽象”(39条消息) 面向对象的基础是抽象_赛男丨木子丿小喵的博客-CSDN博客

当再提到这个问题得时候有了新的认知,尤其是这样得一句话“不用关心他是怎么做的,只要做成就可以了。抽象就是不关注内部具体是什么”。结合老师提到得一个问题,如何理解下面两句话:

”①我们要注重多少人来干事,而不是干什么事。

②我们要注重谁来干事,而不是怎么干事。

这与面向对象的抽象有什么关系?“

一、问题是最后一句话,”这与面向对象的抽象有什么关系?“,现在只说”抽象“,还没有谈到”类“的概念,所以还没有到封装,继承和多态,这说明什么问题,没有类,就无需关注类中的方法,方法中可能会说让别人做什么事情。我的脑袋中一直不能理解为什么不能说让别人做什么,比如打水这个例子,我也没有关心具体水是怎么打的,为什么不是面向对象的抽象,问题就在抽象这里,现在说的就是”抽象“,抽象还没做好,就没有类的事,没有类的事就没有类之间的关系。当然更不用关心一件事具体怎么去实现,回到抽象的解释--抽象就是不关注内部具体是什么。


二、关注句子的主语而非整个句子,再进一步说,关注除了句子的谓语之外的其他成分都可以,主语,宾语,总之名词性的部分,什么意思,你要抽象谁,这个谁是个名字,还拿打水这件事来说,抽象过程中注重对象,而不是过程,场地,打水人,打水工具,受水人,水等等,如果再进一步抽象,参与者,使用的工具,场所(UI),材料(参数)等等,唯独不该关心”让谁打水“。往上抽象,类越来越少,不光为了实现复用,也为了实现代码自动化,可扩充可维护。


三、关于粒度,越大,代码的“颗粒”越模糊,越接近一个逻辑上的概念;粒度越小,代码的“颗粒”越清晰,越接近具体的实现。通常情况下粗粒度的复用性要差,细粒度的、更具体反而更容易复用。也可以理解成抽象的类粒度越小,复用性越高,也就是上面的例子中提到的,抽象出场地,打水人,打水工具,受水人,水等等。


总结,面向对象的基础是抽象,因为没有抽象就没有类,没有类就没有封装继承和多态。


目录
打赏
0
0
0
0
1
分享
相关文章
交易链路设计原则&模式问题之在软件开发中实现开闭原则如何解决
交易链路设计原则&模式问题之在软件开发中实现开闭原则如何解决
你的职责链模式符合五大原则吗?-系统学习九
工作之余对于用到的设计模式进行总结再梳理,发现职责链模式的妙处以及五大原则的指导下更能发挥职责链模式的优势于是乎便有了这篇博文的诞生
系统的混乱并业务本身之复杂,我们并不擅长处理『简单』
![](https://ata2-img.oss-cn-zhangjiakou.aliyuncs.com/neweditor/846d5052-1e21-4f9c-8f52-aaa37cacc407.png) # 前言 一群高智商青年在餐厅吃饭,餐桌上一个瓶盖标识为盐的瓶子里装得是胡椒粉,而标识为胡椒粉的瓶子里装得却是盐,他们想出了一个充满才气的方案来完成对调--仅需要一张餐巾纸、一根吸管和两个
48705 10
系统的混乱并业务本身之复杂,我们并不擅长处理『简单』
系统的混乱并非业务本身之复杂,我们并不擅长处理『简单』
软件工程最大的成本在于维护,为了未来可扩展、为了未来更灵活,我们往往会增加很多很多奇奇怪怪可有可无的代码,增加这些代码可能只需要几分钟,但移除这些代码花费的精力与承担的风险,却数倍于此。我们不断 YY 着所谓的未来,却让现在越来越糟。系统的混乱并非业务本身之复杂,我们并不擅长处理『简单』。
1219 1
系统的混乱并非业务本身之复杂,我们并不擅长处理『简单』
【Java设计模式 规范与重构】 四 小型重构的手段:规范的十五条军规
【Java设计模式 规范与重构】 四 小型重构的手段:规范的十五条军规
149 0
产品相关 细说软件产品和业务 & 业务过程(流程) & 业务逻辑
产品相关 细说软件产品和业务 & 业务过程(流程) & 业务逻辑
181 0
六大原则之外的设计原则|设计原则
在前面的几篇设计原则文章中,我们分别讲述了经典的六大设计原则。但是事实上,我们在开发中还有几个重要的设计原则,在这篇文章中,一并给大家讲述。
AI助理

你好,我是AI助理

可以解答问题、推荐解决方案等