【Grasshopper基础12】打造自定义可复用的有按钮电池外观模版

作者：“咕咕咕？下一篇马上就写好了”

上一篇【基础11】向大家介绍了怎么在Grasshopper里制作自己的带有按钮的电池外观。从反馈来看，挺多读者对这个例子十分感兴趣，同时也私信联系到我问了一些更详细的需求细节。其中一位“风起云淡”网友提到了下面的问题：

“如果这个自定义属性类是单独写的一个类，想要这个自定义属性类写成通用的是否可以？”
“我在构造函数里面传入的IGH_ComponentOwner接口，但是到了在GH_Attribute里面的文字渲染（重写Render方法）的时候，没有办法拿到传入那个枚举类型的“工作模式转文字”输出渲染了。”

这个问题挺有意思的，简单聊了几句之后，发现其实这个需求十分的实际，也是一个十分好的从实际需求出发的一个讲解C#这门语言本身的精髓的一个案例：

有10个自定义电池，每个电池都想要一个按钮，但是这每个按钮上面的文字内容、按下去之后的响应却都需要不一样。

哼哼，这还不简单，脑门一拍方案就出来了：参照上一篇 【基础11】，每个电池重写Render方法，代码Ctrl+C、Ctrl+V之后仅需稍加修改，对于点击事件分别实现；只要给我钛金Ctrl/C/V键，别说10个电池，100个电池又如何？

嗯，似乎没毛病。

但是，

一个月后，你学到了一个新的超级酷炫无敌X炸天的Graphic库，用它来渲染按钮帅的一B，现在想要把这100个电池的按钮样式都换了

原地升天。

又要Ctrl+C、Ctrl+V辛苦劳作一整天？不不不，这其实就需要我们将代码的思维再拔高一个层面，我们这次要写的不是某一个类了，我们这次来写“一类”类，也就是所谓的“框架”。

为什么写框架

写框架 = 复用。

毫无疑问的，如果某个类只会用到一次，那是没必要写框架的。就比如这按钮电池外观这个例子，如果就写这一个带按钮的电池外观类，那么框架带来额外代码工作量是不划算的。但是但凡第二次开始写与这个类差不多功能的类的时候，框架的优势就开始体现了。

计算机业内有句话：

“第一次写某个功能，请直接实现，第二次写这个功能，也请直接实现，但记住它，第三次写这个功能，写一套可复用的函数，并以后一直改进它”。

框架就是这“一系列可复用的函数”。

框架的思想

其实整个代码思想都是围绕着“复用”这个概念来的。无论是前一段时间很火的“面向对象编程”，还是“面向过程编程”，最终的思路都是少写点代码。为了少写点代码，我们就需要：

观察需求中 重复 的部分

把重复的部分具体化，包含在框架里，把不同的部分抽象化，暴露在框架外。

这里提到了两个词，“具体化”和“抽象化”。简单地理解，“具体化”就是把代码写死，固定住，这代表着框架中固定不变的部分。“抽象化”就是把代码留给框架的使用者来写，仅仅规定“要写什么”，而不规定“具体写的是什么”。具体化很好理解，抽象化却是有点抽象，我们接下来细细展开。

以我们的本文最初的核心，“打造自定义可复用电池外观模版”，为例：模版不变的部分就是“外观上需要一个按钮”，模版变化的部分就是“按钮上的文字”和“按钮按下后的触发方法”；写一个简单模版。

一个简单的可复用电池外观模版

首先分析需求：

• 我们的模版肯定是一个类，这个类还得能够被Grasshopper本身认识。
• 通过使用这个模版，我们以后不想每次都需要粘贴Render方法里的代码。
• 通过使用这个模版，我们需要能够对不同的电池实现不同的按钮文字和事件。

Simple and easy.

直接使用C#中的抽象类来完成这个使命：
我们定义一个抽象类，将 Render 方法“具体化”地写死，但留下一个 string 属性和一个用来触发按钮的方法作为抽象化，只有具体再继承的时候，才需要写具体的实现。假设我们的模板类名字取为“MyCompAttrTemplate”