网站运营与管理规划书,龙岩市兼职网,wordpress前台很慢,用dw设计最简单的网页编辑寄语 当我让 MSDN 杂志高级特约编辑 James McCaffrey 审阅本文的初稿时#xff0c;他为本文作者提出的一些观点和想法所震怒#xff0c;愤愤然地离开了。大多数时候#xff0c;这预示着文稿不通过。但 McCaffrey 指出#xff0c;软件工程中的新概念遭到摒弃再常见不过他为本文作者提出的一些观点和想法所震怒愤愤然地离开了。大多数时候这预示着文稿不通过。但 McCaffrey 指出软件工程中的新概念遭到摒弃再常见不过这完全是因为之前从未有人提出过。虽然 McCaffrey 声称自己仍为本文中的诸多观点而震怒但我们都认为这篇文章可能会引发很多有关软件设计和方法范例的思考。- Michael Desmond 只要有软件就会有失败的软件。研究显示所有项目中有 25% 完全失败有 50% 可以说是“有缺陷”。 试想想如果汽车制造商也有相同的统计数据那就是有 25% 的汽车无法启动或在开灯时爆炸有 50% 的汽车仅能达到 25 英里每小时或每英里使用 15 加仑的汽油。更重要的是如果客户在付款前并不知道哪款汽车适合自己情况又如何这与当前的软件开发现状颇为相似。 已提出各种解决方案来改善这种状况但均未涉及代码这一根本原因 我认为软件项目失败通常可以归因为同一问题混乱不堪的代码。代码之所以如此糟糕是因为确实没有办法适应变更。正因为此我们建议采用极限编程和敏捷软件开发等方法。不过这些方法其实都无法帮助创建更好的代码。敏捷软件开发并不能神奇地帮助避免混乱不堪的代码。必须能够通过原子构建基块单独处理问题才能变得敏捷。 本文介绍的设计模式并不能替代敏捷软件开发或其他类似方法。毕竟敏捷软件开发是一种管理框架而不是体系结构设计模式。相反我提出的设计方法可以让你更轻松地变得敏捷因为你可以适应变更。在过去几年里我开发出了一种设计模式我将其称为“有效事件”。 借助这种设计模式可以创建可重用的小型组件从而能够轻松扩展、修改、重用这些组件并将其与其他部件进行交换。这种设计模式带来了不同的软件视角让你可以“安排”代码几乎就像是各块乐高积木。你可能会认为这与使用面向对象的编程 (OOP) 范例编写代码颇为相似。然而有效事件与传统 OOP 有很大区别。 检查你自己的代码 帮个忙呗 打开你在 Visual Studio 中生成的最后一个解决方案然后检查依赖项关系图。可以从你的解决方案中提取多少项目和类 可以在未来项目中重用多少类 在不破坏软件的前提下可以将多少类替换成其他类 我猜你的项目和类依赖项与其他大多数项目一样。你项目的依赖项关系图很有可能混乱不堪。非常抱歉我可能太过坦诚而忽略大家的感受但这确是我的经验之谈。但请放心不只你一个人遇到这种问题。虽然没有确凿的数据但我可以说世界上 98% 的代码都存在同样的问题。此外我不会强迫大家去面对这个问题除非我有解决方案。 如果可以理清这些依赖项并创建可重用的组件这样代码的各个部分就都不会引用其他任何部分那么你的编程质量将会大大提高。如果你的项目和类不像现在这样混乱就可以更容易地交换各个部分了。如果理清了你的类便可以在未来项目中重用它们。如果你的项目最大限度地减少了依赖项那么你将拥有一组更有可能重用的组件而不是一个庞然大物。有效事件可推进跨类和项目不使用依赖项。若要解决软件混乱不堪的问题零依赖项是唯一可接受的数字 有效事件的工作原理是什么 有效事件设计模式实际上极其易于理解。与其创建接口来分隔逻辑块的实现和使用者不如直接使用属性来标记方法。例如 [ActiveEvent (Name “foo.bar”)]protected static void foo_bar(ApplicationContext context, ActiveEventArgs e)
{var input e.Args[“input”].Value as string;e.Args.Add(“output”, “Hello there ” var);
} 此语法取自 Phosphorus Five这是我创建的一个开放源代码有效事件实现。有关详细信息请参阅“几乎不存在的软件”。 若要调用已定义的方法使用有效事件范例同样十分简单。通过有效事件名称间接调用方法而不是直接调用 /* ... some method in another assembly ... */var args new Node ();
args.Add (input, John Doe);/* context is your ApplicationContext instance, which keeps track of your Active Events */var result context.Raise (foo.bar, args)[output].Value as string; 引发调用调用的是 foo.bar 有效事件。请注意在有效事件调用及其实现之间没有依赖项。此外它们之间没有共用的公共类。只有数据在事件中传入和传出。此外还请注意所有有效事件的签名都完全相同。因此类、接口和方法略微转向幕后并且在源代码中的受重视程度降低。 有效事件组件的加载完全是一个动态过程可以通过应用程序配置文件中引用的程序集列表完成也可以通过从文件夹自动加载所有 DLL然后将其注册为有效事件处理程序来完成。在内部有效事件“内核”会在加载期间遍历 DLL 中的所有类型并对有效事件方法的 MethodInfo 引用存储到字符串/MethodInfo 字典中。稍后会在调用事件时使用此字典。若要限定有效事件的范围或将其与状态相关联可以动态添加类实例作为有效事件侦听器并使用实例方法而不是静态方法作为有效事件接收器这便是举例来说Phosphorus Five 中的 plugins/p5.web 项目完成的工作。 这会创建一个环境其中不同的代码部分都是简单的构建基块彼此间接调用以便你可以轻松地将任意一个有效事件程序集与另一个实现进行交换。彻底更改生成的应用程序就像更改配置设置或替换 DLL 一样简单。如果愿意就像将字符串“foo.bar”更改为“foo.bar-2”一样简单。 同时解决方案中的每个程序集仍能调用其他程序集中的方法而不需要像普通旧数据 (POD) 结构一样与另一方进行共享。基本上来说有固定的“另一抽象层”可供任意使用。换言之组件已原子化。 让我们将此与需要在传统 OOP 中执行的操作进行比较。首先假设使用的是按接口设计方法且有一个接口和至少一个接口实现。可能需要使用抽象工厂方案来创建对象具体视应用场景而定。因此需要创建两个类和一个接口很容易就总共有 30 行以上代码。此外若要根据实现创建真正的插件最终会为使用者部分生成一个项目使用插件并为实现部分生成一个项目实现接口的含类项目。若要采用完全模块化的方法可以使用第三个项目来包含接口和可能的抽象工厂。然后查看结果时你会发现最终在三个项目中生成了至少三个交叉组件引用。此外只有修改所有三个项目才能添加或更改接口的输入或输出部件。将这与有效事件示例生成的单行解决方案相比后者根本就没有引用向它提供任何输入或输出自变量都不要紧。传统方法的代码行可能有两倍之多或更多根据我的经验会生成更复杂的依赖项关系图、更严格的结果和更复杂的代码。 OOP 不是 OO 我喜欢 OOP。那是一个极好的范例可方便你轻松封装代码逻辑、方法和数据。不过也有人指出OOP 没有完全解决所有编码问题。在某些情况下使用 OOP 时必须定义多个类这些类通常会紧密耦合并创建依赖项。 在 OOP 中需要知道方法的签名需要拥有对接口的访问权限也需要知道如何创建此接口的实例。此外通常还需要在接口的使用者部分和实现部分之间共享类型。这将在构建基块中创建依赖项。使用 OOP仅仅为了创建一个简单的“Hello World”插件而需要创建多个类再常见不过。如果更改 OOP 接口除非你是很认真地设计接口否则可能需要重新编译多个程序集。最终可能会有许多抽象接口和样本代码或者不得不接受以下事实更改接口有可能引起多米诺效应需要额外更改大量代码。只要某事物变得过于复杂或需要完成大量繁琐重复的工作你的直觉应该就会认为这是不对的。 问问自己下面这个问题 “如果 OOP 允许创建面向对象的 (OO) 软件为什么还很难成功地使用它” 在我看来OOP 并不等同于 OO。如果等同就不需要为了充分利用它而了解这么多的设计模式。 按照目前的做法我认为 OOP 存在一些根本性的限制为了充分利用 OOP 而需要了解所有这些设计模式就是体系结构存在以下更为基本的问题的症状无法交付 OO 软件。有效事件可以解决这些问题不是通过实现更好的抽象工厂或新的类构造而是通过更改方法和函数的调用方式完全剔除 OOP。若要创建 OO 软件需要的不是实例化抽象类和接口的新方法而是不同的功能调用机制以及调用的每个接口方法能否共用一个签名。 几乎不存在的软件 有关展示了有效事件广泛应用范围的示例请查看 Phosphorus Five (github.com/polterguy/phosphorusfive)。Phosphorus Five 是一个大型软件项目而有效事件实现仅用了 1.000 行代码。有关有效事件实现可以访问 core/p5.core。 在这个项目中我创造了新的编程语言 Hyperlambda用于创建有效事件挂钩。这样一来我就可以根据需要更改 for-each 和 while 语句的实现。我还可以将 else 语句扩展为在另一台服务器上执行。我可以将编程语言轻松扩展为创建我自己的域特定关键字以执行解决任何域问题所需的操作。 我还创造了一种文件格式用于以一段文字的形式动态声明节点结构并将其存储到我的磁盘或我的数据库。此外我还创造了自己的表达式语法用于引用树任何部分内的任意节点。这样就生成了非编程语言我喜欢这样称呼完全是图灵完备语言。我的非编程语言既不用动态解释也不用静态编译有时只需五行代码就能完成其他编程语言要用数百行代码才能完成的操作。 借助有效事件、Hyperlambda 和托管的 AJAX 库仅包含一个 AJAX 小组件在未引入“Web OS”等名称的情况下我成功创造了一些自己不知道如何称呼的事物。 Phosphorus Five 中大约有 30 个项目不同的插件中没有任何引用。所有项目都只引用有效事件实现 p5.core 和表达式引擎 p5.exp。就是这样。核心文件夹中的主要网站项目 p5.website 只包含一个简单的容器小组件几乎不含逻辑。应用程序启动期间所有插件均在我的 Global.asax 中动态加载。尽管如此所有项目都能动态调用其他项目内的功能。既没有引用、没有依赖项也没有出现任何问题 回归基本 解决方案总是蕴含在问题之中。自相矛盾的是OOP 旨在解决的一些问题全局函数和数据反而成为 OOP 无意间引发的问题的解决方案。如果你看看有效事件这种设计模式首先会发现的是在某种程度上它是回归基本的同时使用全局函数取代方法和类。然而由于无需在有效事件的使用者和实现之间知道并共享签名或类型因此与使用 OOP 相比环境更像是黑盒。这样一来可以轻松地进行交换例如将 SaveToDatabase 与 InvokeWebService 或 SaveToFile 进行交换。没有接口、类型、POD 结构和类只有一个共用签名。只有优质的普通旧数据。数据只会传入传出 实现多形性和更改字符串一样简单。下面的示例展示了如何使用有效事件实现多形性 string myEvent some-active-event;if (usePolymorphism) {myEvent some-other-active-event;
}
context.Raise (myEvent); 我意识到经验丰富的构架师一定会认为这种多形性构造幼稚可笑且简单粗糙。然而这种简单性正是它奏效的原因所在。借助有效事件可以从数据库、配置文件或通过用户在窗体文本框中提供名称来提取方法或函数的名称。可以将此看作是不需要显式类的多形性变体。这是不含类型的多形性。这是在运行时期间动态确定的多形性。通过剔除所有关于多形性的传统观念并重构多形性的实质内容最终会生成实际有效的多形性封装和多形性而不含类、类型、接口或设计模式。链接有效事件就像原子结合成分子一样简单。这就是敏捷软件 唯一需要的图类型 Node.cs 使用有效事件将在有效事件中仅传入传出数。这样一来可以松散耦合组件。为此需要使用一个数据类这也是在使用有效事件范例时唯一需要的一个图类型。类需要能够封装所有可能类中的全部可能字段和属性。在 Phosphorus Five 中此类名为 Node.cs就是包含键/值/子设计的图对象。 成功实现有效事件的关键是节点类是允许有效事件作为输入接收并作为输出返回的唯一自变量。事情就是这么凑巧几乎所有类都可以有效地缩减成键/值/子图 POD 对象。与有效事件程序集的动态加载相结合这可以大大减少项目之间的依赖项数。 若要实现 Node.cs必须能够保留键或名称、可以是任意对象的值和节点的“子”集合。如果节点类符合这些约束可以将几乎所有可能的对象轻松转换成节点实例。对于熟悉 JSON 或 XML 的人来说这一点的相似性可能就非常明显。下面的简化伪代码展示了节点类结构 class Node
{public string Name;public object Value;public ListNode Children;
} 在内部可以在组件内根据需要使用尽可能多的 OOP。然而当一个组件需要调用另一个组件中的逻辑时必须以某种方式将所有输入数据都转换成节点实例。从有效事件返回信息时也需要完成同样的操作。不过在组件内可以根据需要使用任意类、接口、抽象工厂、外观组件、单一实例和设计模式。而外部只有节点并且有效事件是组件之间的桥梁。将有效事件看作是协议将节点看作是它的数据如果这样有助于你在脑海中勾勒两者之间的关系的话。 总结 虽然旨在取代当今世界上的其他大多数设计模式但有效事件并不是灵丹妙药。除其他事项外这项技术还会带来一定开销。例如需要进行字典查找而不是直接调用方法。此外方法还使用一些反射。这些间接方法调用可能是多个数量级的相比传统的虚拟方法调用更加昂贵。此外只要与其他组件有接口就需要将对象转换成节点和数据。 然而有效事件不应替代你的所有工作。我们的想法是在组件之间提供更好的接口。鉴于此性能开销就不是主要问题。如果实际实现需要 5,000,000 个 CPU 周期那么不论是需要 5 个 CPU 周期还是需要 500 个 CPU 周期才能调用 SaveToDatabase 方法都是风马牛不相及 Donald Knuth 曾经说过“过早的优化是万恶之源。” 每当考虑编写接口时应该问问自己改为创建有效事件是否会更好。积累了一些有效事件经验后你对这个问题的回答往往是“可能会”。 借助有效事件大多数时候接口和抽象类的受重视程度降低。 我知道这听起来像是荒谬大胆的立场但看看“几乎不存在的软件”中介绍的 Phosphorus Five 项目。 在 Hyperlambda我为有效事件创造的“语言”中对象可以是文件、文件夹、lambda 回叫、图节点树的子部分、取自数据库的一段文字或通过 HTTP 发送的一段数据。所有对象都可以执行就像是计算机可理解的执行树。在 Hyperlambda 中理论上可以执行数字 42。 我第一次想到有效事件是在七年多前直觉告诉我有效事件有一种内在的美。问题在于有效事件挑战了 60 年来的传统编程智慧。有效事件甚至成为必须重构最佳做法的促使因素。我花了七年时间才忘掉以前所学跟着自己的直觉走。有效事件存在的最大问题实际上并不是它的实现而是在于你的想法。事实上我完全重构了 Phosphorus Five 五次这就证明了这一点。 在本文的初稿中我创造了几十个类比。通过关联物理和生物等其他学科的既有知识我试图让大家相信有效事件的优势。在第二份草稿中我试图激怒大家。我的想法是刺激你来证明我是不对的这样你就会来找我立场的缺陷当然你是发现不了任何缺陷的。然而在我的第三份也是最后一份草稿中我决定直接介绍有效事件。如果你顺着思路走下去那么有效事件将是成为你唯一需要学习的设计模式。 Thomas Hansen 自 8 岁起便一直在开发软件他于 1982 年就开始使用 Oric-1 计算机编写代码。编写的代码偶尔确实是利大于弊。他对 Web、Ajax、敏捷方法和软件体系结构充满热情。 衷心感谢以下 Microsoft 技术专家对本文的审阅 James McCaffrey 原文地址https://msdn.microsoft.com/en-us/magazine/mt795187 .NET社区新闻深度好文微信中搜索dotNET跨平台或扫描二维码关注
