学习 Java 8年了，我一直坚定不移地“抄”代码：“抄”同事“抄”框架“抄”网友有黑子会问，你天天自吹技术专家了，天天就知道抄？对此，我只想说，是的，咋滴？初级程序员和高级程序员最大的区别在哪里？：1 为啥就知道抄？“抄”，听起来让人不舒服？技术人嘛，咋能叫抄呢，应该叫：造轮子。不过似乎也被诟病，大佬们肯定劝你：年轻人不要重复造轮子，你的一切发明不过是发现！首先，造轮子是你面前已经有一个轮子了。
1 简介1.1 定义不要存在多于一个导致类变更的原因。1.2 特点一个类/接口/方法只负责一项职责。1.3 优点降低类的复杂度、提高类的可读性，提高系统的可维护性、降低变更引起的风险。类的复杂性降低，实现什么职责都有清晰明确定义可读性提高，复杂性降低，那当然可读性提高可维护性提高，可读性提高，更易维护变更引起的风险降低，变更必不可少。若接口的单一职责做好，一个接口修改只对相应的实现类有影响，对其他
1 代码重构定义对软件代码做任何改动以增加可读性或者简化结构而不影响输出结果。目的增加可读性、增加可维护性、可扩展性3 关键点不影响输出不修正错误不增加新的功能性代码重构时，发现有个功能实现逻辑不合理，可直接修改吗？当然不可！2 架构重构定义通过整系统结构(4R)来修复系统质量问题而不影响整体系统能力。目的修复质量问题（性能、可用性、可扩展......）关键点修复质量（架构，而非代码层面的质量）问
1 定义来个需求就改一次代码，似乎都习惯了，甚至觉得理所当然。反正修改也容易，只要按之前的代码再CV一份，不费脑子。但每人每次改一点点，日积月累，再来个新需求，后人改动量就很大了。每个人都很无辜，都只是简单修改一点点。但最终导致伤害后来接盘侠，代码已无法维护，直接推翻老系统，写新系统了。既然“修改”会带来这么多问题，那可以不修改吗？开放封闭原则就是一种值得努力的方向。Software enti
1 简介Flyweight Design Pattern，结构型模式。享元模式中的“享元”指被共享的单元。享元模式通过复用对象，以达到节省内存的目的。用于减少创建对象的数量，以减少内存占用和提高性能。尝试复用现有的同类对象，如果未找到匹配的对象，则创建新对象。意图：运用共享技术有效地支持大量细粒度的对象。主要解决：在有大量对象时，有可能会造成内存溢出，我们把其中共同的部分抽象出来，如果有相同的业务
1 简介一般有两种方式给一个类或对象新增行为：继承 子类在拥有自身方法同时还拥有父类方法。但这种是静态的，用户无法控制增加行为的方式和时机关联 将一个类的对象嵌入另一个对象，由另一个对象决定是否调用嵌入对象的行为以便扩展自身行为，这个嵌入的对象就叫做装饰器(Decorator)2 定义结构型模式。动态给一个对象增加额外功能，装饰器模式比生成子类实现更为灵活。装饰模式以对用户透明的方式动态给一个对象
1 定义Bridge Design Pattern，将抽象部分与它的实现部分分离，使之任意删减，而无需受其它约束。Decouple an abstraction from its implementation so that the two can vary independently，将抽象和实现解耦，让它们可以独立变化。2 结构Abstraction： 定义抽象类的接口,维护一个指向Imple
1 前言有时一个对象的行为取决于一或多个动态变化的属性（状态），这样的对象称为有状态(stateful)对象，其对象状态是从事先定义好的一系列值中取出。当这样的对象与外部事件产生互动时，内部状态就会改变，对象行为也随之变化。在UML中可使用状态图描述对象状态的变化。在状态模式中，创建表示各种状态的对象和一个行为随着状态对象改变而改变的 context 对象。2 定义该模式下，类的行为基于其状态而改
看着自己每次根据设计原则及模式的代码重构，虽然效果还不错，但你肯定也自省过：如果我的每段代码都这么写，是不是过度设计了？把握设计的度，确需长久锤炼。行业也总结了很多原则，帮助我们把握设计的度。它们是一种思考方法、一种行为准则。KISSKeep it simple, stupid，保持简单、愚蠢。提醒我们大多数系统，与其变得复杂，保持简单能让系统运行更好。越资深的人，越觉得这大有道理。因为大佬们见识
“这代码真烂”或“代码写得真好”。这描述太笼统，具体怎么烂了、怎么就好了？也有一些工程师对如何评价代码质量有所认识，如好代码易扩展、易读、简单、易维护，但更深入的，“怎么算可读性好？代码怎么算易扩展、易维护？可读、可扩展与可维护之间有什么关系？可维护中‘维护’两字该如何理解？”如果连啥是好代码、烂代码，都分不清，又谈何写好代码？如何评价代码质量的高低？对代码质量的一种描述：“好”笼统地表示代码质量
看了很多基础的书籍，比如操作系统、组成原理、编译原理等，但还是觉得很迷茫，觉得在开发中用不上，起码在平时的CRUD业务开发中用不上。实际上，这些基础的知识确实很难直接转化成开发“生产力”。但是，它能潜移默化地、间接地提高你对技术的理解。不过，我觉得，设计模式和操作系统、组成原理、编译原理等这些基础学科是不一样的。它虽然也算是一门基础知识，但是它和数据结构、算法更像是一道儿的，相比那些更加基础的学科
鸟类型体系是一个清晰的泛化体系：父类是抽象的“鸟”，子类是各种具体鸟。这是教科书中经常讨论的继承和多态，但并非实践中使用继承的唯一方式。而且这种方式很可能不是最常用或最好。另一种使用继承：我想表达某个对象与另一个对象大体类似，但又有一些不同之处。 有一家评级机构，要对远洋航船的航行进行投资评级。这家评级机构会给出“A”或“B”两种评级，取决于多种风险和盈利潜力的因素。在评估风险时，既要考虑航程本身
有读者看到标题就开始敲键盘了，我知道，命名不就是不能用 abc、123 命名，名字要有意义嘛，这有什么好讲的？然而，即便懂得了名字要有意义，很多程序员依然无法逃离命名沼泽。
Copyright © 2005-2025 51CTO.COM 版权所有 京ICP证060544号
