学习Design Pattern笔记

feiyang21687

浏览: 3733 次
来自: ...

最近访客更多访客>>

博主相关

博客

微博

相册

留言

关于我

文章分类

全部博客 (1)

社区版块

存档分类

2006-11 ( 1)
更多存档...

设计模式 DAO SQL 框架数据结构

软件可维护性能差的主要原因
[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 00:06
浏览 3733
评论(7)
论坛回复 / 浏览 (6 / 6340)
查看更多

7 楼 thinker 2006-11-29

关于设计模式，不敢发表评论，学习中...

6 楼 feiyang21687 2006-11-29

另外还有一点疑问就是，为没一个具体的实现功能的类上面都封装一个接口会不会影响效率？

5 楼 feiyang21687 2006-11-28

说个简单的例子，是我最近的一个练习。最近练习做一个基于WEB的图书馆管理系统，里面有一些对数据库的简单操作，所以就想到了用DAO模式来设计，下面就谈谈我对DAO的一些理解和一些疑惑。（我是用的是Struts架构，IDE使用的是Eclipse） 
<hr size='2' width='100%'/>
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语句，不过只是个想法，不知道合理与否。大家给点意见吧。

4 楼 hk109 2006-11-27

给我的感觉不要把设计模式看的太神拉，一切设计做到顺其自然，行云流水就足够拉！
3年前不知道到什么是设计模式；
2年前看不懂设计模式；
1年前在注意到设计模式；
现在发现原来没有以前那么多的开发设计经验，根本没办法理解设计模式！

盖大楼的壮工和建筑设计师是没办法靠设计模式来交流的！

3 楼 mouse_xb 2006-11-27

过于脆弱：修改一处可能波及到很多其他的地方
黏度过高：改动总是以破坏原始意图和原始设计框架的方式进行
这两点似乎差不多啊

2 楼 yr2008 2006-11-26

分析很好,最近也想研究一下

1 楼有思想的芦苇 2006-11-26

软件可维护性能差的主要原因:

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

这四点总结得不错,简明扼要.

发表评论

您还没有登录,请您登录后再发表评论

最近访客更多访客>>

博主相关

文章分类

社区版块

存档分类

最新评论