基于反射的插件架构.docxVIP

基于反射的插件架构实际上并没有被归类为一种模式，因为它实际上不是一个模板，而是一系列组合在一起形成程序架构的概念。 接口要求所有的实现类声明定义在接口中的所有方法。对于严格的系统来说，这是理想的.但是在规模更大更复杂的系统中，两个交互的项本身也是交杂程序的情况下，这可能会导致程序发生故障， 反射APl的插件方法是基于在运行时决定程序逻辑的功能来实现的.也就是说.它允许创建可选的接口方法 .并且在首次使用时检测到这些接口方法。只有在插件中存在这些方法的情况下.它门才会被用到。否则，它们就会被忽略。这有助于避免实现复杂的接口，从而支持史灵活的定制情况‘ Interface Iplugin{ Function getMenuItems(); Function getArticles(); Function getSideBars();}Class SomePlugin implements Iplugin{ Public function getMenuItems(){ Return null;}Public function getArticles(){Return null}Public function getSideBars(){Return array(‘SideBarItem’);}} 这种情况井不太合理，因为为了满足接口的要求，为大量方祛添加了不会用到的函数体。如果在APl中有数百个方法，这肯定是行不通的。 现在你也许想到你可以将每个方法拆分到它自己的接口中，但同样的问题也会发生。会出现一个实现了数百个接口的类，还会出现数百个接口的声明，这同样不太现实。 一些语言是事件驱动的.它们提供了委托方法，可以从宿主应用程序中接收到事件，但PHP没有内置的委托支待。所以，很多框架都定义了复杂的一套钩子函数，它们要求插件在某些形式的初始化过程中注册插件自身的能力。这种初始化过程和注册API吏得创建插件的工作更加困难，所以开发的插件数量很少。 反射.4P1哭供了一种解决方案。在这一方案中:可以get_declared_classes()函数获取所有当前加载的类，并检测哪个类实现了一个单方法的IPlugin“标记”接口‘这个接口与整个API相比要简单得多，但是它会包含一个getName()函数，所有插件都必须包含这个函数。 作为示例，我们将演示如何以基于插件的系统的方式创建一个非常基本的Web页面。页面包含菜单、侧边栏和文章。通过反射，应用程序将检测到每个插件支持的特性，并且只有在这个特性存在时才会执行相应的方法。这个例子非常简单，不是作为一个整体的应用程序来设计的.但它演示了使用反射来加载插件的方法。首先，我们需要创建一个所有插件都必须遵循的接口，名为IpluginInterface Iplugin{ Public static function getName();} 这个接口很简单。它仅仅定义了一个要求所有插件都必须实现的方法口 下-步，我们需要创建一个子程序去检测所有当前已包含的插件。要实现这一点，只需要使用get_declared_classes()函数和ReflectiononClass类，如代码清单所示。使用反射查找插件Function findPlugins(){ $plugins =array(); Foreach(get_declared_classes() as $class){ $reflectionClass = new ReflectionClass($class); If($reflectionClass-implementsInterface(‘IPlugin’)){ $plugins[]=$reflectionclass;}} Return $plugins;} 代码使用了ReflectionClass类的implementsInterface()方法来检测某个类是否实现了IPlugin接口。这个方法的作用正如其名称所表示的那样，它检查类是否实现了某个接口。与instanceof操作符不同的是，这个方法并不需要操作类的实例，因此更高效: 应该注意到，这段代码保存了ReflectionClass的实例.而不是类的实例或者作为字符串的名称。这是因为创建反射类会有一些开销，在稍后调用捅件的方法之前要检查插件是否具有特定的属性。所以需要现在就将它保存起来，这样就不用执行两次实例化工作了。 找到插件后，还需要创建一种机制去检测插件提供的应用程序功能的子集。例如，包含菜单项的插件将会定义一个为法，用来向菜单添加菜单项，而侧边栏插件没有这个方法。为了确定某类是否实现了某个方法.可以使用ReflectionClass类的hasMethod ()方法口Function computeMenu(){ $menu =