<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Design on Tony Bai</title><link>https://tonybai.com/tags/design/</link><description>Recent content in Design on Tony Bai</description><generator>Hugo</generator><language>zh-cn</language><copyright>2004-2026 Tony Bai. 版权所有.</copyright><lastBuildDate>Fri, 23 May 2025 00:00:00 +0800</lastBuildDate><atom:link href="https://tonybai.com/tags/design/index.xml" rel="self" type="application/rss+xml"/><item><title>API设计的“Go境界”：Go团队设计MCP SDK过程中的取舍与思考</title><link>https://tonybai.com/2025/05/23/go-api-design-mcp-sdk/</link><pubDate>Fri, 23 May 2025 00:00:00 +0800</pubDate><guid>https://tonybai.com/2025/05/23/go-api-design-mcp-sdk/</guid><description>本文永久链接 – https://tonybai.com/2025/05/23/go-api-design-mcp-sdk 大家好，我是 Tony Bai。 作为开发者，我们每天都在与 API 打交道——调用它们，设计它们，有时也会为糟糕的 API 设计而头痛不已。一个优秀的 API，如同一位技艺精湛的向导，能清晰、高效地引领我们通往复杂功能的彼岸；而一个蹩脚的 API，则可能像一座布满陷阱的迷宫...</description></item><item><title>简单之道</title><link>https://tonybai.com/2023/12/11/simplicity/</link><pubDate>Mon, 11 Dec 2023 00:00:00 +0800</pubDate><guid>https://tonybai.com/2023/12/11/simplicity/</guid><description>本文永久链接 – https://tonybai.com/2023/12/11/simplicity 已经退居二线的Go语言之父Rob Pike近日发表了一篇名为“Simplicity”的博文，记述了2009年在Google内部一次圆桌会议上发表的演讲内容。Pike老先生在这个时间点发表这篇文章究竟有何深意呢？是对Go语言演进的路线有所不满吗？我们不得而知。不过，这篇文章的内容却是非常值得我们学习...</description></item><item><title>Go语言包设计指南</title><link>https://tonybai.com/2023/06/18/go-package-design-guide/</link><pubDate>Sun, 18 Jun 2023 00:00:00 +0800</pubDate><guid>https://tonybai.com/2023/06/18/go-package-design-guide/</guid><description>本文永久链接 – https://tonybai.com/2023/06/18/go-package-design-guide 1\. Go包的认知 ---------- 1.1 Go包是基本功能单元 我们知道Go包是Go编程语言中的一个重要概念，它是一组相关的Go源代码文件。并且，在Go中，每个Go源文件都必须属于一个包。 Go包是一个逻辑上独立的单元，是Go的**基本功能单元**，用来做功能边...</description></item><item><title>Adapter模式的C实现</title><link>https://tonybai.com/2012/03/05/implement-adapter-pattern-in-c/</link><pubDate>Mon, 05 Mar 2012 00:00:00 +0800</pubDate><guid>https://tonybai.com/2012/03/05/implement-adapter-pattern-in-c/</guid><description>Adapter(适配器)模式是《Design Pattern》一书中结构类模式集中的第一个模式，也是一个真正被我的同事在产品代码中应用的模式。 Adapter模式也是一个相对容易理解的模式，多数书籍和网络资料在描述这个模式时都使用了一个与电源适配器有关的例子，说不定Adapter模式还真的是源于对电源适配器的再思考和挖掘呢。 我们在重构遗留代码时引入了Adapter模式。遗留系统中存在的问题大致是...</description></item><item><title>State模式的C实现</title><link>https://tonybai.com/2011/11/07/implement-state-pattern-in-c/</link><pubDate>Mon, 07 Nov 2011 00:00:00 +0800</pubDate><guid>https://tonybai.com/2011/11/07/implement-state-pattern-in-c/</guid><description>上个周末花了些时间将《Pro Git》（Git高手进阶之必读书籍，严重推荐^\_^）快速地浏览了一遍，在感叹于Git强大的同时，也见识到了Git的复杂。可以肯定的是Git学习曲线远没有学习Subversion那样平坦。比如，Subversion工作目录下的文件只有三种状态：Untracked、Modified和Committed(即Unmodified)；而以Git本地工作目录下则有四种状态：Un...</description></item><item><title>Transaction模式的C实现</title><link>https://tonybai.com/2011/11/04/implement-transaction-pattern-in-c/</link><pubDate>Fri, 04 Nov 2011 00:00:00 +0800</pubDate><guid>https://tonybai.com/2011/11/04/implement-transaction-pattern-in-c/</guid><description>提到Transaction模式(即事务模式)，很多人会感到陌生。这并不奇怪，在大名鼎鼎的GoF的《Design Pattern》一书中，它仅仅是Command模式的别名罢了。不过在实际的开发中，我们却经常会遇到可以应用事务模式的场景。本文可以理解成Command模式在事务领域的应用，但这样说有些麻烦，我们莫不如直接称之为Transaction模式。 与前几篇设计模式C实现系列文章一样，这篇文章也源...</description></item><item><title>Chain of Responsibility模式的C实现</title><link>https://tonybai.com/2011/10/25/implement-chain-of-responsibility-pattern-in-c/</link><pubDate>Tue, 25 Oct 2011 00:00:00 +0800</pubDate><guid>https://tonybai.com/2011/10/25/implement-chain-of-responsibility-pattern-in-c/</guid><description>又是一个行为类的模式，似乎这类模式在使用C语言开发的项目中适应性更强，而另外两类模式创建型和结构型则略显不受待见^\_^。 Chain of Responsibility模式（中文名：职责链模式）是一个不算复杂的模式。虽不复杂，但用好了同样可以解决大问题。个人觉得其最大的好处就在于可以动态地重组针对一类对象的处理流程。正是得益于这一优势，它才可以在纷繁芜杂的业务领域站稳脚跟。 我们遇到的问题是这样...</description></item><item><title>Strategy模式的C实现</title><link>https://tonybai.com/2011/10/20/implement-strategy-pattern-in-c/</link><pubDate>Thu, 20 Oct 2011 00:00:00 +0800</pubDate><guid>https://tonybai.com/2011/10/20/implement-strategy-pattern-in-c/</guid><description>与那些复杂的模式相比，Stragegy Pattern(策略模式)是一个相对简单的模式，很直观，也易于理解。 同时它也是我们在开发过程中使用最多的模式之一。 问题是设计模式使用的驱动力，只有当我们遇到问题时，设计模式才会向我们伸出援助之手。这里我也想通过对问题以及解决方法演化的阐述来说明策略模式是如何更好地帮助我们的。我们从问题出发！ Tony最近接到了一个新任务，任务的内容是实现一个通用的平衡二...</description></item><item><title>Observer模式的C实现</title><link>https://tonybai.com/2011/10/14/implement-observer-pattern-in-c/</link><pubDate>Fri, 14 Oct 2011 00:00:00 +0800</pubDate><guid>https://tonybai.com/2011/10/14/implement-observer-pattern-in-c/</guid><description>设计模式) (Design Pattern，以下简称DP)的定义有很多种。我个人的理解：DP是人们在软件开发过程中所总结出来的一些典型问题的经验解决方法模板。使用它们可以使我们的代码更易被复用，更易扩展，更好地适应变化以及更便于后期维护。 人们都说设计模式是独立于语言的，但这里的&amp;#34;语言&amp;#34;更多的是指面向对象语言，比如Java、C++、C#、Python和Ruby等。使用面向对象语言(OO)在实现设计...</description></item><item><title>经典设计原则背后的本质</title><link>https://tonybai.com/2010/09/17/the-nature-of-some-classical-design-rules/</link><pubDate>Fri, 17 Sep 2010 00:00:00 +0800</pubDate><guid>https://tonybai.com/2010/09/17/the-nature-of-some-classical-design-rules/</guid><description>近一段时间重读了一些经典书籍，诸如《敏捷软件开发：原则、模式与实践》、 《程序员修炼之道》、《Unix编程艺术》等。这些书中关于如何衡量或评价一个类或函数设计好坏的几个原则(Principle)让人印象深刻。《敏捷软件开发》中谈到了SRP、OCP、DIP; 程序员修炼之道则以DRY、“正交性”为话题展开;《Unix编程艺术》围绕紧凑性、SPOT、分离等阐述作者立场。这么多经典原则，如何学习把握？我...</description></item><item><title>一次函数设计讨论</title><link>https://tonybai.com/2010/09/02/an-discussion-on-function-design/</link><pubDate>Thu, 02 Sep 2010 00:00:00 +0800</pubDate><guid>https://tonybai.com/2010/09/02/an-discussion-on-function-design/</guid><description>近期在考虑对底层函数库进行一些重构，今天下午花了两个小时考量现有的函数库的接口设计，发现目前函数库的实现存在着一个普遍的问题：与特定的内存分配实现耦合的太紧。 我们的应用是多进程结构的，并使用了共享内存这种最快捷的IPC机制，鉴于此很多同事在实现一些数据结构或者算法时可能只考虑到了我们常见的应用场景-多进程共享，而对非共享内存分配的情况考虑不足。那如何将目前某些库函数实现与内存分配之间的强耦合解开...</description></item><item><title>iterator的C实现</title><link>https://tonybai.com/2010/01/30/implement-iterator-in-c/</link><pubDate>Sat, 30 Jan 2010 00:00:00 +0800</pubDate><guid>https://tonybai.com/2010/01/30/implement-iterator-in-c/</guid><description>这几天一直处于编码状态，也找回了一些对代码的良好感觉。 昨天晚上闲暇时翻阅“Head First设计模式”，当翻到迭代器模式时，突然有了想法：实现一个iterator。这几天编码时恰好也写了一个简单的带有遍历功能的小数据结构，不妨用iterator改造一下这个数据结构的遍历接口，看是否能成行。 迭代器模式较为简单，网上的文章也多得很，这里就不再贽述了，直接看实现思路和代码吧。 在迭代器模式中，有几...</description></item><item><title>软件业的'图纸'在哪里？</title><link>https://tonybai.com/2008/03/31/where-is-the-drawing-of-software-developing/</link><pubDate>Mon, 31 Mar 2008 00:00:00 +0800</pubDate><guid>https://tonybai.com/2008/03/31/where-is-the-drawing-of-software-developing/</guid><description>上周日和橱柜公司商量好，下午三点到我的房子量尺，橱柜设计师按时到达，拿着一卷尺开始了测量工作。有过装修经历的人都知道：在装修公司进场之前需要橱柜设计师出一份水电改造图，便于装修公司人员确定水电改造的具体方法。装修公司的施工人员与橱柜设计师之间仅需要一份设计图纸就可以完成水电路改造的沟通，这不由得让我想起这样一个问题：&amp;#34;软件开发领域的&amp;#34;图纸&amp;#34;在哪里呢&amp;#34;? &amp;#34;图纸&amp;#34;是建筑行业的标准的共同语言，它能让设...</description></item><item><title>查表法求解'自然数对'问题</title><link>https://tonybai.com/2008/01/29/use-searching-table-to-solve-natural-number-pair-problem/</link><pubDate>Tue, 29 Jan 2008 00:00:00 +0800</pubDate><guid>https://tonybai.com/2008/01/29/use-searching-table-to-solve-natural-number-pair-problem/</guid><description>‘自然数对’是这样的一对自然数，他们的和与差的结果都是平方数，比如：自然数对32和68，根据定义32+68 = 100 = 10^2，68-32 = 36 = 6^2。现在的题目是：根据输入的两个100以内的自然数，打印出这两个整数之间的所有自然数对。 这道题不难，而且限制了范围，在两个100以内的自然数区间，很多人马上就能给出程序。这道题的有两个点需要思考：一个是关于平方数的判断；另一个就是两个...</description></item><item><title>三角形输出问题考量</title><link>https://tonybai.com/2008/01/27/solve-triangle-print-problem/</link><pubDate>Sun, 27 Jan 2008 00:00:00 +0800</pubDate><guid>https://tonybai.com/2008/01/27/solve-triangle-print-problem/</guid><description>相信很多人在初学某门计算机语言的时候都会做过类似的题目：在控制台上输出用特定字符&amp;#39;拼&amp;#39;出来的某种图形，比如下面的这种三角形：     \*    \*\*\*   \*\*\*\*\*  \*\*\*\*\*\*\* \*\*\*\*\*\*\*\*\* 这样的问题应该算是入门级的了，大多人都是看之，做之，忘之，而今天我就拿这种入门级的题目说事，小问题里也许内含有大道理。 昨晚无意中在编程爱好者论...</description></item><item><title>软件抽象</title><link>https://tonybai.com/2005/11/21/software-abstraction/</link><pubDate>Mon, 21 Nov 2005 00:00:00 +0800</pubDate><guid>https://tonybai.com/2005/11/21/software-abstraction/</guid><description>不知道“软件抽象”这个标题能否恰好表达出我想表达出的意思，暂且就起这个名字吧。随着工作经验的增加，对软件开发所涉及的技术知识体系的理解也渐渐地清晰（起码自己是这么感觉的^\_^），思考了若干时间后，拿出来给自己一个和大家交流的机会。 1、起源 这个想法起源于一次项目方案讨论例会，会上我们的项目遇到了“存储资源瓶颈”，遂有同事提出一个类似“数据中心”的方案，但考虑到部门目前没有相关经验和数据供参考，...</description></item><item><title>tony说设计-实践后的体会</title><link>https://tonybai.com/2005/11/16/experience-after-some-design-practice/</link><pubDate>Wed, 16 Nov 2005 00:00:00 +0800</pubDate><guid>https://tonybai.com/2005/11/16/experience-after-some-design-practice/</guid><description>入司后连续做过几个项目。最近在做一个新的项目的设计的时候，突然想到是不是该把以前项目中一些好的设计想法应用到新的项目中，并且尽量减少在新的项目中遗留以前的不好的设计呢？那么以前的项目中哪些是值得我去借鉴，哪些又是应该去避免的呢？真的很遗憾，自己并没有系统的反思和总结过，这就是我写下这篇Blog的直接起因。 一直在Unix平台下做设计和开发，所以下面谈的内容可能都有些局限性。作为设计原则本身，某些可...</description></item><item><title>开放与封闭</title><link>https://tonybai.com/2005/01/09/open-and-close/</link><pubDate>Sun, 09 Jan 2005 00:00:00 +0800</pubDate><guid>https://tonybai.com/2005/01/09/open-and-close/</guid><description>敏捷设计最基本原则：“开放封闭原则（OCP，Open-Close Principle）” \* 回顾SRP 在开始谈OCP之前，我们还是简单回顾一下Bob大叔在其书中所论述的敏捷设计的第一个原则“单一职责原则（SRP，Single Responsibility Principle）”。 Bob大叔在其书中将职责理解为“变化的原因”。一般当需求变化时，该变化就会反映为类的职责的变化。按书中所述“如果...</description></item></channel></rss>