第一章读后感

本文介绍了面向对象程序设计(OOP)的基本概念,包括OOP的开发方法及其如何在解决方案中添加新的对象以增强其可扩展性。每个对象都有其状态和行为,并且可以通过发送消息与其他对象交互。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

这一章介绍的是面向对象程序设计(OOP)的基本概念,包括OOP 的开发方法的概述。

编程要解决的问题就是在机器模型(在“解空间”,即建模该问题的空间中,计算机中)和实际上要解决的问题模型(在“问题空间”,即问题存在的空间中)之间建立联系。OOP思想允许程序员在解决方案中添加的新的对象,使得解决方案具有可扩展性,不在因为解决一个问题而存在,可以随着需求的变化而变化。每一个对象就像一台小型计算机,具有状态,有可执行的运算(即特性和行为)。

对象的一些特性:

1、所有对象都是(虽然都具有唯一性)都是一类对象中的一员;

2、程序是一组对象,对象之间通过发送消息互相通知做什么;

3、每一个对象都有它自己的由其他对象构成的存储区;

4、一类对象都能接受一些相同的消息(虽然另一些消息可由某个对象单独实现 )

5、万物皆对象

对象的一些常识:

1、程序员创建类型的变量在面向对象中的称为对象(object)或者实例(instance);

2、父类----->>子类------>>对象;

对象和接口的举例:

类型名                                                                    Light
接口                                                on()            off()            bright()            dim() ........   
Light It;
It.on();
It.off();

<think>嗯,用户让我写一篇关于《重构:改善既有代码的设计》第三章“代码的坏味道”的读后感。首先,我需要回忆一下第三章的主要内容。这章主要讲的是识别代码中的不良设计模式,也就是所谓的“坏味道”。比如重复代码、过长函数、过大的类等等。用户可能希望这篇读后感能概括这些坏味道,并给出自己的理解和感受。 接下来,用户可能的需求是什么?他们可能正在学习重构,或者在工作中遇到了代码质量问题,想通过读后感来加深理解。也有可能是在准备演讲或分享,需要参考别人的观点。所以,读后感不仅要总结内容,还要有个人见解,最好能结合实际例子,让读者更容易理解。 用户提到的系统级指令里要求使用中文,数学公式用$...$,但读后感里可能不需要数学公式。不过需要确保结构清晰,分点论述。用户希望结构清晰,逐步解决问题,所以可能需要分几个部分,比如摘要、具体坏味道分析、个人体会、实践建议等。 需要注意的是,用户可能希望这篇读后感不仅仅是书的内容复述,而是加入自己的思考和案例。比如,可以结合自己编程中遇到的坏味道例子,说明这些问题的危害以及重构后的改善。这会让读后感更有深度,也更符合用户要求的“真实可靠”。 另外,用户可能对如何应用这些识别坏味道的方法感兴趣,所以实践部分很重要。比如,如何培养嗅觉,如何逐步重构,团队协作中的注意事项等。这部分内容能帮助读者将理论应用到实际工作中。 还要注意避免过于技术化,保持语言通俗易懂,因为读者可能不全是经验丰富的开发者。但也要准确,比如正确引用书中的术语,比如“神秘命名”、“重复代码”等,确保专业性。 最后,检查结构是否符合要求,是否有分点,是否使用正确的格式,比如独立公式虽然这里可能用不到,但其他要求如中文回答、结构清晰等都要满足。可能需要先概述章节内容,再分析几个重点坏味道,接着谈个人体会,最后总结如何应用这些知识。</think>《重构:改善既有代码的设计(第二版)》第三章读后感 ——识别代码的"坏味道"的实践指南 ### 一、章节核心思想 第三章以"代码的坏味道"为核心,系统性地归纳了代码质量下降的22种典型信号。这些"坏味道"如同人体疾病的早期症状,开发者需培养敏锐的嗅觉,在代码腐化初期及时干预。 ### 二、典型坏味道的深层解读 1. **重复代码(Duplicated Code)** - 书中将其列为头号坏味道,例如: ```java // 重复的校验逻辑 if (user.age < 18 || user.credits < 100) {...} if (order.user.age < 18 || order.user.credits < 100) {...} ``` - 我的实践反思:在微服务架构中,重复代码常以跨服务的相似逻辑出现,此时应考虑抽取公共库而非简单复制。 2. **过长函数(Long Method)** - 函数长度与可读性成反比,书中提出"每当需要注释说明时,就该抽取函数"的判断标准。我曾重构过一个300行的订单处理函数,拆解后核心逻辑仅剩20行,维护效率提升显著。 3. **数据泥团(Data Clumps)** - 书中强调"总是一起出现的数据项应该拥有自己的对象"。例如地理坐标中的经度、纬度、海拔,应该封装为`GeoPoint`类,而非散落在各个方法参数中。 ### 三、技术债务的量化认知 书中将坏味道分为两类: - **结构性问题**:如发散式变化(Divergent Change) $$ \text{修改点数量} \propto \frac{1}{\text{模块化程度}} $$ - **行为性问题**:如依恋情结(Feature Envy) 某个方法过度访问其他对象的数据,说明职责分配失衡。 ### 四、重构时机的把握策略 作者提出**"三次法则"**: 1. 第一次实现功能时允许快速实现 2. 第二次出现相似代码时保持警觉 3. 第三次重复时必须重构 这种渐进式策略平衡了开发速度与代码质量,避免了过度设计。 ### 五、实践中的认知升级 - **坏味道的相对性**:例如"过大的类"在DDD领域模型中可能是合理的聚合根 - **检测工具化**:结合SonarQube等静态分析工具,将书中理论转化为可量化的技术债务指标 - **团队共识建设**:建立团队的坏味道检查清单,在代码评审中统一标准 ### 六、延伸思考 书中未明确提及但值得关注的现代坏味道: 1. 过度使用设计模式导致的"模式膨胀" 2. 微服务间的"隐式耦合" 3. 异步代码中的"回调地狱" ### 结语 本章的价值不仅在于罗列问题,更在于培养开发者对代码质量的持续关注。如同好的厨师能辨别食材的新鲜度,优秀的工程师必须建立对代码气味的条件反射。在实践中,我们要像园丁修剪枝叶般持续重构,让代码库在演化中保持生命力。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值