建模原语:四象图

11-08-27 jdon007
建模原语:四象图

作者:achieveidea@gmail.com

命名:模型、结构特征、行为特征、场景(及其规约)。

释义:
模型,描述事物为一组时间函数,蕴藏了与事物相关的所有事实。
特征,从模型上剥离的一组时间函数。特征分为两大类,一类是结构特征,一类是行为特征。
场景,模型凝聚相应的特征持续一段时间,描述一段时间内与模型相关的事实。场景中隐藏的一些规则、约定,称之为场景规约。

用法:
一笔一纸,一横一竖,四象顿生。
一象画景,三象画物,物在景中。
二象画形,四象画神,形神兼备。
万象入画,浑然一体,一目了然。

注:第一象限画景,即描述场景;第三现象画物,即描述模型。第二现象画物之形,即描述模型的结构特征;第四象限画物之神,即描述模型的行为特征。


诸子百家:
如果你熟悉四色原型,DESC可理解为结构特征,PPT可理解为模型,Role可理解为行为特征,MI可理解为场景。
如果你熟悉DDD, VO可理解为结构特征,Entity可理解为模型,Aggregate可理解为行为特征,Service可理解为场景, Specification可以理解为场景规约。
如果你熟悉DCI,D可理解为模型,C可以理解为场景,I可以理解为行为特征。
如果你熟悉MVC, M可理解为模型,V可理解为结构特征,C可理解为行为特征。
如果你熟悉Web,HTML可理解为模型,CSS可理解为结构特征,JS可理解为行为特征,“页面”可理解为场景,HTTP可理解为场景规约, URI可理解为场景的命名。
如果你熟悉Database, Table可理解为模型,View可理解为结构特征,Trigger可理解为行为特征,“增删改查”可理解为场景,SQL(关系代数)可理解为场景规约。

如果你对上述诸子百家的解释一无所知,恭喜你!你可能将在最佳的状态下,快速掌握四象图的精髓。

为了有一个感性的认识,以电影为隐喻。Actor(演员)表示模型,Props(道具)表示结构特征,Role(角色)表示行为特征,Script(剧本)表示场景。电影《英雄》中的陈道明是模型(演员),龙袍是结构特征(道具),秦始皇是行为特征(角色),刺伤秦始皇片段是场景(剧本)。
最后也会有两个简单的代码案例(都源自Jdon道友提出的案例),让你初步感受一下四象图的作用。

17
jdon007
2011-08-27 14:09
开放课题:
1)描述原语的具体语言
静态语言,动态语言?命令式语言,声明式语言?Web给我们树立了一个极好的榜样,模型使用HTML描述,结构特征使用CSS语言描述,行为特征使用JavaScript描述,场景规约使用HTTP描述,场景使用URI命名。事实上Android UI就汲取了Web的灵感,将UI的模型及结构特征使用XML描述。

2)特征剥离的方法
如果特征与模型使用同一种语言(比如Java),结构特征和行为结构的剥离需要付出额外的精力,比如前者侧重“一致性”,后者侧重“交互性”。而在Web中,结构特征和行为特征的剥离易如反掌。一致性要求画面在一段时间呈现相同的风格,这将给用户良好的界面体验的必要基础。CSS的设计者之一Bert Bos,解释了为什么CSS高度强调一致性。

Why “variables” in CSS are harmful?

3)特征凝聚的方法
模型凝聚特征,最简单的方法就是赋值。当模型具有复杂的结构特征时,可以使用“结构型”模式进行凝聚;当模型具有复杂的行为特征时,可以使用“行为型”模式进行凝聚。 凝聚特征的方法远不止赋值和GoF模式,比如JQuery中的selector、 Android中的R.java等等。

4)语言引擎的设计与实现
在不同的“系统”或“层次”之间,可能需要引入“语言引擎”这个概念,语言引擎的工作主要是协调两个说不同“语言”的“系统”之间的信息交流。比如Web应用的前端客户端说的是JavaScript语言,后端服务器使用是其它的语言(比如Java, PHP等)。Ajax(Asynchronous JavaScript and XML,由Jesse James Gaiiett发明)引擎负责两者的信息交流。Ajax的本意是通过JavaScript启动引擎,发送Request,异步接收以XML的数据格式返回的Response。现在XML已逐渐被JSON取而代之,因为相对于XML, JavaScript天生对JSON非常熟悉,是自家兄弟。

这里我修改Ajax的含义使其具有普适的意义。A = asynchronous, J = jabber, A = And, X = X。A 表示异步(同步是异步的特殊状态),Jabber的含义是“快而含糊不清的话”,X代表是任意对话者将的语言。

当某个层次或系统说的语言(Jabber),对于另一个层次或系统(使用X语言)而言可能就是“快而含糊不清的话(Jabber)”(我们多数人听老外讲话不就如此?老外听我们说话亦然!),此时就需要一个“语言引擎”进行翻译,使两者流畅地交流。语言引擎有两个工作模式:异步模式和同步模式。

对于Web UI来说,JavaScript为了自己的话能够被服务器(比如使用Java编写的服务器)听懂,使用Ajax语言引擎告知自服务器自己说了啥,要做什么。

对于Web Server(比如Java编写的服务器),为了Database能够听懂自己的话,知道自己想要些什么,做些什么,也需要构造一个Ajax引擎。语言引擎如果足够智能,可自动切换工作模式。比如在同步工作模式下,与SQL数据库建立会话;在异步工作模式,与NoSQL建立会话。

语言引擎的设计者需要具备精通数据库语言和服务器使用的语言,才可能建立通用的语言引擎。这个有能力的人可以考虑怎么实现,将其开源奉献给社区。 我目前是不知道啦。语言引擎不是Object/Relation Mapping,多多借鉴Asynchronous JavaScript and XML才是正道。

5)架构风格的设计与实现
Roy Thomas Fielding的博士论文《架构风格与基于网络的软件架构设计》是一篇极好的文章。李锟、廖志刚、刘丹、杨光的翻译也非常到位,感谢他们无私的奉献。我提出四象图的灵感部分(模型)源自于这篇论文对“资源”的定义,还有一部分灵感(特征)源于曾经对系统“特征向量空间”的痴迷。

Fielding在文中提及,“更精确地说,资源R是一个随时间变化的成员函数MR(t),该函数将时间t映射到等价的一个实体或值的集合,集合中的值可能是资源的表述和/或资源的标识符。”“REST对于信息的核心抽象是资源。任何能够被命名的信息都能够作为一个资源。”

在四象图中,Resource犹如“凝聚特征的模型”; Representational State表示“模型进入的场景”; State Transfer Protocol表示“场景的规约”;URI则是对“场景的命名”,其应绑定恰当的语义。

四象图与REST描述具有相似的“画面感”。 资源的表述性状态是一个持续一段时间的画面,状态转移协议切换各个画面。模型进入场景持续一段时间的画面,场景规约切换各个画面。两者之所以,具有相似画面感,是因为模型与资源的定义都是时间函数,是一个随着时间变化的概念。

体验与感受REST架构风格、四色原型、GoF设计模式,想象与其提出者进行交流,聆听、汲取其智慧,是我提出“四象图”的源泉。Web是一个成功的REST架构,运行了几十年。碰触Web,与接触TCP/IP协议栈、信号与系统、香农的信息论、机器学习一样,都令我感到震撼,开阔了原有的视野。

架构风格的设计与实现,我也是个在不断学习的初学者。之所以列出这个课题,是因为我觉得其非常重要,不可或缺。

6)程序之道:象数理
Niklaus Wirth提出公式“程序 = 数据结构 + 算法”,我认为这个公式少了一个东西,必须显现出来,即“模式”。古人有“象数理”之说,“象”在程序中抽象为“数据结构”,“数”抽象为“算法”,“理”抽象为“模式”。

“象”可以描述变量,过程,对象,函数,进程,事实,……,基于不同的“象”(数据结构),我们需要思考相应的“数”(算法),发现“象数”之后的“理”。这是无止境开放的课题,我们可能永远都无法找到永恒的真理。

建模原语和程序之道的来龙去脉,可以参考帖子《领域驱动设计之我见》《Hello, World! 我心中的道》,但那两个帖子充斥着混乱和错误,有时间可以了解一下,没有时间,看这个帖子就行了。这些是我提炼、加工后的结果。

提出“六大开放课题”,因为其与“四象图”在虚拟世界中的落实息息相关。有空我会写一些特征凝聚的代码例子,作为参考。uda1341的设计的作品完成差不多了,可让他普及一下程序之道这个课题出现的新方法论:Fact-Oriented Programming。

希望有更多的人,了解和使用四象图,并对随之提出的“六大课题”感兴趣,去研究和解决他们。

欢迎转载此文。最好注明原出处。
achieveidea@gmail.com

jdon007
2011-08-27 14:14
示例:

代码案例【1】电脑维修
四象图的模型:电脑

class Computer {
	private String username;
	private String boughtTime;
	private String price;
	private String brand;
	private ComputerConfiguration cc;

	public Computer(String username, String boughtTime, String price,
			String brand, ComputerConfiguration cc) {
		super();
		this.username = username;
		this.boughtTime = boughtTime;
		this.price = price;
		this.brand = brand;
		this.cc = cc;
	}

	// getter/setter
}
<p class="indent">


四象图的结构特征:电脑配置

class ComputerConfiguration {
	private String cpu;
	private String keyboard;
	private String hardDisk;
	private String memory;
	private String motherBoard;
	private String monitor;
	// getter/setter
}
<p class="indent">


四象图的行为特征:维修中的电脑

class ComputerInRepairing {
	private String reason; // 哪里坏了
	private String orderNo; // 订单编号
	private Date startTime; // 送来修理的时间
	private Date endTime; // 修理完的时间
	private String chargedPrice;// 收费价格
	private String repairer; // 修理人
	private Computer computer;

	public ComputerInRepairing(Computer computer) {
		this.computer = computer;
		this.startTime = new Date();
	} // getter/setter
}
<p class="indent">



四象图的场景规约:收费策略

class ChargeStrategy {
	public String repairHardDisk() {
		return "50$";
	}

	public String repairMotherBoad() {
		return "20$";
	}
}
<p class="indent">


四象图的场景规约:场景

class RepairComputer {
    private ChargeStrategy strategy;  // 收费策略       

	public void repair(ComputerInRepairing c) {
            // repaire the computer
            // charge to customer
	}
}
<p class="indent">

[该贴被jdon007于2011-08-27 14:16修改过]

jdon007
2011-08-27 14:17
代码案例【2】图书馆借阅图书

四象图的模型之一:书

public class Book {
	private String serialNo;
	private String name;	
	private BookCounter counter;	

	public Book(String name, String serialNo, BookCounter counter) {	
		this.name = name;
		this.serialNo = serialNo;
		this.counter = counter;
	}

	public String getSerialNo() {
		return serialNo;
	}
	
	public String getName() {
		return this.name;
	}

	public boolean hasStock() {
		return counter.hasStock();
	}

	public int getCount() {
		return counter.getCount();
	}
	
	public int incrementCount() {
		return counter.incrementCount();
	}

	public int decrementCount() {
		return counter.decrementCount();
	}
}
<p class="indent">


从“一致性”的角度,将“模型”的“结构特征”剥离出来。
四象图的结构特征:书的计数器

public class BookCounter {
	private int total; // total 
	private int count; // count in stock

	public BookCounter(int total) {
		this.total = total;
		this.count = total;
	}

	public int getTotal() {
		return total;
	} 
	
	public int getCount() {
		return count;
	}
	
	public boolean hasStock() {
		return count == 0 ? false : true;
	}

	public int incrementCount() {
		return count++;
	}

	public int decrementCount() {
		return count--;
	}
}
<p class="indent">


从“交互性”的角度,将“模型”的“行为特征”剥离出来。
四象图的行为特征:被借/已借的书

public class BorrowedBook {
	private String username;
	private Book book;	
	private Date borrowedTime;
	private Date returnedTime;

	public BorrowedBook(Book book) {
		this.book = book;			
	}
	
	public String getUsername() { return username;}
	public Book getBook() { return book; }
	public Date getBorrowedTime() { return borrowedTime; }
	public Date getReturnedTime() {	return returnedTime; }

	public void setUsername(String username) { this.username = username; }
	public void setBorrowedTime(Date borrowedTime) { this.borrowedTime = borrowedTime; }
	public void setReturnedTime(Date returnedTime) { this.returnedTime = returnedTime; }
}
<p class="indent">



四象图的模型之二:账号

public class Account {
	private String username;
	private AccountType accountType;
	private List<BorrowedBook> borrowedBooks;

	protected Account(String username) {
		this.username = username;
		this.borrowedBooks = new ArrayList<BorrowedBook>();
	}

	public BorrowedBook borrowBook(Book book) {
		BorrowedBook borrowedBook = new BorrowedBook(book);
		borrowedBook.setUsername(username);
		borrowedBook.setBorrowedTime(new Date());
		borrowedBooks.add(borrowedBook);
		return borrowedBook;
	}

	public Book returnBorrowedBook(BorrowedBook borrowedBook) {
		Book book = borrowedBook.getBook();
		borrowedBook.setReturnedTime(new Date());
		borrowedBooks.remove(borrowedBook);
		return book;
	}

	public List<BorrowedBook> borrowBooks(List<Book> books) {
		for (Book book : books) {
			borrowedBooks.add(borrowBook(book));
		}
		return borrowedBooks;
	}

	public List<Book> returnBorrowedBooks(List<BorrowedBook> borrowedBooks) {
		List<Book> books = null;
		if (this.borrowedBooks.removeAll(borrowedBooks)) {
			books = new ArrayList<Book>();
			for (BorrowedBook borrowedBook : borrowedBooks) {
				books.add(returnBorrowedBook(borrowedBook));
			}
		}
		return books;
	}
	
	public AccountType getAccountType() {
		return accountType;
	}

	public List<BorrowedBook> getBorrowedBooks() {
		return borrowedBooks;
	}
}
<p class="indent">



从“一致性”的角度,将“模型”的“结构特征”剥离出来。
四象图的结构特征:账号类型

public enum AccountType {
	TEARCHER, STUDENT;
}
<p class="indent">


为了保证账号的唯一性,使用单例工厂创建账号。

public class AccountFactory {
	private static Map<String, Account> accounts = new HashMap<String, Account>();

	private AccountFactory() {
	}

	public static synchronized Account getAccount(String username) {
		if (!accounts.containsKey(username)) {
			accounts.put(username, new Account(username));
		}
		return accounts.get(username);
	}
}
<p class="indent">



四象图的模型之三: 图书馆

public class Library {
	public static Map<String, Book> books = new HashMap<String, Book>();

	public static Map<String, Book> getBooks() {
		return books;
	}

	public static void setBooks(Map<String, Book> books) {
		Library.books = books;
	}

	public static Book takeBook(String serialNo) {
		Book book = books.get(serialNo);	
		if (book.hasStock()) {
			book.decrementCount();
			return book;
		} 
		return null;
	}

	public static void putBook(String serialNo) {
		Book book = books.get(serialNo);	
		book.incrementCount();
		books.put(serialNo, book);
	}
	
	public static int getCount(String bookName) {
		int count = 0;
		Collection<Book> _books = books.values();
		for (Book book : _books) {
			if (book.getName().equalsIgnoreCase(bookName)) {
				count = book.getCount();
				break;
			}
		}
		return count; 
	}	
}
<p class="indent">

jdon007
2011-08-27 14:20
代码案例【2】图书馆借阅图书

四象图的场景之一:借书

public class BorrowBookContext {
	public List<BorrowedBook> borrowBooks(Account account, List<String> serialNos) {
		List<BorrowedBook> borrowedBooks = new ArrayList<BorrowedBook>();		
		for (String serialNo : serialNos) {
			borrowedBooks.add(borrowBook(account, serialNo));
		}
		return borrowedBooks;
	}

	public BorrowedBook borrowBook(Account account, String serialNo) {
		Book book = Library.takeBook(serialNo);
		return account.borrowBook(book);
	}
}
<p class="indent">



四象图的场景之二:还书

public class ReturnBookContext {
	public void returnBorrowedBooks(List<BorrowedBook> borrowedBooks) {
		for (BorrowedBook borrowedBook : borrowedBooks) {
			returnBorrowedBook(borrowedBook);
		}
	}

	public void returnBorrowedBook(BorrowedBook borrowedBook) {
		Account borrower = AccountFactory.getAccount(borrowedBook.getUsername());
		Book book = borrower.returnBorrowedBook(borrowedBook);
		Library.putBook(book.getSerialNo());
	}
}
<p class="indent">


四象图的场景规约:借阅规则

简单起见,两个场景没有使用借阅规则。更完善的实现,借阅规则应作为场景的前置条件和交互过程中的约束条件。

场景规约是领域的灵魂,模型是领域的躯体。场景规约代表业务规则。在领域的各个场景中,灵与肉本应合为一体。

没有场景规约(业务规则)的模型,在场景中犹如行尸走肉。考虑到游戏《植物大战僵尸》的火爆,这里且让模型的灵魂脱壳。^_^

public class BorrowingTerms {
	private static final int LIMIT_OF_BOOKS = 5;
	private static final long LIMIT_OF_DAYS = 30;
	private static final int LIMIT_OF_STOCK = 1;
	private static final double UNIT_OF_PENALTY = 0.1;

	// 账号是否借满书
	public static boolean checkAccount(Account account) {
		int borrowedBooks;
		borrowedBooks = account.getBorrowedBooks().size();
		return (borrowedBooks > LIMIT_OF_BOOKS) ? false : true;
	}

	// 书是否超期
	public static boolean checkBorrowedBook(BorrowedBook borrowedBook) {
		return (exceededDays(borrowedBook) == 0) ? true : false;
	}

	// 图书馆是否还有额外的库存
	public static boolean checkLibrary(String bookName) {
		int stockBooks  = Library.getCount(bookName);
		return (stockBooks > LIMIT_OF_STOCK) ? true : false;
	}

	// 超期的天数
	public static long exceededDays(BorrowedBook borrowedBook) {
		long borrowedDays, exceededDays;
		borrowedDays = (borrowedBook.getReturnedTime().getTime() - borrowedBook
				.getBorrowedTime().getTime())
				/ (24 * 60 * 60 * 1000);
		exceededDays = (borrowedDays - LIMIT_OF_DAYS);
		return (exceededDays > 0) ? exceededDays : 0;
	}

	// 一本书超期的罚款金额,1本书1天0.1元
	public static double getPenalty(BorrowedBook borrowedBook) {
		return exceededDays(borrowedBook) * UNIT_OF_PENALTY;
	}
	
	// 多本书超期的罚款金额
	public double getPenalty(List<BorrowedBook> borrowedBooks) {		
		double penalty = 0;
		for (BorrowedBook borrowedBook : borrowedBooks) {
			if (BorrowingTerms.checkBorrowedBook(borrowedBook)) {
				penalty += BorrowingTerms.getPenalty(borrowedBook);
			}
		}
		return penalty;
	}
	
	// 此账号是否可以借此书	
	public static boolean canBorrowBook(Account account, String bookName) {	
		if (!BorrowingTerms.checkAccount(account))
			return false;
		if (!BorrowingTerms.checkLibrary(bookName))
			return false;
		for (BorrowedBook borrowedBook : account.getBorrowedBooks()) {
			if (!BorrowingTerms.checkBorrowedBook(borrowedBook))
				return false;
		}
		return true;
	}
}
<p class="indent">

jdon007
2011-08-27 14:37
// 测试用例

public class UseCase {
	public static void showLibarayInfo() {
		Collection<Book> books = Library.getBooks().values();
		System.out.println("----------- Libaray----------------");
		for (Book book : books) {
			System.out.println("{" + book.getName() + ": " + book.getCount() +"}");
		}
		System.out.println("-----------------------------------");
	}
	
	public static void showAccountInfo(Account account) {
		List<BorrowedBook> books = account.getBorrowedBooks();
		System.out.println("----------- Account----------------");
		for (BorrowedBook book: books) {
			System.out.println("{"+book.getBook().getName()+"}");
		}
		System.out.println("-----------------------------------");
	}
	
	public static void initLibaray() {
		Map<String, Book> books = new HashMap<String, Book>();
		books.put("001", new Book("Jdon Framework", "001", new BookCounter(10)));
		books.put("002", new Book("Spring Framework", "002", new BookCounter(20)));
		books.put("003", new Book("Guice Framework", "003", new BookCounter(30)));
		Library.setBooks(books);
	}
	
	public static void main(String[] args) {		
		initLibaray();	
		
		// 0 图书馆里找书
		List<String> serialNos = new ArrayList<String>();
		serialNos.add("001");
		serialNos.add("002");
		serialNos.add("003");
		
		// 1 持卡借书
		Account jobs = AccountFactory.getAccount("Steve Jobs");
		
		// 1.1) 借书之前
		System.out.println("【0】 Before Borrowing Books");
		showLibarayInfo();
		showAccountInfo(jobs);
		
		// 1.2)借书
		BorrowBookContext borrowService = new BorrowBookContext();		
		List<BorrowedBook> borrowedBooks = borrowService.borrowBooks(jobs, serialNos);
		// 1.2)借书之后
		System.out.println("【1】After Borrowing Books");
		showLibarayInfo();
		showAccountInfo(jobs);
		
		// 2  阅读借来的书,读完时就该还书了。
		System.out.println("\n【2】 ******** Steve Jobs is reading books! ********\n" );
		
		// 3 无卡还书
		// 3.1) 还书之前
		System.out.println("【3】 Before Returning Books");
		showLibarayInfo();
		showAccountInfo(jobs);
		
		// 3.2) 还书, 
		ReturnBookContext returnService = new ReturnBookContext();			
		returnService.returnBorrowedBooks(borrowedBooks);		
		
		// 3.3) 还书之后
		System.out.println("【4】After Returning Books");
		showLibarayInfo();
		showAccountInfo(jobs);
	}
}
<p class="indent">


// 运行结果
【0】 Before Borrowing Books
----------- Libaray----------------
{Jdon Framework: 10}
{Spring Framework: 20}
{Guice Framework: 30}
-----------------------------------
----------- Account----------------
-----------------------------------
【1】After Borrowing Books
----------- Libaray----------------
{Jdon Framework: 9}
{Spring Framework: 19}
{Guice Framework: 29}
-----------------------------------
----------- Account----------------
{Jdon Framework}
{Spring Framework}
{Guice Framework}
-----------------------------------

【2】 ******** Steve Jobs is reading books! ********

【3】 Before Returning Books
----------- Libaray----------------
{Jdon Framework: 9}
{Spring Framework: 19}
{Guice Framework: 29}
-----------------------------------
----------- Account----------------
{Jdon Framework}
{Spring Framework}
{Guice Framework}
-----------------------------------
【4】After Returning Books
----------- Libaray----------------
{Jdon Framework: 10}
{Spring Framework: 20}
{Guice Framework: 30}
-----------------------------------
----------- Account----------------
-----------------------------------

// 附件,文档和源码。

attachment:

notes.doc
domain.rar

oojdon
2011-08-28 16:45
007,可以不可以这样表达:



我认为模型可能还具备一个本质的结构和行为,就像数学中的公理,基于这个公理在各种场景中演化出定理。

jdon007
2011-08-28 17:58
2011年08月28日 16:45 "@oojdon"的内容
可以不可以这样表达: ...


今天出去游玩了,刚回来。

我很高兴,因为我认为你已经掌握了四象图的精髓。

你的坐标图,把“时间”概念作为一维凸显出来,这是四象图的强调的一个重点。因为时间是变化的前提,且不以人之意志为转移。如果你在时间一维上再画出一个区间,随之再画出相应一个场景,可能看起来会更清晰一些,当然简洁性有所降低。

所谓公理,无非是形式化的、具有普适性的常识而已,不证自明。我说这话,不是说公理的形式化表述很简单(其形成过程一般是颇费周折的),而是说公理的特点:形式化、普适性。

四象图也许做不到这点,但至少是朝这个方向思考的。

模型具有“基本”的结构和行为(或称之为基本事实),但这个“基本点”的定义会受到我们具体目标和需求的影响。

模型的“基本事实”未必是模型的“本质”,但与公理有相通之处,在此基础之上,我们进行演绎推理,产生各种场景。

公理 != 本质,大家都认可的道理、常识,未必是模型的本质。

对于本质,我的态度与古今中外一些人的态度基本一致。

老子:道可道,非常道。
康德:用人类理性发明的语词只能谈论现象,不能谈论世界的本质。
维特根斯坦:凡不可说的,应当沉默。

SpeedVan
2011-08-29 12:49
我认为模型谈不上时间,而是在对象空间中谈时间(banq以前也有过这样的观点:时间和空间都是需要考虑的,但我们先放下其中一个考虑问题,然后再谈论这一个。其中谈论空间的如结构,谈论时间的如生命周期等)。

关于“本质”,我想,没有一个家伙会不联系领域来,独自创造出对象。不同领域有不同BOOK的角度,懂得从业务出发,从领域出发的,就不会产生这样的问题。即使说出本质,也是一个“局限性”的本质。

>>模型的“基本事实”未必是模型的“本质”。
<<注意模型也是我们的想象物,我认为我们一直在做的是构造一个以这些“基本事实”为本质的模型。这个本质是对模型而言,而非世界。而我们所谈模型的本质,可以说就是这些有限的事实。本质的认识来源于事实,如本质属性。

我对本质的看法是:超越人类认识的本质是不可言的。简单例子就是“世界当中的人谈世界本质”。

mistbow
2011-08-31 07:51
jdon007大牛,可不可以用Ruby再写个DCI的例子,学习学习啊。先谢过O(∩_∩)O~

banq
2011-08-31 09:34
2011年08月31日 07:51 "@mistbow"的内容
jdon007大牛,可不可以用Ruby再写个DCI的例子 ...


翻墙看:DCI与Rails

SpeedVan
2011-08-31 15:42
2011年08月31日 09:34 "@banq"的内容
翻墙看:DCI与Rails ...


文中“we don't do object oriented programming but we do class oriented programming”,看来理解DCI后,才是OO的开端。

jdon007
2011-09-01 22:31
2011年08月31日 07:51 "@mistbow"的内容
Ruby再写个DCI的例子 ...


1) http://andrzejkrzywda.com/

class Human
  attr_accessor :address
end

class Address
  def to_s
    "City: #{@city}"
  end
 
  private

  def initialize(city)
    @city = city
  end
end

module Policeman
  def check_address(address)
    # do some stuff
  end
end

module Thief
end

module FakeAddress
  def to_s
    "City: LA"
  end
end

class ArrestContext
  def execute
    @policeman.check_address @thief.address.to_s
  end

  private
  
  def initialize(policeman, thief)
    @policeman = policeman
    @policeman.extend Policeman

    @thief = thief
    @thief.extend Thief
    @thief.address.extend FakeAddress
  end
end

policeman, thief = Human.new, Human.new
thief.address = Address.new 'NY'

context = ArrestContext.new policeman, thief
context.execute
<p class="indent">


2) https://github.com/anachronistic/DCI-Rails-Example

这是网络上的两个例子,你可以看看,不用翻墙。第一个例子是“警察抓小偷”,第二例子我没看。

“警察抓小偷”例子中的人扮演警察与小偷可形象说明扮演角色。不过Address扮演Fake Address,我觉得有些牵强。建议看看“The Common Sense of Object Orientated Programming”一文,Trygve Reenskaug较为详尽地阐释其提出的两大范式:MVC和DCI。

tangxuehua
2011-09-05 22:41
最近终于稍微有点空了,

jdon007,看了你这个帖子中提到的理论和例子,我有很多问题想确认:

1)问题一:
2011年08月31日 07:51 "@jdon007"的言论
// 3.2) 还书,
ReturnBookContext returnService = new ReturnBookContext();
returnService.returnBorrowedBooks(borrowedBooks ...

BorrowedBook是行为特征,在你的例子中,因为过于简单,borrowedBooks没有从某个持久化层获取;而真正的系统,当你要还书时,borrowedBooks肯定要从某个持久化层(比如数据库)获取的。如果要这样,你会如何做呢?如何在还书之前获取borrowedBooks?按照我的理解Book是模型,BorrowedBook是角色,即你说的行为特征,而Eric Evans的DDD理论中的Repository是针对Aggregate的;之前你说过,行为特征相当于DDD中的Aggregate,所以,是否意味着BorrowedBook应该从一个名叫BorrowedBookRespository的仓储去取呢?因为据我了解Repository都是针对Aggregate的,而据你所说,Aggregate相当于行为特征;按照这样理解的话,是不是意味着单独的Entity,即你所说的模型就无法被持久化或重建了呢?有这个疑问的原因是你并没有提到关于如何持久化/重建 模型或行为特征。我相信有很多情况模型是没有参与任何业务场景(即不需要扮演任何角色,也就是你所说的凝聚行为特征)就会被持久化或重建的;

2)问题二:
我无法理解并且感觉很别扭的一点是,为什么模型Book会知道自己还有多少本库存?即Book为什么会具有一个BookCounter?我觉得你一味的强调如何建模,而忽略了建模最重要的思想,那就是一切建模结果要能体现业务,任何属性或职责的分配要完全根据业务需要来。在我看来,Book就是Book,它怎么知道自己现在还有多少本在书架上,只有图书馆在清楚某本书目前还有多少本库存。试想一下,如果某本Book被借走了,但是Borrower却能通过这本Book知道目前图书馆还有多少本这个书的库存,那是不是有点可笑?现实生活中,如果要查询某本书在图书馆还有多少本可存,必须要通过图书馆才能查询得到;

3)问题三:
我觉得你对一件事情不太重视,那就是属性的只读问题,如果真正地在对业务进行建模,那应该深刻了解业务需求,比如被借的书(BorrowedBook)的借书人和借书时间这两个信息是随着BorrowedBook的被创建而诞生的,并且最重要的是这两个信息也从此不可能被修改,但你却给这两个信息提供了set,这意味着我可以随便随时修改这两个信息,这就会导致领域模型的业务逻辑不安全,不可控;真正的领域模型不仅能表达业务实体,业务规则,以及业务实体之间的交互,从而帮你做事情;更重要的一点是,它一定是业务安全的,即你无法利用它来做任何违反业务规定的事情,否则这样的领域模型即便设计的再好也是非常危险的;所以,我觉得你在设计模型或角色时,对于构造时初始化属性还是提供Set来初始化属性方面还需要注意,不能太随便;

4)问题四:
记得之前你最早的版本中,是有图书卡的,即Card,而现在的模型中没有了Card,取而代之的是Account,即帐号,这两者是同一个意思吗?如果是,那么Account和用户之间的关系是什么样的?是不是多对多的关系,即一个用户理论上可以使用多个Account登录,然后做借书或还书的事情;同一个Account理论上也可以被不同的用户使用,只要那些用户知道该帐号的使用密码权限;也就是说用户和Account是使用者与被使用者的关系,而这个关系正式用户和Card之间的关系;用户是系统使用者,是行为驱动者,Account是行为拥有者;我是不是可以理解为你正是由于理解了这一点才把原来的Card替换为了Account呢?

5)问题五:
记得之前你谈到过,Account即是模型,也是角色;并且你说过只有角色才可能有交互行为的,模型拥有的是非交互的行为;在你这里最新版本的图书借阅的例子中,Account拥有了借书和还书的行为,这两个是交互行为;但是你说Account是模型,而非角色,即你所说的行为特征,那是不是有点问题呢?是不是应该分开,即搞一个Account模型,它没有借书和还书的交互行为;再搞一个Borrower角色,它有借书和还书的行为;这样是不是更严谨,更符合你所提到的建模理论呢?

6)问题六:
如果真的要分行为特征或角色的话,那为什么“被借的书”(BorrowedBook)的还书时间也属于这个“行为特征”或角色呢?按照我的理解,我会觉得很奇怪,因为被借的书不应该也不需要存储还书时间这个信息,在还书场景中,没有“被借的书”这一行为特征,而只有“被还的书”这一行为特征,并且“被还的书”才应该具有还书时间这个信息,这样才对称,才准确地不多不少地符合角色所表达的含义。你是不是觉得这样会导致角色泛滥而直接把还书时间也放在BorrowedBook这个“行为特征”上呢?如果是这个原因,你能说一下何时该创建角色,创建角色的度在哪里吗?


暂时只想到这些问题了,我说话的态度可能不是太客气,请不要见怪,我没有任何针对您的意思,呵呵。

[该贴被tangxuehua于2011-09-05 22:57修改过]

[该贴被tangxuehua于2011-09-05 23:00修改过]

jdon007
2011-09-06 01:18
一、
DDD的Aggregate,“聚合”之意,可以理解为“模型凝聚行为特征”后的角色,但这很勉强,之前我说过。
DDD我看了一段时间,但现在基本上为四象图所替代,记不太清楚了。
如果没有记错,Repository应该是针对Aggregate, Entity, Value Object。
行为特征(borrowedBook),在图书管这个例子中,表达了交互的事实,“谁”何时“借(还)”了何“书”,可持久化。
模型(book),表达了基本的事实,图书馆里存放着那些书,可持久化。
结构特征(bookCounter),表达了书的一些数量信息,也可以持久化。
在我看来,场景也可以持久化,审批流就是一个例子。

三种事实的变化频率(访问或更新频率)不同,在数据库中可以设计三张表来表示。可以通过视图来提高关连查询的性能。

二、
比如,某书总共有几本,被接走了几本,剩下几本,都是数量信息,表达为结构特征。
计数器,可理解为书使用的道具,用来计量自身的一些信息,就像在炸药上安装的计时器。

三、
借书时要记录借书时间,还书时要记录还书时间,setter是需要的。业务安全属于业务规则,用场景规约来控制。模型是自由的(需要setter就setter,不需要就拿掉,不能强求都不能setter), 如果没有业务规则的约束。

四、
Account和Card都是工具,在这里可以说互为映射,前者是虚拟之物,是现实之物。软件中用户使用Account借书,现实中用户使用Card借书。至于User是否可以有多个Account或Card,取决于业务规则。

五、
Account关注的基本事实,是其借了哪些本书,还了哪些些书,borrow和return只是记录这个事实而已。
Account参与交互时,其行为特征,在模型身上已经定义了,无需再定义。
除非Account有其他用途(存在截然不同的应用场景),才有必要调整其应该关注的事实。
比如Account也可以用来借钱,那么其应该关注的基本事实,即Account是谁使用的等信息即可。
Library的在此例子中与Account相似,基本事实已经包含了交互性质的事实。

现在HTML5(模型)可以也具有一些JS(刻画行为特征,交互性)的能力,这应该是更合理的设计。
从Web,而不是DDD、DCI、彩色UML,来理解四象图,会容易一些。因为一年前,实际上我对Web(背后的思想)几乎是一无所知的,所以关于它的一切对我都是新鲜的,影响也更大。

六、
借书与还书,是两个相对对立的场景,有各自的行为特征(交互的事实)。
但分离这两个事实意义不大,更有意义的是关注“借与还”这一相对完整的事实。
角色或行为特征创建的角度,主要是从交互性出发。

使用DDD,DCI, 彩色UML作类比,是因为我以为,在这里这些是对大家“更友好的术语”,“更容易接近我要表达的东西”,但也有可能让读者理解起来,浅尝辄止,甚而背道而去,非我所言。

oojdon其实很好地理解了我想表达的东西。

[该贴被jdon007于2011-09-06 07:21修改过]

猜你喜欢
2Go 1 2 下一页