【设计模式】访问者--稳定的数据结构+多变的算法

【缘起】

          本周六的时候,本人进行了一场关于设计模式中访问者的分享。

         但是本人一紧张就说话语速略快,所以就想将自己分享的主要思想写出来,以便将自己的想法分享给大家。

【参考资料】

         程杰著  《大话设计模式》

        《设计模式-可复用面向对象软件的基础》

【主要思想】

      1  访问者的特点: 稳定的数据结构和多变的算法。

      2  结构图(UML类图)

      3   访问的过程

       step1 需求驱动

                 声明算法

          因为访问者的使用场景是稳定的数据结构,申请访问的对象是固定的,如这里只有ConcreteElementA和ConcreteElementB         

                如果我拥有了某个具体对象的访问权(可以使用它的公共静态属性,公共动态方法)时,我在访问该具体对象的时候,我会做什么。即编写VisitConcreteElementA()  和Visit ConcreteElementB()。

        step2 申请访问权

                又因为访问者的使用场景是稳定的数据结构,所以可以将数据对象都封装在一个对象结构ObjectStructure中。

                当我们需要发送对每个访问对象的访问权申请的时候,只需要将访问申请发送给对象结构。然后通过对象结构,遍历结构中的被访问对象,就能够让每个被访问对象都通过Accept(Vistor visitor)对算法(操作) 访问者的访问申请进行审核(识别访问者的身份并判断)。

        step3 审核访问权

               通过Accept(Visitor visitor)将访问者对象作为参数传入,通过visitor.GetType().Name (对象名) 公共静态属性的获取,可以对不同的访问者(申请调用该对象的具体操作类)设置不同的访问权限(可以调用和不可调用)。

       step4 执行  调用对象实现算法(具体操作)

      如果该对象对访问者设置的权限是可以访问,在允许访问的方法体中就会调用具体的操作,也就是,一旦获得了访问权,就马上实施权利。

    以上就是在访问者模式下,一次完整的访问的流程。

4  面对修改封闭,面对扩展开放

  该模式,添加算法(作用在数据结构上的具体操作)容易,新写一个具体算法类(写一份访问申请书)即可。

                添加对象,则需要修改多处,更需要新建算法父类,违背了开闭原则 。

5  适用场景

                 一系列的操作中,具体操作用到的操作对象是一个对象集合的子集,并且操作较复杂的时候,可以采用该设计模式,可以起到算法和数据结构解耦的作用。

 

                                                                                  【感谢阅读】

数据库设计 以及所有数据库的性能优化 所谓数据库设计就是根据具体应用环境设计出合理的数据库模式。其中应用环境包括:业务需求、数据需求和技术条件等具体情况,而数据库模式包括数据之间的联系、数据应满足的约束以及对数据的典型操作。从面向对象的角度讲:数据库设计就是类的持久化。 1 数据库设计的重要性 各种信息系统都以数据库为其中心,各种大型应用系统都以数据库为其枢纽。数据库的设计是一项十分复杂的任务,设计的质量直接关系信息系统建设的成败! 1.1 数据是企业的重要资产 数据是需要精心设计,并长时间积累方可获得的一种资源。数据不仅对组织的运作和管理是重要的,而且还决定者组织的竞争能力或运行效率。例如:婚姻介绍所的求婚者数据是该婚介所的生命线;股票经纪人的股票及其价格的历史数据是这些经纪人的生命线。因此,数据是组织(企事业单位,机关,学校等)的相当重要资产,应当像管理其它资产那样管理组织的数据。 1.2 数据位于信息系统的中心 从简单的单证数据处理、统计汇总与查询到综合信息服务,以及按照“如果…将会…”(what-if)思维模式进行人-机交互的辅助决策等活动,都是对精心设计的数据库的存取操作。数据位于信息系统的中心。 1.3 数据是稳定的,而处理是多变的 数据是按实体(如客户、产品、零件、员工、设备等)存储的。除了偶尔少量加入几个新的实体类型外,在企业经营方向不发生改变的前提下,这些实体类型及其属性之间的内在联系是不会变化的,变化的只是实体的属性值。如同机场航班信息牌上的数据一样,数据的格式一般是不变的,而数据的取值是随时变化的。虽然数据是相对稳定的,但是,对于数据的处理规则是经常变化的。 1.4 数据建模是信息系统建设的核心和难点 从技术角度讲,信息系统建设的实质是系统集成,而系统集成的关键在于处理好各系统之间的互连性和互操作性(即接口)。硬件及系统软件的互连性和互操作性均可由标准化接口或协议来实现,而应用软件系统(比如:财务、供应、生产、销售等等)之间的互连性和互操作性,必须通过开发商或集成商与企业的业务人员和管理人员一起,对企业管理中的各种业务流程、业务数据以及相关的规章制度进行深入细致的调查、分析,并进行归纳、抽象,在此基础上建立企业运行的逻辑模型—集成化的数据模型(即数据库模式)和业务模型才能实现,这是信息系统建设的核心和难点。 稳定的数据库模式是客观存在的,它深藏于组织的业务之中,必须采取科学的方法并下大力气方可获得。建立稳定的数据库模式(即数据建模)是信息系统建设的一项基础性工作。早期信息系统建设屡遭挫折的根本原因就在于没有建立起稳定的数据库模式。 2 需求获取与分析 2.1 业务建模(Business Modeling) 业务模型是用“职能范围(Function Area)—业务过程(Process)—业务活动(Activity)”这样的层次结构描述的。 2.1.1 职能范围 职能范围指的是一个企业中的主要业务领域,比如工程、市场、生产、科研、销售等。下面举出一个中型制造厂的职能范围:  经营计划  财务  产品计划  材料  生产计划  生产  销售  分配  财会  人事 职能范围图表展示了整个企业的概貌,即职能模型(Functional Model)。 2.1.2 业务过程 每个职能范围都要执行一些业务过程。下面是前面例子中的中型制造厂的各职能范围的业务过程(图表1): 职能范围和业务过程的确定,应该独立于当前的组织机构。组织机构可能变化,但要执行的业务职能以及相应的业务过程仍然相同。例如,有的企业的组织机构如同某些政府一样,每两年或稍长一点时间就改组一次,而其职能范围和相应的业务过程则保持不变。因此,企业的职能范围和业务过程的确定,应反映出这样一种基本的考虑,即撇开企业当前的组织结构(它常使人误解),该企业将怎样运行?
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值