vba代码创建步骤_通过三个简单的步骤创建高度可配置的代码

vba代码创建步骤

制冷乱码 (REFACTORING MESSY CODE)

It’s honestly not very difficult to write great, configurable classes. But, it might be if you’ve grown used to doing things in certain ways.

老实说，编写出色的可配置类并不是很困难。 但是，可能是您已经习惯于以某些方式做事。

From my experience, the best way to turn an existing class into a configurable one is first to move logic into separate classes and then the moving hardcoded part into constructor or method arguments.

根据我的经验，将现有类转变为可配置类的最好方法是，首先将逻辑移到单独的类中，然后将硬编码部分移到构造函数或方法参数中。

It’s that easy. Let me show you how.

就这么简单。 让我告诉你怎么做。

但是首先，可配置类的优点是什么？ (But first, what’s so great about a configurable class?)

Before you spend any time refactoring your existing classes into configurable ones, I’ll let you know why it’s so great.

在您花任何时间将现有的类重构为可配置的类之前，我将让您知道它为什么这么好。

A configurable class is damn easy to use. It’s extensible. It doesn’t do too much. It’s stupid simple, which is awesome.

可配置的类非常容易使用。 它是可扩展的。 它并没有做太多。 这很愚蠢，太棒了。

The biggest selling point, it’s easy to test.

最大的卖点是易于测试。

上课 (Meet the classes)

For good measure, here’s a quick overview of the classes you’re dealing with.

为了很好的衡量，这是您正在处理的类的快速概述。

You have an OrderProcessor class with a single method ProcessOrder(Order).

您有一个具有单个方法ProcessOrder(Order)的OrderProcessor类。

Next, there’s a base class Order and three subclasses VirtualOrder, ServiceOrder, ShippingOrder.

接下来，有一个基类Order和三个子类VirtualOrder ， ServiceOrder ， ShippingOrder 。

Understanding the Order classes is completely irrelevant. Don’t get distracted by thinking of how they’re implemented. If you really must know, they just have two properties, ‘Name’ and ‘Price’… Okay, let’s carry on.

了解Order类是完全不相关的。 不要因为思考如何实现而分心。 如果您真的必须知道，它们只有两个属性，即“名称”和“价格” ...好的，让我们继续。

You’ve implemented the order processor the following way.

您已经通过以下方式实现了订单处理器。

Messy if-else based method

基于凌乱的if-else方法

It took 1 minute to implement. It works. You’re happy. Your manager is happy. Your customer is happy.

实施花费了1分钟。 有用。 你很高兴。 您的经理很高兴。 您的客户很高兴。

But it’s a mess.

但这是一团糟。

This could be a switch. But if that’s your first thought, you’re focusing on entirely irrelevant aspects of software development.

这可能是一个开关。 但是，如果这是您的第一个想法，那么您将专注于与软件开发完全无关的方面。

让我告诉你如何使它变得更好 (Let me show you how to make this better)

Better is of course subjective. If you’re certain (you’re not) this class will never change (it will), this might be a great implementation (it’s not).

更好当然是主观的。 如果确定(不是)，则该类将永远不会更改(它将)，这可能是一个很好的实现(不是)。

You and I are refactoring this hot mess into a sensible, configurable class — without much effort whatsoever.

您和我都将这个混乱的地方重构为一个明智的，可配置的类，而无需付出任何努力。

We’ll make this class better regarding three internal software qualities.

关于三种内部软件质量，我们将使该课程更好。

Readability. Currently, this class’ method reads terribly. I got an easy fix up my sleeve for this.

可读性。 当前，此类的方法读起来非常糟糕。 为此，我轻松解决了问题。

Maintainability. If you need to modify the processing of a ‘ServiceOrder’, you’ll do so at a place surrounded by unrelated code. Also, if other developers are working on the same class, you probably get merge conflicts. Annoying and potentially introducing unexpected bugs.

可维护性。 如果您需要修改“ ServiceOrder”的处理，请在不相关代码包围的地方进行。 另外，如果其他开发人员正在同一个类上工作，则可能会发生合并冲突。 烦人并可能引入意外的错误。

Flexibility. Adding a new order? You’ll have to add an extra else-if. I’m sure you already know that’s bad, and a clear violation of Open/Closed.

灵活性。 正在添加新订单？ 您必须添加一个额外的else-if 。 我确定您已经知道这很糟糕，并且明显违反了Open / Closed。

1通过将IF转换为地图来提高可读性 (1 Improving readability by turning IFs into maps)

It usually takes a few iterations to refactor a messy class. First, we’re improving the readability. It’s difficult to achieve a highly maintainable and flexible class if it’s unreadable.

重构杂乱的类通常需要几次迭代。 首先，我们正在提高可读性。 如果难以理解，则很难实现高度可维护和灵活的类。

Entirely getting rid of if-else is a great first step.

完全摆脱if-else是一个伟大的第一步。

Refactored into an incredibly readable class

重构为难以置信的类

The ProcessOrder(Order) method just got immensely easier to read, and is now doing only one, single job.

ProcessOrder(Order)方法变得非常容易阅读，现在仅执行一项工作。

If you’re not familiar with Action<T>, it’s just a lambda taking an argument, or, anonymous function if you’d like.

如果您不熟悉Action<T> ，那么它只是一个带参数的lambda，或者是您愿意的匿名函数。

We’ve taken the nasty if-else and made it into a dictionary instead.

我们已经把讨厌的if-else改成字典了。

Also, notice the added benefit in regards to the property OrderTypes. If a new order type comes along, we don’t need to manually add it in two places.

另外，请注意与属性OrderTypes有关的附加好处。 如果出现了新的订单类型，则无需在两个地方手动添加。

2创建单独的类可提高可维护性 (2 Creating separate classes improves maintainability)

We could easily stop at this point and call it a day. You’ve already made the class so much simpler. But you haven’t exactly reached ‘stupid simple’ yet. That’s our end goal.

我们可以轻松地停下来，称之为一天。 您已经使课程简化了很多。 但是您还没有完全达到“愚蠢的简单”状态。 那是我们的最终目标。

Currently, with our first refactoring iteration, our class still knows too much about how each type is processed.

当前，在我们的第一次重构迭代中，我们的类仍然对每种类型的处理方式了解得太多。

In this case, achieving maintainability is about refactoring the action implementations out of the processor class and into their own classes.

在这种情况下，实现可维护性就是将操作实现重构为处理器类以外的类。

How the actions are split into separate classes

如何将动作分成单独的类

In code, this looks like the following — notice the new IOrderProcessing interface. Each lambda action from the dictionary is now its own, separate class.

在代码中，如下所示—注意新的IOrderProcessing接口。 现在，字典中的每个lambda动作都是其自己的单独类。

Interface and separate processing classes

接口和单独的处理类

This incredibly simple refactoring allows us to granularly test each processing. We no longer need to ‘new’ up the whole OrderProcessor just to see if e.g. a virtual order is processed correctly.

这种难以置信的简单重构使我们能够对每个处理进行粒度测试。 我们不再需要“重新”整个OrderProcessor只是查看例如虚拟订单是否被正确处理。

Your order processor is starting to look really stupid. Just how we like it.

您的订单处理程序开始显得非常愚蠢。 就是我们喜欢的方式。

Refactoring to a highly maintainable class

重构为高度可维护的类

3一次最终重构，以实现最大的灵活性 (3 One final refactoring for maximum flexibility)

Sure, unit testing is easy at this point. But, you’d still be required to test the ProcessOrder(Order) method three times, just to make sure it’s working properly. Even worse, this is not obvious. You’d need to be aware of the inner workings to know this.

当然，在这一点上单元测试很容易。 但是，仍然需要三遍测试ProcessOrder(Order)方法，以确保其正常运行。 更糟糕的是，这并不明显。 您需要了解内部工作原理才能知道这一点。

For every new order type, you’d need to test the same method with an additional case. This is surely a code smell.

对于每种新的订单类型，您需要在其他情况下测试相同的方法。 这肯定是代码的味道。

Your last refactoring is going to make the processor class amazingly simple. You simply turn the dictionary instantiation into an explicit dependency.

您上一次的重构将使处理器类非常简单。 您只需将字典实例化为显式依赖项即可。

Refactoring to a very simple class

重构为非常简单的类

So light. So easy. So simple to test.

好轻 太简单。 测试非常简单。

When your code suddenly becomes stupidly simple, you know you’ve hit the right level of abstraction. This is one of those times. Congrats.

当您的代码突然变得非常简单时，您就知道达到了正确的抽象水平。 这是那些时代之一。 恭喜。

重构更多类 (Refactoring to more classes)

Computer science majors may shriek in horror as each new class is added, calling out potential performance issues (which never manifests).

随着每个新班级的加入，计算机科学专业的学生可能会惊恐地尖叫，指出潜在的性能问题(从未表现出来)。

Well, there’s a trade-off to everything. Nicely composed code requires more components as opposed to an entangled, unreadable, lightning-fast mess. Pick your poison.

好吧，一切都需要权衡。 精心编写的代码需要更多的组件，而不是纠结，难以理解的闪电般的混乱。 选择你的毒药。

But, again, for good measure, I did a simple performance test. 1 million iterations of instantiating the non-refactored class vs the flexible class, calling the process order method for each order type.

但是，再说一次，我做了一个简单的性能测试。 实例化非重构类与灵活类的一百万次迭代，为每种订单类型调用流程订购方法。

Performance table of doing 1 million instantiations and method class

执行一百万个实例的性能表和方法类

You decide yourself how terrible those numbers are.

您决定自己这些数字有多可怕。

Resources for the curious
-------------------------Making Your C# Code More Object Oriented by Zoran HorvatClean Code Principles in C# by Cory HouseCode Complete 2 by Steve McConnell

Nicklas Millard is a software development engineer in one of the fastest-growing banks, building mission-critical financial services infrastructure.

Nicklas Millard是发展最快的银行之一的软件开发工程师，负责构建关键任务金融服务基础架构。

Previously, he was a Big4 Senior Tech Consultant developing software for commercial clients and government institutions.

在此之前，他是Big4高级技术顾问，为商业客户和政府机构开发软件。

Connect on LinkedIn

在 LinkedIn上 连接

翻译自: https://medium.com/swlh/creating-configurable-classes-that-are-easy-to-use-69d78d6881a2

vba代码创建步骤