论坛首页 Java企业应用论坛

学习Design Pattern笔记

浏览 6347 次
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
作者 正文
   发表时间:2006-11-26  
软件可维护性能差的主要原因
[list=A]
  • 过于僵硬:不能轻松的加入新的功能[/list]
  • [list=B]
  • 过于脆弱:修改一处可能波及到很多其他的地方[/list]
  • [list=C]
  • 复用率低:现有的代码依赖于其他的东西,想要重用这个代码就很困难[/list]
  • [list=D]
  • 黏度过高:改动总是以破坏原始意图和原始设计框架的方式进行[/list]

  • 设计原则
    1。OCP原则(开闭原则)
        Software entities should be opon for extension but closed for modification.
        对可变性的封装:当一个组件被认为是可变的时候,应该对这个可变性的组件进行封装,以便使其内部的变化只作用在内部范围内,不会延伸到其他地方。
        一个可变性的不同的表象就是同一个继承结构中的具体的子类。在设计的时候不应该把不同的可变性混合在一起。

    2。里氏代换原则:
        如果每个C1类型的对象O1,都有一个C2类型的对象O2,使得以C1定义的程序里面的O1都可以换成O2,那么就说C2是C1的一个子类。
        里氏代换原则要求在使用基类的地方其子类也一定适用,这条原则是在进行OOD时候对对象抽象过程中的一个验证方法。比若说设计了一个超类A,我们又设计了A的子类,那么检查我们的设计是否合理,就应该根据里氏代换原则,看看应用代码中使用到A的对象的地方,时候可以换成其子类对象也同样成立,如果不成立那么则证明子类并不真正是超类的孩子。

    3。依赖倒转关系:
        通常在设计分层结构的时候,我们总是设计成高层依赖于低层,而依赖倒转的要求就是低层要依赖于高层,这里面简单的例子就是Java中的接口技术,根据依赖倒转关系原则,就有了针对接口编程概念:一个具体的Java类应该只实现其抽象类和接口中的方法,而不是给出多余的方法。

    4。抽象类于接口:
        a.抽象类可实现部分功能,而接口不可以,所以抽象类的子类就拥有了抽象类实现的那部分功能。
        b.抽象类的实现存在于其等级结构中,而接口的实现不仅可以实现此接口,同时也可以实现其他接口。这样这个子类可以对外提供不同的服务。
        c.如果在已有的子类,为其定义一个抽象的父类是比较困难的,因为这会改变其等级结构,而为其定义一个接口却是容易的。
        d.接口是定义混合型类型的理想工具。
    5。ISP(接口分离原则):
        这个原则强调的是如何来设计接口,它强调了应该按角色来对接口划分,而不应该把所有角色的功能都归结到一个接口中去。它强调不要把很多接口作为优化对象。
        例如:有一个网站有一个全文搜索的功能,系统有一个Interface来提供所有的操作功能,比如说管理索引,搜索操作等等。根据ISP原则应该按角色划分,对每一个角色都设计一个接口,如上例就应该分别设计一个索引管理接口和搜索操作接口。
    6。CARP合成/聚合复用原则:
    7。LoD迪米特原则:也成为最少知识原则
        如果一个类不必与其他类直接通信,那么两个类就不应该相互作用,也就是说彼此都不知道对方的存在。如果一个类需要调用另外一个类的方法,可以通过第三方来调用。
        这个原则就是为了封闭组件的可变性,是它们的变化不会波及到其他地方。

    以上是我学习Design Pattern的一些理解,可能有不恰当的地方,希望与大家交流。我是对这方面知识还算是个菜鸟,希望大家能给我提点建议,对于这方面的知识应该如何去学习效率比较高一些。现在学起来感觉很是抽象,可能以前也做过一些东西,不过考虑到这方面的东西并不是很多。第一次发贴!庆祝一下,^_^
       发表时间:2006-11-26  
    软件可维护性能差的主要原因:

    1.过于僵硬:不能轻松的加入新的功能
    2.过于脆弱:修改一处可能波及到很多其他的地方
    3.复用率低:现有的代码依赖于其他的东西,想要重用这个代码就很困难
    4.黏度过高:改动总是以破坏原始意图和原始设计框架的方式进行

    这四点总结得不错,简明扼要.
    0 请登录后投票
       发表时间:2006-11-26  
    分析很好,最近也想研究一下
    0 请登录后投票
       发表时间:2006-11-27  
    过于脆弱:修改一处可能波及到很多其他的地方
    黏度过高:改动总是以破坏原始意图和原始设计框架的方式进行
    这两点似乎差不多啊
    0 请登录后投票
       发表时间:2006-11-27  
    给我的感觉不要把设计模式看的太神拉,一切设计做到顺其自然,行云流水就足够拉!
    3年前不知道到什么是设计模式;
    2年前看不懂设计模式;
    1年前在注意到设计模式;
    现在发现原来没有以前那么多的开发设计经验,根本没办法理解设计模式!

    盖大楼的壮工和建筑设计师是没办法靠设计模式来交流的!
    0 请登录后投票
       发表时间:2006-11-28  
    说个简单的例子,是我最近的一个练习。最近练习做一个基于WEB的图书馆管理系统,里面有一些对数据库的简单操作,所以就想到了用DAO模式来设计,下面就谈谈我对DAO的一些理解和一些疑惑。(我是用的是Struts架构,IDE使用的是Eclipse)

    DAOFactory来负责实例化,然后为每一个BO(business object)设计一个DAOInterface,例如在这里我就建立了BorrowerDAOInterface, BorrowRecordDAOInterface等等(其中BO是从领域分析中得来的),然后就是创建接口的实现类,而这些实现类都有一个共同的超类DAO,它包含了共性的操作和属性,例如DataSource和close()操作。具体代码如下(我只列举一部分):
    工厂类:提供静态方法,返回DAO接口实例
    <code="java">
    public class DaoFactory {

        public static Certificates getCertificateDao(DataSource dataSource) {
            return new CertificatesImp(dataSource);
        }

        public static BorrowRecords getBorrowRecordDao(DataSource dataSource) {
            return new BorrowRecordsImp(dataSource);
        }

        public static BorrowItems getBorrowItemDao(DataSource dataSource) {
            return new BorrowItemsImp(dataSource);
        }

        public static BorrowHistories getBorrowHistoryDao(DataSource dataSource) {
            return new BorrowHistoriesImp(dataSource);
        }

        public static Borrowers getBorrowerDao(DataSource dataSource) {
            return new BorrowersImp(dataSource);
        }
    }
    </code>
    BorrowRecord接口:定义对此BO的操作
    <code="java">
    public interface BorrowRecords {

        public List<BorrowRecord> list() throws SQLException;

        public BorrowRecord searchById(String id) throws SQLException;

        public boolean insertBorrowRecord(BorrowRecord record) throws SQLException;

        public boolean delete(BorrowRecord record) throws SQLException;
    }
    </code>
    BorrowRecord接口实现类:
    <code="java">
    public class BorrowRecordsImp extends Dao implements BorrowRecords {
        private BorrowItems items;

        private final String SQL_LIST = "SELECT DISTINCT borrowerID FROM BORROWRECORD";

        public BorrowRecordsImp(DataSource dataSource) {
            this.dataSource = dataSource;
            items = new BorrowItemsImp(dataSource);
        }

        public List<BorrowRecord> list() throws SQLException {
            Connection conn = null;
            ResultSet rs = null;
            PreparedStatement st = null;
            List<BorrowRecord> records = new Vector<BorrowRecord>();
            List<BorrowRecordItem> itemList;
            BorrowRecord record;
            try {
                conn = dataSource.getConnection();
                st = conn.prepareStatement(SQL_LIST);
                rs = st.executeQuery();
                while (rs.next()) {
                    itemList = items.listRecord(rs.getString("borrowerID"));
                    record = new BorrowRecord();
                    record.setBorrowerID(rs.getString("borrowerID"));
                    record.setBorrowRecordItems(itemList);
                    records.add(record);
                }
            } catch (SQLException e) {
                e.printStackTrace();
            } finally {
                close(rs);
                close(st);
                close(conn);
            }
            return records;
        }

        public BorrowRecord searchById(String id) throws SQLException {
            BorrowRecord record = null;
            try {
                List<BorrowRecordItem> list = items.listRecord(id);
                record = new BorrowRecord();
                record.setBorrowerID(id);
                record.setBorrowRecordItems(list);
            } catch (SQLException e) {
                e.printStackTrace();
            } finally {
            }
            return record;
        }

        public boolean insertBorrowRecord(BorrowRecord record) throws SQLException {
            boolean result = true;
            String borrowerID = record.getBorrowerID();
            BorrowRecordItem item = null;
            for (int i = 0; i < record.getBorrowRecordItems().size(); i++) {
                try {
                    item = (BorrowRecordItem)record.getBorrowRecordItems().get(i);
                    items.insertBorrowRecordItem(item, borrowerID);
                }catch (SQLException e) {
                    e.printStackTrace();
                }
            }
            return result;
        }

        public boolean delete(BorrowRecord record) throws SQLException {
           //还没写呢^_^,在这就省了吧。
            return false;
        }
    }
    </code>
    应用程序就使用由DAOFactory来返回接口的实例,代码如下:
    <code="java">
    BorrowItems itemDao = DaoFactory.getBorrowItemDao(dataSource);
    itemDao.insertBorrowRecordItem(item, borrower.getCertificate().getId());
    </code>
        问题来了,首先这样设计DAO方面与BO的关联太强,BO其中的属性改变会波及到DAO方面,不知道怎么来克服这个缺陷。
        其二就是在设计接口的实现的时候定义了SQL语句,但是每次设计DAO都不可能使用同样的SQL来对数据库进行操作,那么代码的重用性就很差,下次要是再开发个项目,还要从头写DAO,不过听说Hibernate是做持久层的,但是不知道其中的原理是什么,如何能克服仅仅因为SQL语句不同而要重新设计的问题。我原来想法是再加一层底层实现,就是实现CRUD,然后参数是一个SQL语句与一个参数列表,然后函数内部根据参数列表来决定如何使用SQL语句,不过只是个想法,不知道合理与否。大家给点意见吧。
    0 请登录后投票
       发表时间:2006-11-29  
    另外还有一点疑问就是,为没一个具体的实现功能的类上面都封装一个接口会不会影响效率?
    0 请登录后投票
    论坛首页 Java企业应用版

    跳转论坛:
    Global site tag (gtag.js) - Google Analytics