🚏导论 代码生成是指通过机器学习模型生成代码的过程，是自然语言处理和程序生成的结合。代码生成技术在软件开发、自动化测试、代码补全等领域有着广泛的应用。本文将记录代码生成相关的论文笔记，包括代码生成模型、评估指标等内容。 🔍索引 代码生成相关模型 MetaGPT: Meta Programming for A Multi-Agent Collaborative Framework 代码生成评估指标 Evaluating Large Language Models Trained on Code
🚏 导论 设计模式是软件开发中解决常见问题的最佳实践，它们凝聚了多年的工程经验与智慧，是提升代码质量、可维护性和灵活性的关键工具。设计模式通过提供一套通用的解决方案，使得开发人员能够应对不同的需求和挑战，而不必从零开始设计系统架构。 在这部分内容中，我将通过学习经典的《大话设计模式》一书，深入理解和探讨23种设计模式。从实际应用的角度出发，我们不仅关注每种模式的定义和结构，更会探索它们在现实世界中的应用场景。 💻 代码 Java代码实现 🔍 索引 设计模式的七大原则 单一职责原则(Single Responsibility Principle) 开放-封闭原则(Open Closed Principle) 依赖倒置原则(Dependency Inversion Principle) 里氏替换原则(Liskov Substitution Principle) 接口隔离原则(Interface Segregation Principle) 迪米特法则(Law of Demeter) 合成复用原则(Composite Reuse Principle) 设计模式的三大类 创建性(Creational Pattern) 抽象工厂模式(Abstract Factory Pattern) 建造者模式(Builder Pattern) 工厂方法模式(Factory Method Pattern) 原型模式(Prototype Pattern) 单例模式(Singleton Pattern) 结构性(Structural Pattern) 适配器模式(Adapter Pattern) 桥接模式(Bridge Pattern) 组合模式(Composite Pattern) 装饰模式(Decorator Pattern) 外观模式(Facade Pattern) 享元模式(Flyweight Pattern) 代理模式(Proxy Pattern) 行为型(Behavioral Pattern) 观察者模式(Observer Pattern) 模板模式(Template Pattern) 命令模式(Command Pattern) 状态模式(State Pattern) 职责链模式(Chain of Responsibility Pattern) 解释器模式(Interpreter Pattern) 中介者模式(Mediator Pattern) 访问者模式(Visitor Pattern) 策略模式(Strategy Pattern) 备忘录模式(Memento Pattern) 迭代器模式(Iterator Pattern)
🚏 导论 装饰模式（Decorator Pattern）：动态地给一个对象添加一些额外的职责。就增加功能来说，装饰模式比生成子类更为灵活。当现有目标功能不足的时候，需要增强时，可以考虑使用装饰模式。 装饰模式把每个要装饰的代码放在单独的类中，并让这个类包装它所要装饰的对象，因此，当需要执行特殊行为时，客户代码就可以在运行时根据需要有选择地、按顺序地使用装饰功能包装对象了。 装饰器常在面向切面编程（AOP）中使用，比如日志、事务、权限等功能。 🚦 结构 UML类图 classDiagram class Component{ <<interface>> +operation() } class ConcreteComponent{ +operation() } class Decorator{ <<abstract>> -component: Component +operation() } class ConcreteDecoratorA{ -addedState +operation() } class ConcreteDecoratorB{ +operation() -AddedBehavior() } Component <|-- ConcreteComponent Component <|-- Decorator Decorator o-- Component Decorator <|-- ConcreteDecoratorA Decorator <|-- ConcreteDecoratorB Component是定义一个对象接口，可以给这些对象动态地添加职责。ConcreteComponent是定义了一个具体的对象，也可以给这个对象添加一些职责。Decorator，装饰抽象类，继承了Component，从外类来扩展Component类的功能，但对于Component来说，是无需知道Decorator的存在的。至于ConcreteDecorator就是具体的装饰对象，起到给Component添加职责的功能。 装饰模式是利用setComponent来对对象进行包装的。这样每个装饰对象的实现就和如何使用这个对象分离开了，每个装饰对象只关心自己的功能，不需要关心如何被添加到对象链当中。 基本代码 Component类 public interface Component { void operation(); } ConcreteComponent类 public class ConcreteComponent implements Component { @Override public void operation() { System.out.println("具体对象的操作"); } } Decorator类 ...
🚏 导论 里氏替换原则（LSP）：子类型必须能够替换掉它们的父类型。 里氏替换原则是Barbara Liskov女士在1988年发表的，A behavioral notion of subtyping, 具体的数学定义如下所示：If S is a declared subtype of T, objects of type S should behave as objects of type T are expected to behave, if they are treated as objects of type T。用大白话翻译就是一个软件实体如果使用的是一个父类的话，那么一定适用于其子类，而且它察觉不出父类对象和子类对象的区别。也就是说，在软件里面，把父类都替换成它的子类，程序的行为没有变化。 由于有里氏替换原则，才使得开放-封闭成为了可能，正是由于子类性的可替换性才使得使用父类类型的模块在无需修改的情况下可以扩展。 🎬 场景 场景一：🐒 动物世界 因为了有了这个原则，使得继承复用成为了可能，只有当子类可以替换掉父类，软件单位的功能不受到影响时，父类才能真正被复用，而子类也能够在父类的基础上增加新的行为。猫是继承动物类的，以动物的身份拥有吃、喝、跑、叫等行为，可当某一天，我们需要狗、牛、羊也拥有类似的行为，由于它们都是继承于动物，所以除了更改实例化的地方，程序其他处不需要改变。
🚏 导论 依赖倒转原则 A. 高层模块不应该依赖低层模块。两个都应该依赖抽象。 B. 抽象不应该依赖细节。细节应该依赖抽象。 🎬 场景 场景一：📦 修电脑 当电脑出现蓝屏时，通常考虑是否时内存坏了或是内存条与主板接触不良。如果是内存坏了，那么就需要更换内存条，如果是内存条与主板接触不良，那么就需要重新插拔内存条。得益于电脑部件以及相关接口的设计，只需要了解简单的计算机知识，就可以轻松的定位问题并维修电脑了。他们的设计中体现了依赖倒转原则，当然还有其他的原则（单一职责原则、开放-封闭原则）。依赖倒转原则原话是说抽象不应该依赖细节，细节应该依赖于抽象，其实就是面向接口编程，而不是面向实现编程。无论主板、CPU、内存、硬盘都是在针对接口设计的，如果针对实现来设计，内存就要对应到具体的某个品牌的主板，那就回出现换内存需要把主板也换了的尴尬。 与修📻收音机相比，修电脑反而要简单。是因为收音机耦合过度了，只要收音机出现故障，不管是没有声音、不能调频，还是有杂音，反正都很难修，因为任何问题都可能涉及其他部件，各个部件相互依赖，难易维护。