• 【Java-POJO-设计模式】JavaEE中的POJO与设计模式中多态继承的冲突


    最近看《重构》谈到利用OO的多态来优化 if else 和 switch 分支语句,但是我发现OO语法中的多态在使用框架的JavaEE中是无法实践的。对此,我感到十分的疑惑,加之之前项目中有个“状态模式”类的模块被频繁改动的需求折磨要死,又去看了《设计模式》。《设计模式》中也是强调,使用多态和继承来实现“状态”模式。但在采用了 SSH 或 SSM 的项目中,但我从来没有在 实体类(POJO/Bean)中见到过“继承”的语法形式。
     
    于是,我搜集了所谓 POJO 、JavaBean、VO、PO、DTO这几个相近概念的含义。
     

     
    POJO
     
     一:什么是POJO
    POJO的名称有多种,pure old java object 、plain ordinary java object 等。
    按照Martin Fowler的解释是“Plain Old Java Object”,从字面上翻译为“纯洁老式的java对象”,但大家都使用“简单java对象”来称呼它。
    POJO的内在含义是指那些没有从任何类继承、也没有实现任何接口,更没有被其它框架侵入的java对象。

     

    二:为什么会有POJO?
    主要是Java的开发者被EJB的繁杂搞怕了,大家经过反思,又回归“纯洁老式”的JavaBean,即有无参构造函数,每个字段都有getter和setter的java类。

     

    三:POJO的意义
    POJO让开发者可专注于业务逻辑和脱离框架的单元测试。除此之外, 由于POJO并不须要继承框架的类或实现其接口,开发者能够极其灵活地搭建继承结构和建造应用。
    POJO的意义就在于它的简单而灵活性,因为它的简单和灵活,使得POJO能够任意扩展,从而胜任多个场合,也就让一个模型贯穿多个层成为现实。
    先写一个核心POJO,然后实现业务逻辑接口和持久化接口,就成了Domain Model; UI需要使用时,就实现数据绑定接口,变成VO(View Object)。

     

    四:POJO与PO、VO的区别
    POJO是指简单java对象(Plain Old Java Objects、pure old java object 或者 plain ordinary java object)。
    PO是指持久对象(persistant object持久对象)。
    VO是指值对象或者View对象(Value Object、View Object)。注意,本文的VO特指View Object。
    持久对象实际上必须对应数据库中的entity,所以和POJO有所区别。比如说POJO是由new创建,由GC回收。但是持久对象是insert数据库创建,由数据库delete删除的。基本上持久对象生命周期和数据库密切相关。另外持久对象往往只能存在一个数据库Connection之中,Connnection关闭以后,持久对象就不存在了,而POJO只要不被GC回收,总是存在的。
    由于存在诸多差别,因此持久对象PO(Persistent Object)在代码上肯定和POJO不同,起码PO相对于POJO会增加一些用来管理数据库entity状态的属性和方法。而ORM追求的目标就是要PO在使用上尽量和POJO一致,对于程序员来说,他们可以把PO当做POJO来用,而感觉不到PO的存在。

     

    五:POJO的扩展
    POJO仅包含最简单的字段属性,没有多余的东西,它本质上就是一个普通的JavaBean。
    但是在POJO的基础上,能够扩展出不同的对象。
    为POJO增加了持久化的方法(Insert、Update、Delete……)之后,POJO就变成了PO。
    为POJO增加了数据绑定功能之后,POJO就变成了View Object,即UI Model。
    为POJO增加业务逻辑的方法(比如单据审核、转帐……)之后,POJO就变成了Domain Model。
    POJO还可以当作DTO使用。

     


     

     

    我一直认为:概念,名词,理论无非是人用来理解、抽象事物的,是拿来用的。如果没有相应的名词,我们自己也可以创造。

     

    个人感觉,在SSM或SSH的 JavaWeb 项目中,领域模型【Domain Model】(如成绩管理系统里面的学生、成绩等实体) 一般是被简化为 POJO ,然后这个 POJO 既用作 VO 也用作 PO 。Struts 或 Sprint MVC 用 VO 来包裹页面的数据,传给 Action  或 Controller ; Action  或 Controller 内部 用 DTO【Data Transfer Object 】互相传输数据; Hibernate 或者 MyBatis 用 PO 来包裹 业务逻辑处理过的数据 放到 数据库中。在这里,VO 和 PO 因为简单,就使用同一个 POJO 了事。但是如果我们遇到复杂的 领域模型,这个需要使用 继承和多态的 结构应该放在哪里呢 ?  POJO ? PO?VO?DTO?我觉得,这时候,是不是就应该需要另外一层 ?

     

    举个在《设计模式:Java语言》中的“状态模式”的例子。

    有个传送带,它有一个用于放入物品的门和控制门开关的按钮。当门关着时,按钮开门;当门开着时,按钮使门继续保持打开;当门开着,且2分钟没有操作时,门自动关闭;当门正在关闭时,按钮使门打开;当门正在打开时,按钮开门。【具体细节忘了。。。】

    博主:简单的说,就是按钮总是要开门,门超时会自动关闭。门除了开关两个状态,还有“正在开 Opening ”  和 “正在关 Closing”两个状态。

    书中建议使用 状态模式,也就是说需要 设计 含有继承关系的几个类。如果这个功能出现在采用了 SSM 框架的 JavaEE项目中,那么,这个继承关系该设计到哪里呢?

     

     

  • 相关阅读:
    详解GaussDB(for MySQL)服务:复制策略与可用性分析
    华为云的研究成果又双叒叕被MICCAI收录了!
    充分释放数据价值:安全、可信6到飞起
    未来云原生世界的“领头羊”:容器批量计算项目Volcano 1.0版本发布
    一文带你掌握OBS的两种常见的鉴权方式
    数据库实践丨MySQL多表join分析
    技术贴丨教你使用华为云鲲鹏服务器部署Discuz!论坛
    python Scrapy 从零开始学习笔记(二)
    python Scrapy 从零开始学习笔记(一)
    从零开始学Electron笔记(七)
  • 原文地址:https://www.cnblogs.com/muyun/p/9911227.html
Copyright © 2020-2023  润新知