Inside ObjectBuilder Part 2

<iframe align="top" marginwidth="0" marginheight="0" src="http://www.zealware.com/46860.html" frameborder="0" width="468" scrolling="no" height="60"></iframe>

Object Builder Application Block
/黃忠成
2006/9/21

三、ObjectBuilder Application Block
ObjectBuilder一開始出現於Microsoft所提出的Composite UI Application Block,主司物件的建立及釋放工作,她實現了本文前面所提及的Dependency Injection概念,同時在架構上提供了高度的延展性。運用ObjectBuilder來建立物件,設計師可以透過程式或組態檔,對物件建立與釋放的流程進行細部的調整,例如改變物件建立時所呼叫的Constructor(建構子),調整傳入的參數,於物件建立後呼叫特定函式等等。鑑於ObjectBuilder的功能逐漸完整,加上社群對於Dependency Injection實作體的強烈需求,Microsoft正式將ObjectBuilder納入Enterprise Library 2006中,並修改CachingLoggerSecurityData AccessApplication Block的底層,令其於ObjectBuilder整合,以此增加這些Application Block的延展性。就官方文件的說明,ObjectBuilder Application Block提供以下的功能。
1
l 允許要求一個抽象物件或介面,ObjectBuilder會依據程式或組態檔的設定,傳回一個實體物件。
l 回傳一個既存物件,或是每次回傳一個新的物件(多半用於Dependency、Singleton情況,稍後會有詳細說明)。
l 透過特定的Factory建立一個物件,這個Factory可以依據組態檔的設定來建立物件(CustomFactory,隸屬於Enterprise Common Library)。
l 當物件擁有一個以上的建構子時,依據已有的參數,自動選取相容的建構子來建立要求的物件。(Consturctor Injection)
l 允許物件於建立後,透過程式或組態檔來賦值至屬性,或是呼叫特定的函式。(Setter Injection、Interface Injection)
l 提供一組Attribute,讓設計師可以指定需要Injection的屬性,亦或是於物件建立後需要呼叫的函式,也就是使用Reflection來自動完成Injection動作。
l 提供IBuilerAware介面,實作此介面的物件,ObjectBuilder會於建立該物件後,呼叫OnBuildUp或是OnTearDown函式。
l 提供TearDown機制,按建立物件的流程,反向釋放物件。
對於多數讀者來說,這些官方說明相當的隱誨,本文嘗試由架構角度切入,討論ObjectBuidler的主要核心概念,再透過實作讓讀者們了解,該如何使用ObjectBuidler
3-1The Architecture of Object Builder
圖2
2ObjectBuilder中四個主要核心物件的示意圖,BuidlerContext是一個概念型的環境物件,在這個物件中,包含著一組Strategys物件,一組Polices物件,一個Locator物件, ObjectBuidler採用Strategys Pipeline(策略流)概念,設計師必須透過Strategy串列來建立物件,而Strategy會透過Polices來尋找『型別/id』對應的Policy物件,使用她來協助建立指定的物件。此處有一個必須特別提出來討論的概念,Strategy在架構上是與型別無關的,每個BuidlerContext會擁有一群Strategys物件,我們透過這個Strategys物件來建立任何型別的物件,不管建立的物件型別為何,都會通過這個Strategys Pipeline。這意味著,當我們希望於建立A型別物件後呼叫函式A1,於建立B型別物件後呼叫函式B1時,負責呼叫函式的Strategy物件會需要一個機制來判別該呼叫那個函式,那就是Policy物件,BuilderContext中擁有一個Polices物件,其中存放著與『型別/id』對應的Policy物件,如圖3所示。
圖3
值得一提的是,Policy是以Type/id方式,也就是『型別/id』方式來存放,這種做法不只可以讓不同型別擁有各自的Policy,也允許同型別但不同id擁有各自的PolicyObjectBuilder中的最後一個元素是LocatorLocator物件在ObjectBuidler中扮演著前述的Service Locator角色,設計師可以用Key/Value的方式,將物件推入Locator中,稍後再以Key值來取出使用。
3-2、Strategys
ObjectBuilder內建了許多Strategy,這些Strategy可以大略分成四種類型,如圖4。
圖4
Pre-Creation Strategy
Pre-Creation意指物件被建立前的初始動作,參與此階段的Strategy有:TypeMappingStrategyPropertyReflectionStrategyConstructorReflectionStrategyMethodReflectionStrategySingletonStrategy,稍後我們會一一檢視她們。
Creation Strategy
Creation類型的Strategy主要工作在於建立物件,她會利用Pre-Creation Strategys所準備的參數來建立物件,ObjectBuilder就是運用Pre-CreationConstructorReflectionStrategyCreationStrategy來完成Constructor Injection動作。
Initialization Strategy
當物件建立後,會進入初始化階段,這就是Initialization Strategy階段,在此階段中,PropertySetterStrategy會與PropertyReflectionStrategy合作,完成Setter Injection。而MethodExecutionStrategy則會與MethodReflectionStrategy合作,在物件建立後,呼叫特定的函式,也就是Method Injection(視使用方式,Interface Injection是以此種方式完成的)。
Post-Initialization Strategy
在物件建立並完成初始化動作後,就進入了Post-Initialization Strategy階段,在此階段中,BuilderAwareStrategy會探詢已建立的物件是否實作了IBuilderAware介面,是的話就呼叫IBuilderAware.OnBuildUp函式。
關於物件釋放
先前曾經提過,ObjectBuidler在建立物件時,會一一呼叫所有Strategy來建立物件,同樣的!當釋放物件時,ObjectBuilder也會進行同樣的動作,不過方向是相反的,在內建的Strategy中,只有BuilderAwareStrategy會參與物件釋放的動作,在物件釋放時,BuilderAwareStrategy會探詢欲釋放的物件是否實作了IBuidlerAware介面,是的話就呼叫IBuidlerAware.OnTearDown函式。
3-3A Simple Application
再怎麼詳細的說明,少了一個實例就很難讓人理解,本節以一個簡單的ObjectBuidler應用實例開始,一步步帶領讀者進入ObjectBuilder的世界。
程式10
using System;
using System.Collections.Generic;
using System.Text;
using Microsoft.Practices.ObjectBuilder;
namespace SimpleApp
{
class Program
{
static void Main(string[] args)
{
Builder builder = new Builder();
TestObject obj = builder.BuildUpTestObject>(new Locator(), null, null);
obj.SayHello();
Console.ReadLine();
}
}
public class TestObject
{
public void SayHello()
{
Console.WriteLine("TEST");
}
}
}
這是一個相當陽春的例子,在程式一開始時建立了一個Builder物件,她是ObjectBuilder所提供的Facade物件,其會預先建立一般常用的Strategy串列,並於BuilderUp函式被呼叫時,建立一個BuilderContext物件,並將Srategy串列及Polices串列指定給該BuilderContext,然後進行物件的建立工作。
How Object Creating
要了解前面的例子中,TestObject物件究竟是如何被建立起來的,首先必須深入Builder物件的建構動作。
private StrategyList<tstageenum> strategies = <span style="COLOR: blue">new</span> <span style="COLOR: teal">StrategyList</span><tstageenum>();</tstageenum></tstageenum>
public BuilderBase()
{
}
public PolicyList Policies
{
get { return policies; }
}
public StrategyList<tstageenum> Strategies</tstageenum>
{
get { return strategies; }
}
public Builder(IBuilderConfiguratorBuilderStage> configurator)
{
Strategies.AddNewTypeMappingStrategy>(BuilderStage.PreCreation);
Strategies.AddNewSingletonStrategy>(BuilderStage.PreCreation);
Strategies.AddNewConstructorReflectionStrategy>(BuilderStage.PreCreation);
Strategies.AddNewPropertyReflectionStrategy>(BuilderStage.PreCreation);
Strategies.AddNewMethodReflectionStrategy>(BuilderStage.PreCreation);
Strategies.AddNewCreationStrategy>(BuilderStage.Creation);
Strategies.AddNewPropertySetterStrategy>(BuilderStage.Initialization);
Strategies.AddNewMethodExecutionStrategy>(BuilderStage.Initialization);
Strategies.AddNewBuilderAwareStrategy>(BuilderStage.PostInitialization);
Policies.SetDefaultICreationPolicy>(new DefaultCreationPolicy());
if (configurator != null)
configurator.ApplyConfiguration(this);
}
Buidler物件被建立時,其建構子會將前面所提及的幾個Strategys加到Strategies這個StrategyList Collection物件中,待BuildUp函式被呼叫時指定給新建立的BuilderContext物件。
public TTypeToBuild BuildUp<ttypetobuild>(<span style="COLOR: teal">IReadWriteLocator</span> locator,</ttypetobuild>
string idToBuild, object existing, params PolicyList[] transientPolicies)
{
return (TTypeToBuild)BuildUp(locator, typeof(TTypeToBuild), idToBuild, existing, transientPolicies);
}
public virtual object BuildUp(IReadWriteLocator locator, Type typeToBuild,
string idToBuild, object existing, params PolicyList[] transientPolicies)
{
....................
return DoBuildUp(locator, typeToBuild, idToBuild, existing, transientPolicies);
...................
}
private object DoBuildUp(IReadWriteLocator locator, Type typeToBuild, string idToBuild, object existing,
PolicyList[] transientPolicies)
{
IBuilderStrategyChain chain = strategies.MakeStrategyChain();
..............
IBuilderContext context = MakeContext(chain, locator, transientPolicies);
..........................
object result = chain.Head.BuildUp(context, typeToBuild, existing, idToBuild);
.......................
}
private IBuilderContext MakeContext(IBuilderStrategyChain chain,
IReadWriteLocator locator, params PolicyList[] transientPolicies)
{
.............
return new BuilderContext(chain, locator, policies);
}
Builder的泛型函式BuildUp函式被呼叫後,其會呼叫非泛型的BuildUp函式,該函式會呼叫DoBuildUp函式,此處會透過strategies(先前於Builder建構子時初始化的StrategyList物件)來取得Strategys串列,並指定給稍後由MakeContext函式建立的BuilderContext,最後呼叫Strategy串列中第一個StrategyBuildUp函式來進行物件的建立動作。在這一連串的動作中,我們可以釐清幾個容易令人混淆的設計,第一!我們是透過Strategy串列,也就是IBuidlerStrategyChain.Head.BuildUp來建立物件,這個Head屬性就是Strategy串列中的第一個Strategy。第二!BuilderContext的作用在於,於呼叫各個Strategy.BuildUp函式時,給予她們存取此次建立動作所使用的StrategysPolicies等物件的機會。
Policy物件的用途
現在,我們弄清楚了Strategy的用途,BuilderContext的真正涵意,但還有兩個元素尚未釐清,其中之一就是Policy物件,前面曾經稍微提過,Strategy是與型別無關的設計概念,因此為了針對不同型別做個別的處理,我們需要另一個與型別相關的設計,那就是Policy物件,要確認這點,必須重返Builder的建構子。
public Builder(IBuilderConfiguratorBuilderStage> configurator)
{
..................
Policies.SetDefaultICreationPolicy>(new DefaultCreationPolicy());
.................
}
這裡呼叫了PoliciesSetDefault函式,Policies是一個PolicyList物件,其提供了推入(SetSetDefault)及取出(Get)函式,允許設計者針對所有『型別/id』及特定『型別/id』指定對應的IBuilderPolicy物件,那這有什麼用呢?這個問題可以由CreationStrategy類別中的以下這段程式碼來回答。
public override object BuildUp(IBuilderContext context, Type typeToBuild, object existing, string idToBuild)
{
if (existing != null)
BuildUpExistingObject(context, typeToBuild, existing, idToBuild);
else
existing = BuildUpNewObject(context, typeToBuild, existing, idToBuild);
return base.BuildUp(context, typeToBuild, existing, idToBuild);
}
[SecurityPermission(SecurityAction.Demand, Flags = SecurityPermissionFlag.SerializationFormatter)]
private object BuildUpNewObject(IBuilderContext context, Type typeToBuild,
object existing, string idToBuild)
{
ICreationPolicy policy = context.Policies.GetICreationPolicy>(typeToBuild, idToBuild);
.........................
InitializeObject(context, existing, idToBuild, policy);
return existing;
}
private void InitializeObject(IBuilderContext context, object existing, string id, ICreationPolicy policy)
{
................
ConstructorInfo constructor = policy.SelectConstructor(context, type, id);
...................
object[] parms = policy.GetParameters(context, type, id, constructor);
...............
method.Invoke(existing, parms);
}
如你所見,CreationStrategy於建立物件時,會由Policies中取出『型別/id』對應的ICreationPolicy物件,接著利用她來取得ConstructorInfo(建構子函式),再以GetParameters函式來取得建構子所需的參數,最後呼叫此建構子。這段程式碼告訴我們Policy的真正用途,就是用來協助Strategy於不同『型別/id』物件建立時,採取不同的動作,這也就是說,StrategyPolicy通常是成對出現的。
Locator
最後一個尚未釐清的關鍵元素是Locator,我們於呼叫Builder的BuildUp函式時,建立了一個Locator物件並傳入該函式,這是用來做什麼的呢?在ObjectBuilder中,Locator扮演兩種角色,第一個角色是提供一個物件容器供Strategy使用,這點可以透過以下程式了解。
public class SingletonStrategy : BuilderStrategy
{
public override object BuildUp(IBuilderContext context, Type typeToBuild,
object existing, string idToBuild)
{
DependencyResolutionLocatorKey key = new DependencyResolutionLocatorKey(
typeToBuild, idToBuild);
if (context.Locator != null && context.Locator.Contains(key, SearchMode.Local))
{
TraceBuildUp(context, typeToBuild, idToBuild, "");
return context.Locator.Get(key);
}
return base.BuildUp(context, typeToBuild, existing, idToBuild);
}
}
SingletonStrategy是一個用來維持某一個物件只能有一份實體存在,當此Strategy被喚起時,其會先至Locator尋找目前要求的物件是否已被建立,是的話就取出該物件並傳回。Locator同時也可以作為一個Service Locator,這點可以由以下程式碼來驗證。
locator.Add("Test",new TestObject());
.............
TestObject obj = locator.GetTestObject>("Test");
當然,這種手法有一個問題,那就是TestObject物件是預先建立後放在Locator中,這並不是一個好的設計,後面的章節我們會提出將Service LocatorDependency Injection整合的手法。
PS:ObjectBuidlerLocator離完善的Service Locator還有段距離。
四、Dependency Injection With ObjectBuilder
ObjectBuilder支援Dependency Injection中定義的三種Injection模式,本章將一一介紹如何運用ObjectBuilder來實現。
4-1Constructor Injection
Constructor Injection的精神在於使用建構子來進行注入動作,本節延用InputAccept的例子,程式11是改採ObjectBuilder進行Constructor Injection的例子。
程式11
using System;
using System.Collections.Generic;
using System.Text;
using System.Configuration;
using Microsoft.Practices.ObjectBuilder;
using Microsoft.Practices.EnterpriseLibrary.Common.Configuration.ObjectBuilder;
using Microsoft.Practices.EnterpriseLibrary.Common.Configuration;
namespace OB_ConstructorInjectionTest
{
class Program
{
static void UseValueParameter(MyBuilderContext context)
{
ConstructorPolicy creationPolicy = new ConstructorPolicy();
creationPolicy.AddParameter(new ValueParameter(typeof(IDataProcessor),
new PromptDataProcessor()));
context.Policies.SetICreationPolicy>(creationPolicy, typeof(InputAccept), null);
}
static void Main(string[] args)
{
MyBuilderContext context = new MyBuilderContext(new Locator());
context.InnerChain.Add(new CreationStrategy());
UseValueParameter(context);
InputAccept accept = (InputAccept)context.HeadOfChain.BuildUp(context,
typeof(InputAccept), null, null);
accept.Execute();
Console.Read();
}
}
internal class MyBuilderContext : BuilderContext
{
public IReadWriteLocator InnerLocator;
public BuilderStrategyChain InnerChain = new BuilderStrategyChain();
public PolicyList InnerPolicies = new PolicyList();
public LifetimeContainer lifetimeContainer = new LifetimeContainer();
public MyBuilderContext()
: this(new Locator())
{
}
public MyBuilderContext(IReadWriteLocator locator)
{
InnerLocator = locator;
SetLocator(InnerLocator);
StrategyChain = InnerChain;
SetPolicies(InnerPolicies);
if (!Locator.Contains(typeof(ILifetimeContainer)))
Locator.Add(typeof(ILifetimeContainer), lifetimeContainer);
}
}
public class InputAccept
{
private IDataProcessor _dataProcessor;
public void Execute()
{
Console.Write("Please Input some words:");
string input = Console.ReadLine();
input = _dataProcessor.ProcessData(input);
Console.WriteLine(input);
}
public InputAccept(IDataProcessor dataProcessor)
{
_dataProcessor = dataProcessor;
}
}
public interface IDataProcessor
{
string ProcessData(string input);
}
public class DummyDataProcessor : IDataProcessor
{
#region IDataProcessor Members
public string ProcessData(string input)
{
return input;
}
#endregion
}
public class PromptDataProcessor : IDataProcessor
{
#region IDataProcessor Members
public string ProcessData(string input)
{
return "your input is: " + input;
}
#endregion
}
}
该合成数据集模拟了世界领先的运动服装和鞋类品牌之一耐克的零售和在线销售交易。它故意填充了凌乱、未清理的记录,以复制真实世界的业务数据,非常适合练习数据清理、探索性数据分析 (EDA) 以及构建仪表板或项目组合项目。 有什么超过 2,500 条交易记录,包含: 多个产品线(跑步、篮球、生活方式、训练、足球) 特定性别的销售(男性、女性、儿童) 零售店和在线渠道的销售额 常见的数据问题,例如:空值、地区拼写错误、错误的数据类型、数值列中的负值、日期格式不一致(例如,2023/07/21、21-07-2023 等)、折扣> 100%。 列描述 Order_ID ----交易/订单 ID(一些重复条目) Gender_Category------- 买家细分:男士、女士或儿童 Product_Line------ 商品类型:跑步、篮球等 Product_Name -------售出的特定商品(例如,Air Force 1、Pegasus Turbo) 尺寸-----商品尺寸(例如 7、M、L - 包括缺失/不一致) Units_Sold-------- 销售数量(可以是负数或空数) 建议零售价---------- 最高零售价(有些为零或零) Discount_Applied------ 销售折扣(有些超过 100%) 收入-------折扣后的最终金额(有些计算错误) Order_Date --------交易日期(多种格式和空) Sales_Channel -----------在线或零售 区域-------------印度城市(包括“德里”、“孟加罗尔”等拼写错误) 利润 --------------赚取的利润(可能是不切实际的或负的)
内容概要:本文详细介绍了果蔬采摘机器人末端执行器的柔顺抓取力控制方法,特别是基于广义比例积分(GPI)的力矩控制技术。文章首先概述了该方法的核心原理,即通过建模电机驱动的末端执行器,推导出电机输入电压与负载力矩的关系,并利用积分重构器设计GPI力矩反馈控制器,将力偏差转化为电机输入电压控制。相比传统PI控制,GPI方法无需对力矩跟踪误差求导,避免了系统延时和噪声问题。文章还提供了详细的Python代码实现,包括系统建模、GPI控制器设计、仿真比较和性能指标计算。实验结果表明,GPI控制方法在力矩跟踪误差、采摘完好率等方面表现出显著优势。 适合人群:具备一定编程基础,尤其是对机器人控制、自动化和机电一体化领域有兴趣的研发人员和技术爱好者。 使用场景及目标:①适用于果蔬采摘机器人或其他需要柔顺力控制的机器人应用;②通过仿真和实物实验,验证GPI控制在力矩跟踪、控制平稳性和采摘完好率等方面的优势;③帮助研究人员理解GPI控制器的设计原理及其相对于传统PI控制的改进之处。 其他说明:文章不仅提供了完整的理论推导和代码实现,还深入探讨了GPI控制器的关键技术和工程实现细节,如积分重构技术、四阶误差动态补偿、极点配置方法等。此外,文中还包含了实物实验结果统计和性能对比分析,进一步验证了GPI控制的实际应用价值。对于希望深入了解果蔬采摘机器人末端执行器控制技术的研究人员来说,这是一份非常有价值的参考资料。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值