尧图网站建设 
GitHub Copilot OOP 设计模式指令实战指南用 GoF 模式与 SOLID 原则驾驭 AI 代码生成【免费下载链接】awesome-copilotCommunity-contributed instructions, agents, skills, and configurations to help you make the most of GitHub Copilot.项目地址: https://gitcode.com/GitHub_Trending/aw/awesome-copilot本文深入解读 awesome-copilot 仓库中面向 GitHub Copilot 的 OOP 设计模式指令。该指令文件将 Gang of FourGoF23 种设计模式、SOLID 五大原则与干净代码实践固化为 Copilot 的代码生成与重构准则适用于 Python、Java、TypeScript、JavaScript、C# 等主流面向对象语言。读完本文你将掌握如何配置该指令、理解每一类模式的适用场景与取舍并学会让 Copilot 在生成代码时自动完成模式识别、接口优先设计、可测试性与文档化从而把 AI 编码助手培养成一名合格的设计驱动型工程师。指令文件是什么一段写给 Copilot 的架构品味契约awesome-copilot 是一个社区共建的 GitHub Copilot 自定义资源集合其中 instructions 目录 收录了大量面向具体技术栈的指令文件。这些*.instructions.md文件本质上是注入到 Copilot 上下文中的系统提示用于约束其代码生成的风格与质量。OOP 设计模式指令 是其中一份通用性极强的指令它不绑定某个框架或云平台而是作用于任何以类为核心组织代码的语言。从该文件头部的 YAML frontmatter 可以看出它的生效范围--- description: Best practices for applying Object-Oriented Programming (OOP) design patterns, including Gang of Four (GoF) patterns and SOLID principles, to ensure clean, maintainable, and scalable code. applyTo: **/*.py, **/*.java, **/*.ts, **/*.js, **/*.cs ---applyTo字段是一个 glob 模式决定了指令的适用范围当你在工作区中编辑或让 Copilot 生成 Python.py、Java.java、TypeScript.ts、JavaScript.js与 C#.cs文件时这段指令才会被激活。这与仓库中 指令文件编写规范 定义的格式完全一致——每一份高质量指令都应具备description1-500 字符说明用途与applyTo可精确到文件类型或路径。如何安装与启用根据 README 与 指令目录说明启用该指令有两种常见方式整仓/工作区级把指令内容复制到工作区的.github/copilot-instructions.md使 Copilot 在整个项目中始终遵循这些设计模式约束。任务/文件级将指令保存为.github/instructions/oop-design-patterns.instructions.md这类独立文件让它在编辑匹配applyTo模式的文件时自动生效。在 VS Code 中也可以直接点击指令目录中对应条目的Install按钮一键安装。安装后无需额外开关Copilot 在处理匹配文件时会自动读取这些规则。核心架构哲学四条贯穿始终的设计主线指令开篇即定义了四条总纲它们是后续所有模式选择的判断依据。理解这四条才能真正读懂 Copilot 在具体场景中为何选择某个模式。1. 面向接口编程而非面向实现编程Program to an Interface, not an Implementation要求代码中的依赖类型尽量是抽象类或接口具体实现通过依赖注入Dependency Injection, DI在运行时注入。这样替换实现如把内存存储换成数据库存储时无需改动调用方。// 面向接口调用方只依赖抽象 interface TaxCalculator { calculate(amount: number): number; } class OrderService { // 通过构造函数注入具体实现而非 new 一个具体类 constructor(private readonly taxCalculator: TaxCalculator) {} }2. 组合优于继承Favor Object Composition over Class Inheritance用对象组合在运行时动态组合行为避免过深的继承树在适当场景用委托Delegation复用行为而不破坏封装。深继承链的典型问题是脆弱的基类Fragile Base Class——修改基类可能连带破坏所有子类而组合把依赖关系显式化、可替换化。3. 封装变化Encapsulate What Varies识别应用中变化的部分把它们与稳定部分分离。Strategy、State、Bridge 三个模式都是这条原则的典型应用把会变的行为/维度抽离成独立的对象。4. 松耦合Loose Coupling最小化类之间的直接依赖。用 Mediator中介者集中协调对象间通信、用 Observer观察者实现发布-订阅、用抽象工厂隔离产品族的创建逻辑都能有效降低耦合度。松耦合的收益直接体现为可测试性依赖越少单测时越容易 mock。创建型模式指南把如何创建对象与业务解耦指令规定当生成涉及对象创建或实例化的代码时用创建型模式把系统与对象如何被创建解耦。五大创建型模式的选用规则如下模式何时使用核心要点Abstract Factory 抽象工厂系统需要配置为多个相关产品族之一如跨平台 UI 控件客户端只与抽象工厂和抽象产品接口交互Factory Method 工厂方法类无法预知它必须创建的对象类把实例化延迟到子类Builder 建造者构造复杂对象需要分步过程且同一构造过程可产生不同表示将构造过程与表示分离Singleton 单例仅当必须保证类只有单一实例并提供全局访问点如集中配置管理器、硬件接口优先用 DI 替代严格单例Prototype 原型避免构建工厂类层级或从零创建比克隆现有对象更昂贵通过克隆复制现有实例指令特别强调了 Singleton 的克制使用Useonlywhen absolutely necessary。在现代工程实践中依赖注入容器Spring、ASP.NET Core DI、NestJS天然保证单实例生命周期因此应优先选择 DI 而非手写getInstance()单例以保持可测试性。这条取舍建议在指令中明确写出Copilot 生成单例代码前会先评估是否真有此必要。工厂方法示例Java// 工厂方法把实例化延迟到子类 public abstract class DocumentProcessor { public final void process(String content) { Document doc createDocument(); // 工厂方法 doc.open(content); doc.save(); } protected abstract Document createDocument(); } public class PdfProcessor extends DocumentProcessor { Override protected Document createDocument() { return new PdfDocument(); } }结构型模式指南如何把类与对象组合成更大的结构结构型模式关注类与对象的组合方式。指令列出了七个模式其中 Adapter 与 Decorator 附带了明确的实现偏好模式何时使用关键约束Adapter 适配器让不兼容的接口协同工作优先用对象适配器组合而非类适配器多继承Bridge 桥接将抽象与其实现分离使两者可独立变化典型场景高层Window概念与平台相关WindowImpl分离Composite 组合表示部分-整体层级客户端通过公共Component接口统一对待单个对象与对象组合Decorator 装饰器动态给对象附加职责装饰器必须与被装饰组件保持完全相同的接口优先于子类化以防类爆炸Facade 外观为复杂子系统提供简单统一接口隐藏子系统内部复杂性Flyweight 享元通过尽可能共享相似对象来降低内存/计算开销适合大量细粒度对象场景Proxy 代理为另一对象提供替身以控制访问典型用途懒加载、访问控制、远程通信适配器组合优于多继承# 目标接口 class JsonSerializer: def serialize(self, data: dict) - str: ... # 不兼容的第三方类 class XmlWriter: def to_xml(self, obj: dict) - str: ... # 对象适配器通过组合包装而非多继承 class XmlToJsonAdapter(JsonSerializer): def __init__(self, writer: XmlWriter): self._writer writer # 组合而非继承 XmlWriter def serialize(self, data: dict) - str: return self._writer.to_xml(data)指令明确要求Adapter 采用对象适配器组合而非类适配器多继承因为组合提供更大的灵活性可以在运行时更换被适配对象且不受多继承的语法与语义限制。Decorator 也遵循同一逻辑——确保 Decorator 与被装饰组件接口完全一致这样客户端无感知地叠加职责如日志、缓存、权限校验而不产生子类爆炸。行为型模式指南算法、控制流与对象间通信行为型模式处理算法组织与对象间协作共十种指令给出的选用规则是这一节的重头戏模式何时使用关键约束Strategy 策略定义一族算法、各自封装并可互换消除选择行为的复杂switch/if-else委托给策略对象Observer 观察者定义一对多依赖Subject 变化自动通知 Observers主题与观察者保持松耦合Command 命令把请求封装为对象实现撤销/重做、队列、请求日志的关键State 状态对象行为强烈依赖内部状态且需运行时切换每个状态用独立类表示Template Method 模板方法在基类定义算法骨架具体步骤由子类实现不改变算法结构Chain of Responsibility 责任链请求沿处理者链传递直到被处理避免发送方耦合到特定接收方Mediator 中介者集中一组对象的复杂通信与控制逻辑让对象互不直接引用Iterator 迭代器顺序访问聚合对象元素不暴露底层表示Visitor 访问者在不改变元素类的前提下定义新操作特别适合 AST 等稳定组合结构上的不同分析Memento 备忘录捕获并外部化对象内部状态而不破坏封装用于复杂 Undo 机制Strategy消灭条件分支指令对 Strategy 的描述最具攻击性——Eliminate complex conditional logic (switch/if-else) that selects behavior by delegating to a Strategy object。这也是 Copilot 遇到我有多种计税方式这类需求时应立刻联想到的模式// 策略接口 具体策略 public interface ITaxStrategy { decimal Calculate(decimal amount); } public class VatTax : ITaxStrategy { public decimal Calculate(decimal amount) amount * 0.2m; } public class NoTax : ITaxStrategy { public decimal Calculate(decimal amount) 0m; } // 客户端不再出现 switch (country) 的税计算分支 public class InvoiceService { private readonly ITaxStrategy _tax; public InvoiceService(ITaxStrategy tax) _tax tax; // DI 注入 public decimal ComputeTotal(decimal amount) amount _tax.Calculate(amount); }这里的收益是双向的业务代码不再被switch淹没新增税率只需新增一个策略类满足开闭原则且每个策略可以独立单测满足可测试性。State 与 Strategy 结构相似区别在于状态对象通常持有对上下文的反向引用并可驱动状态迁移而策略是完全被动的算法单元——Copilot 生成时需注意二者不混用。Command为撤销/重做而生public interface Command { void execute(); void undo(); } public class InsertTextCommand implements Command { private final TextEditor editor; private final String text; // execute() 执行插入undo() 逆操作 }指令指出 Command 是实现撤销/重做、任务队列或请求日志的必备机制因为请求一旦被封装成对象就可以被存储、排队、序列化并支持逆操作。Copilot 代码生成规则把设计原则翻译成机器可执行的约束这一节是整份指令中最可操作的部分共 20 余条规则。它们构成 Copilot 生成代码时的完整决策链可归纳为几个层面模式识别与命名模式识别Pattern Recognition当提示词映射到某个 GoF 模式时如我需要撤销这个操作我有多种计税方式必须在注释中显式注明正在应用的模式。这既让开发者容易审查也让后续维护者理解设计意图。命名约定在有助于理解的地方把模式名融入类名如TaxCalculationStrategy、ButtonDecorator、WidgetFactory但保持命名贴合领域不要生硬套用。接口优先与封装接口优先Interface First先生成接口或抽象基类再生成具体实现。不可变与封装字段默认private仅在必要时提供 getter/setter优先不可变对象。不可变对象天然线程安全、易于缓存与共享也与 Flyweight 等模式相得益彰。避免上帝类God Class把庞大复杂的类拆成多个专注的小类通过 Mediator 协调或由小型 Strategy 对象组合。SOLID 五原则的落地指令把五条原则逐条写成了对 Copilot 的硬性要求并给出了关键判断标准单一职责SRP每个类只有一个变更理由类承担过多职责时就拆分。开闭原则OCP对扩展开放、对修改关闭用抽象类或接口承载新行为。里氏替换LSP子类必须能无副作用地替换基类派生类不得强化前置条件或弱化后置条件——这是最容易在继承设计中出错、也最容易被 AI 忽略的点。接口隔离ISP偏好多个专用接口而非一个通用大接口客户端不应被迫依赖其未使用的接口。依赖倒置DIP依赖抽象而非具体高层模块与低层模块都应依赖抽象层。工程纪律明智地使用模式Judiciously仅在能带来可维护性、灵活性或可读性实际收益时使用避免过度设计指令甚至明确要求能用简单函数解决的问题优先定义函数类与模式仅在带来清晰组织收益时使用。记录意图Document Intent使用模式时必须注释解释为什么选它、如何应用。可测试性Testability用依赖注入便于 mock编写验证模式行为的测试。迭代重构Refactor Iteratively重构时小步增量、以测试保障行为不变。性能考量模式会引入抽象层注意性能影响用性能分析工具定位瓶颈但不牺牲可维护性。一致性与评审同类场景保持同一设计语言定期代码评审聚焦设计质量。仓储与类型定义Repositories Typing涉及复杂数据结构与交互时用 Repository 抽象数据访问、用类型定义保证类型安全——这呼应了分离关注点的总目标。日志与错误处理模式的伴生工程指令专门强调应用设计模式时日志与错误处理必须同步集成具体规则包括Fail safe, loud, clear and early——安全失败、响亮失败、清晰失败、尽早失败杜绝静默失败。错误日志需携带足够上下文便于排障与维护。在合适场景使用自定义异常提供更有意义的错误信息并允许客户端代码做更细粒度的处理。异常块用于处理预期的错误条件而非控制正常程序流避免把异常当 goto 使用。使用日志框架管理日志级别与输出区分开发/生产环境。在每个类与函数中合理使用 info、debug、warning、error、critical 级别考虑实现集中式错误处理机制如全局异常处理器保证错误响应与日志的一致性。这条规则的实际意义在于设计模式尤其装饰器、代理、责任链会引入多层调用若每层都静默吞掉异常排障将极为困难。配合记录意图规则模式边界处的日志将成为系统运行时行为的活文档。文档规范让模式设计可被团队读懂指令要求模式化代码配套良好文档核心规则包括使用英文 docstring说明类与方法用途注释澄清复杂逻辑与设计决策默认采用numpy 风格的参数/返回值文档若现有代码采用其他风格则遵循现有风格。特别地指令要求在首次使用时向开发者确认偏好之后统一采用该风格——这是一种一次询问、全局统一的上下文收敛策略。可用 Sphinx 或 JSDoc 等工具从代码库生成文档。在 README 或专用文档中维护高层架构总览说明各组件与模式如何契合整体架构。文档分用户文档如何使用与开发者文档如何工作与维护并随代码演进保持更新。合适处使用 UML 等图表表达类与模式间关系。克制文档膨胀不要不断创建包含相同内容的新文档文件扫描既有文档以相同风格扩展或新建保持简洁、聚焦、避免冗余。仓库内的实践佐证指令精神在真实代码中的回响设计模式的价值在于约束生成而非展示语法。在本仓库的源码中可以找到与指令精神高度一致的工程实践证明这些原则是可落地、可验证的同步词映射即数据驱动的策略/享元skills/mini-context-graph/scripts/tools/ontology_store.py用两张同义词映射表_ENTITY_TYPE_MAP与_RELATION_TYPE_MAP把上百个实体/关系同义词归一化为少量规范形式如class/function/method均归一化为component。从结构上看这就是把变化的数据集中管理、运行时查找替换避免了在每个使用点编写if/else分支——与指令倡导的封装变化、消灭条件分支一脉相承。单一职责的极致拆分eng/validate-plugins.mjs将插件校验拆分为validateName、validateSchema、validateDescription、validateVersion、validateKeywords等多个专注函数每个函数只做一件事、只返回自己的错误集合——正是 SRP 与避免上帝类/上帝函数的直接体现。面向接口的校验管线同一文件中validateLicenseField、validateAgentPluginManifest、validateAgentPluginMcpConfig等被从其他模块导入复用校验逻辑通过导入接口组装符合 DIP 精神。指令生态本身的组合设计本仓库把资源划分为 agents、instructions、skills、plugins、hooks、workflows 等类别见 README插件再组合多个 agent 与 skill——这种以小粒度单元组合出复杂能力的组织方式与组合优于继承的设计哲学同构。这些实例说明指令文件并不是孤立的规则清单它与仓库内真实代码的工程品味互相印证。当 Copilot 遵循该指令生成代码时其产出风格将与这些经过评审的社区代码保持一致。结语把设计模式指令当作团队的架构守门员OOP 设计模式指令 的价值不在于罗列 23 个模式的教科书定义而在于把有品味的架构决策编码成 Copilot 每次生成代码时的默认行为面向接口、组合优先、封装变化、松耦合创建对象先想工厂族组织行为先想策略与状态控制访问先想代理与装饰类要小、依赖要抽象、模式要注明意图、日志与测试要同步到位。将这份指令装入工作区后Copilot 从一个语法正确的代码生成器升级为遵循团队设计语言的协作者。配合 指令文件编写规范 与 指令目录 中其他领域指令如 C# 开发、Java 开发你可以为团队构建一套完整、一致、可持续演进的 AI 编码约束体系——而这正是本仓库的核心价值所在。【免费下载链接】awesome-copilotCommunity-contributed instructions, agents, skills, and configurations to help you make the most of GitHub Copilot.项目地址: https://gitcode.com/GitHub_Trending/aw/awesome-copilot创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 GitHub Copilot OOP 设计模式指令实战指南：用 GoF 模式与 SOLID 原则驾驭 AI 代码生成
GitHub Copilot OOP 设计模式指令实战指南用 GoF 模式与 SOLID 原则驾驭 AI 代码生成【免费下载链接】awesome-copilotCommunity-contributed instructions, agents, skills, and configurations to help you make the most of GitHub Copilot.项目地址: https://gitcode.com/GitHub_Trending/aw/awesome-copilot本文深入解读 awesome-copilot 仓库中面向 GitHub Copilot 的 OOP 设计模式指令。该指令文件将 Gang of FourGoF23 种设计模式、SOLID 五大原则与干净代码实践固化为 Copilot 的代码生成与重构准则适用于 Python、Java、TypeScript、JavaScript、C# 等主流面向对象语言。读完本文你将掌握如何配置该指令、理解每一类模式的适用场景与取舍并学会让 Copilot 在生成代码时自动完成模式识别、接口优先设计、可测试性与文档化从而把 AI 编码助手培养成一名合格的设计驱动型工程师。指令文件是什么一段写给 Copilot 的架构品味契约awesome-copilot 是一个社区共建的 GitHub Copilot 自定义资源集合其中 instructions 目录 收录了大量面向具体技术栈的指令文件。这些*.instructions.md文件本质上是注入到 Copilot 上下文中的系统提示用于约束其代码生成的风格与质量。OOP 设计模式指令 是其中一份通用性极强的指令它不绑定某个框架或云平台而是作用于任何以类为核心组织代码的语言。从该文件头部的 YAML frontmatter 可以看出它的生效范围--- description: Best practices for applying Object-Oriented Programming (OOP) design patterns, including Gang of Four (GoF) patterns and SOLID principles, to ensure clean, maintainable, and scalable code. applyTo: **/*.py, **/*.java, **/*.ts, **/*.js, **/*.cs ---applyTo字段是一个 glob 模式决定了指令的适用范围当你在工作区中编辑或让 Copilot 生成 Python.py、Java.java、TypeScript.ts、JavaScript.js与 C#.cs文件时这段指令才会被激活。这与仓库中 指令文件编写规范 定义的格式完全一致——每一份高质量指令都应具备description1-500 字符说明用途与applyTo可精确到文件类型或路径。如何安装与启用根据 README 与 指令目录说明启用该指令有两种常见方式整仓/工作区级把指令内容复制到工作区的.github/copilot-instructions.md使 Copilot 在整个项目中始终遵循这些设计模式约束。任务/文件级将指令保存为.github/instructions/oop-design-patterns.instructions.md这类独立文件让它在编辑匹配applyTo模式的文件时自动生效。在 VS Code 中也可以直接点击指令目录中对应条目的Install按钮一键安装。安装后无需额外开关Copilot 在处理匹配文件时会自动读取这些规则。核心架构哲学四条贯穿始终的设计主线指令开篇即定义了四条总纲它们是后续所有模式选择的判断依据。理解这四条才能真正读懂 Copilot 在具体场景中为何选择某个模式。1. 面向接口编程而非面向实现编程Program to an Interface, not an Implementation要求代码中的依赖类型尽量是抽象类或接口具体实现通过依赖注入Dependency Injection, DI在运行时注入。这样替换实现如把内存存储换成数据库存储时无需改动调用方。// 面向接口调用方只依赖抽象 interface TaxCalculator { calculate(amount: number): number; } class OrderService { // 通过构造函数注入具体实现而非 new 一个具体类 constructor(private readonly taxCalculator: TaxCalculator) {} }2. 组合优于继承Favor Object Composition over Class Inheritance用对象组合在运行时动态组合行为避免过深的继承树在适当场景用委托Delegation复用行为而不破坏封装。深继承链的典型问题是脆弱的基类Fragile Base Class——修改基类可能连带破坏所有子类而组合把依赖关系显式化、可替换化。3. 封装变化Encapsulate What Varies识别应用中变化的部分把它们与稳定部分分离。Strategy、State、Bridge 三个模式都是这条原则的典型应用把会变的行为/维度抽离成独立的对象。4. 松耦合Loose Coupling最小化类之间的直接依赖。用 Mediator中介者集中协调对象间通信、用 Observer观察者实现发布-订阅、用抽象工厂隔离产品族的创建逻辑都能有效降低耦合度。松耦合的收益直接体现为可测试性依赖越少单测时越容易 mock。创建型模式指南把如何创建对象与业务解耦指令规定当生成涉及对象创建或实例化的代码时用创建型模式把系统与对象如何被创建解耦。五大创建型模式的选用规则如下模式何时使用核心要点Abstract Factory 抽象工厂系统需要配置为多个相关产品族之一如跨平台 UI 控件客户端只与抽象工厂和抽象产品接口交互Factory Method 工厂方法类无法预知它必须创建的对象类把实例化延迟到子类Builder 建造者构造复杂对象需要分步过程且同一构造过程可产生不同表示将构造过程与表示分离Singleton 单例仅当必须保证类只有单一实例并提供全局访问点如集中配置管理器、硬件接口优先用 DI 替代严格单例Prototype 原型避免构建工厂类层级或从零创建比克隆现有对象更昂贵通过克隆复制现有实例指令特别强调了 Singleton 的克制使用Useonlywhen absolutely necessary。在现代工程实践中依赖注入容器Spring、ASP.NET Core DI、NestJS天然保证单实例生命周期因此应优先选择 DI 而非手写getInstance()单例以保持可测试性。这条取舍建议在指令中明确写出Copilot 生成单例代码前会先评估是否真有此必要。工厂方法示例Java// 工厂方法把实例化延迟到子类 public abstract class DocumentProcessor { public final void process(String content) { Document doc createDocument(); // 工厂方法 doc.open(content); doc.save(); } protected abstract Document createDocument(); } public class PdfProcessor extends DocumentProcessor { Override protected Document createDocument() { return new PdfDocument(); } }结构型模式指南如何把类与对象组合成更大的结构结构型模式关注类与对象的组合方式。指令列出了七个模式其中 Adapter 与 Decorator 附带了明确的实现偏好模式何时使用关键约束Adapter 适配器让不兼容的接口协同工作优先用对象适配器组合而非类适配器多继承Bridge 桥接将抽象与其实现分离使两者可独立变化典型场景高层Window概念与平台相关WindowImpl分离Composite 组合表示部分-整体层级客户端通过公共Component接口统一对待单个对象与对象组合Decorator 装饰器动态给对象附加职责装饰器必须与被装饰组件保持完全相同的接口优先于子类化以防类爆炸Facade 外观为复杂子系统提供简单统一接口隐藏子系统内部复杂性Flyweight 享元通过尽可能共享相似对象来降低内存/计算开销适合大量细粒度对象场景Proxy 代理为另一对象提供替身以控制访问典型用途懒加载、访问控制、远程通信适配器组合优于多继承# 目标接口 class JsonSerializer: def serialize(self, data: dict) - str: ... # 不兼容的第三方类 class XmlWriter: def to_xml(self, obj: dict) - str: ... # 对象适配器通过组合包装而非多继承 class XmlToJsonAdapter(JsonSerializer): def __init__(self, writer: XmlWriter): self._writer writer # 组合而非继承 XmlWriter def serialize(self, data: dict) - str: return self._writer.to_xml(data)指令明确要求Adapter 采用对象适配器组合而非类适配器多继承因为组合提供更大的灵活性可以在运行时更换被适配对象且不受多继承的语法与语义限制。Decorator 也遵循同一逻辑——确保 Decorator 与被装饰组件接口完全一致这样客户端无感知地叠加职责如日志、缓存、权限校验而不产生子类爆炸。行为型模式指南算法、控制流与对象间通信行为型模式处理算法组织与对象间协作共十种指令给出的选用规则是这一节的重头戏模式何时使用关键约束Strategy 策略定义一族算法、各自封装并可互换消除选择行为的复杂switch/if-else委托给策略对象Observer 观察者定义一对多依赖Subject 变化自动通知 Observers主题与观察者保持松耦合Command 命令把请求封装为对象实现撤销/重做、队列、请求日志的关键State 状态对象行为强烈依赖内部状态且需运行时切换每个状态用独立类表示Template Method 模板方法在基类定义算法骨架具体步骤由子类实现不改变算法结构Chain of Responsibility 责任链请求沿处理者链传递直到被处理避免发送方耦合到特定接收方Mediator 中介者集中一组对象的复杂通信与控制逻辑让对象互不直接引用Iterator 迭代器顺序访问聚合对象元素不暴露底层表示Visitor 访问者在不改变元素类的前提下定义新操作特别适合 AST 等稳定组合结构上的不同分析Memento 备忘录捕获并外部化对象内部状态而不破坏封装用于复杂 Undo 机制Strategy消灭条件分支指令对 Strategy 的描述最具攻击性——Eliminate complex conditional logic (switch/if-else) that selects behavior by delegating to a Strategy object。这也是 Copilot 遇到我有多种计税方式这类需求时应立刻联想到的模式// 策略接口 具体策略 public interface ITaxStrategy { decimal Calculate(decimal amount); } public class VatTax : ITaxStrategy { public decimal Calculate(decimal amount) amount * 0.2m; } public class NoTax : ITaxStrategy { public decimal Calculate(decimal amount) 0m; } // 客户端不再出现 switch (country) 的税计算分支 public class InvoiceService { private readonly ITaxStrategy _tax; public InvoiceService(ITaxStrategy tax) _tax tax; // DI 注入 public decimal ComputeTotal(decimal amount) amount _tax.Calculate(amount); }这里的收益是双向的业务代码不再被switch淹没新增税率只需新增一个策略类满足开闭原则且每个策略可以独立单测满足可测试性。State 与 Strategy 结构相似区别在于状态对象通常持有对上下文的反向引用并可驱动状态迁移而策略是完全被动的算法单元——Copilot 生成时需注意二者不混用。Command为撤销/重做而生public interface Command { void execute(); void undo(); } public class InsertTextCommand implements Command { private final TextEditor editor; private final String text; // execute() 执行插入undo() 逆操作 }指令指出 Command 是实现撤销/重做、任务队列或请求日志的必备机制因为请求一旦被封装成对象就可以被存储、排队、序列化并支持逆操作。Copilot 代码生成规则把设计原则翻译成机器可执行的约束这一节是整份指令中最可操作的部分共 20 余条规则。它们构成 Copilot 生成代码时的完整决策链可归纳为几个层面模式识别与命名模式识别Pattern Recognition当提示词映射到某个 GoF 模式时如我需要撤销这个操作我有多种计税方式必须在注释中显式注明正在应用的模式。这既让开发者容易审查也让后续维护者理解设计意图。命名约定在有助于理解的地方把模式名融入类名如TaxCalculationStrategy、ButtonDecorator、WidgetFactory但保持命名贴合领域不要生硬套用。接口优先与封装接口优先Interface First先生成接口或抽象基类再生成具体实现。不可变与封装字段默认private仅在必要时提供 getter/setter优先不可变对象。不可变对象天然线程安全、易于缓存与共享也与 Flyweight 等模式相得益彰。避免上帝类God Class把庞大复杂的类拆成多个专注的小类通过 Mediator 协调或由小型 Strategy 对象组合。SOLID 五原则的落地指令把五条原则逐条写成了对 Copilot 的硬性要求并给出了关键判断标准单一职责SRP每个类只有一个变更理由类承担过多职责时就拆分。开闭原则OCP对扩展开放、对修改关闭用抽象类或接口承载新行为。里氏替换LSP子类必须能无副作用地替换基类派生类不得强化前置条件或弱化后置条件——这是最容易在继承设计中出错、也最容易被 AI 忽略的点。接口隔离ISP偏好多个专用接口而非一个通用大接口客户端不应被迫依赖其未使用的接口。依赖倒置DIP依赖抽象而非具体高层模块与低层模块都应依赖抽象层。工程纪律明智地使用模式Judiciously仅在能带来可维护性、灵活性或可读性实际收益时使用避免过度设计指令甚至明确要求能用简单函数解决的问题优先定义函数类与模式仅在带来清晰组织收益时使用。记录意图Document Intent使用模式时必须注释解释为什么选它、如何应用。可测试性Testability用依赖注入便于 mock编写验证模式行为的测试。迭代重构Refactor Iteratively重构时小步增量、以测试保障行为不变。性能考量模式会引入抽象层注意性能影响用性能分析工具定位瓶颈但不牺牲可维护性。一致性与评审同类场景保持同一设计语言定期代码评审聚焦设计质量。仓储与类型定义Repositories Typing涉及复杂数据结构与交互时用 Repository 抽象数据访问、用类型定义保证类型安全——这呼应了分离关注点的总目标。日志与错误处理模式的伴生工程指令专门强调应用设计模式时日志与错误处理必须同步集成具体规则包括Fail safe, loud, clear and early——安全失败、响亮失败、清晰失败、尽早失败杜绝静默失败。错误日志需携带足够上下文便于排障与维护。在合适场景使用自定义异常提供更有意义的错误信息并允许客户端代码做更细粒度的处理。异常块用于处理预期的错误条件而非控制正常程序流避免把异常当 goto 使用。使用日志框架管理日志级别与输出区分开发/生产环境。在每个类与函数中合理使用 info、debug、warning、error、critical 级别考虑实现集中式错误处理机制如全局异常处理器保证错误响应与日志的一致性。这条规则的实际意义在于设计模式尤其装饰器、代理、责任链会引入多层调用若每层都静默吞掉异常排障将极为困难。配合记录意图规则模式边界处的日志将成为系统运行时行为的活文档。文档规范让模式设计可被团队读懂指令要求模式化代码配套良好文档核心规则包括使用英文 docstring说明类与方法用途注释澄清复杂逻辑与设计决策默认采用numpy 风格的参数/返回值文档若现有代码采用其他风格则遵循现有风格。特别地指令要求在首次使用时向开发者确认偏好之后统一采用该风格——这是一种一次询问、全局统一的上下文收敛策略。可用 Sphinx 或 JSDoc 等工具从代码库生成文档。在 README 或专用文档中维护高层架构总览说明各组件与模式如何契合整体架构。文档分用户文档如何使用与开发者文档如何工作与维护并随代码演进保持更新。合适处使用 UML 等图表表达类与模式间关系。克制文档膨胀不要不断创建包含相同内容的新文档文件扫描既有文档以相同风格扩展或新建保持简洁、聚焦、避免冗余。仓库内的实践佐证指令精神在真实代码中的回响设计模式的价值在于约束生成而非展示语法。在本仓库的源码中可以找到与指令精神高度一致的工程实践证明这些原则是可落地、可验证的同步词映射即数据驱动的策略/享元skills/mini-context-graph/scripts/tools/ontology_store.py用两张同义词映射表_ENTITY_TYPE_MAP与_RELATION_TYPE_MAP把上百个实体/关系同义词归一化为少量规范形式如class/function/method均归一化为component。从结构上看这就是把变化的数据集中管理、运行时查找替换避免了在每个使用点编写if/else分支——与指令倡导的封装变化、消灭条件分支一脉相承。单一职责的极致拆分eng/validate-plugins.mjs将插件校验拆分为validateName、validateSchema、validateDescription、validateVersion、validateKeywords等多个专注函数每个函数只做一件事、只返回自己的错误集合——正是 SRP 与避免上帝类/上帝函数的直接体现。面向接口的校验管线同一文件中validateLicenseField、validateAgentPluginManifest、validateAgentPluginMcpConfig等被从其他模块导入复用校验逻辑通过导入接口组装符合 DIP 精神。指令生态本身的组合设计本仓库把资源划分为 agents、instructions、skills、plugins、hooks、workflows 等类别见 README插件再组合多个 agent 与 skill——这种以小粒度单元组合出复杂能力的组织方式与组合优于继承的设计哲学同构。这些实例说明指令文件并不是孤立的规则清单它与仓库内真实代码的工程品味互相印证。当 Copilot 遵循该指令生成代码时其产出风格将与这些经过评审的社区代码保持一致。结语把设计模式指令当作团队的架构守门员OOP 设计模式指令 的价值不在于罗列 23 个模式的教科书定义而在于把有品味的架构决策编码成 Copilot 每次生成代码时的默认行为面向接口、组合优先、封装变化、松耦合创建对象先想工厂族组织行为先想策略与状态控制访问先想代理与装饰类要小、依赖要抽象、模式要注明意图、日志与测试要同步到位。将这份指令装入工作区后Copilot 从一个语法正确的代码生成器升级为遵循团队设计语言的协作者。配合 指令文件编写规范 与 指令目录 中其他领域指令如 C# 开发、Java 开发你可以为团队构建一套完整、一致、可持续演进的 AI 编码约束体系——而这正是本仓库的核心价值所在。【免费下载链接】awesome-copilotCommunity-contributed instructions, agents, skills, and configurations to help you make the most of GitHub Copilot.项目地址: https://gitcode.com/GitHub_Trending/aw/awesome-copilot创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考