写一段文字描述程序要完成什么样的功能，然后将这段文字的名词转换成类或者类的属性，将动词转换成类的方法。这是80年代中期的经典做法。
<<设计模式解析>> 2nd 开篇就说，上述方式有局限性，因为只关注了如何实现对象，是不完整的解决方案。或许只应该是解决方案中的一部分。
我目前的做法是，仍然用一段文字来描述程序要完成什么样的功能，根据自己的经验（当然也包括名词和动词分析法）写出调用代码，然后再慢慢实现每个类。我这个方法有个出处，源自于Bob的敏捷软件开山之作里面描述的测试驱动编程。他的原意是写一个Unit test，然后慢慢的实现所有的类和方法，最终让Unit test通过。但是很多时候，Unit test并不那么容易建立，画UML里面的时序图感觉代价比较高，我更愿意通过代码来讲述故事大纲，就像写作文先写提纲一样。
举个例子：用户登录网站，如果用户名、密码、验证码都正确，可以登录。在这个后台验证程序逻辑里面，我用如下代码将故事大纲先写好：
User user = UserManager.login(id,password,authenKey);
if(user!=null){
log.info("User logs into web site successfully");
}
然后实现细节在UserManager类里面逐层展开，要做如下工作:
1)检查验证码
2)通过SHA256算法，计算密码是否正确
3)如果验证通过，创建User对象，里面包含了用户信息，并返回
4)错误处理，如果验证失败，则抛出异常告知哪种错误，错误可能有几种，比如验证码错误，用户名或者密码不正确。
由于有错误处理，所以调用代码修改为：
try{
User user = UserManager.login(id,password,authenKey);
log.info("User logs into web site successfully");
//do something for correct user
}catch(LoginException ex){
log.error(ex.getMessage(),ex);
//do something for wrong authentication
}
然后就开始实现User,UserManager,LoginException类。可能还需要一个类来处理验证码,一个类来处理SHA256算法。
在设计类的时候，尽量遵守单一职责原则，组合优于继承原则等等。后面会继续谈到。
我自己概括我的方式为：需求驱动编写自顶向下的代码。这种方式的优点是细节将被逐层展开，容易把握大方向，避免一上来被细节牵着走，写出复杂而难以维护的代码。而且避免了绘制UML图带来的高成本，慢进度。用程序来讲故事，是非常自然的事情。不过这种方式必须结合不断的重构，可能由于特殊的需求引入一些算法和模式，改变了故事大纲。一个程序的代码，就像一个生命体，是不断演化，甚至积累到一定程度和初始面貌截然不同.