编程中，相较于OOAD设计工作而言，编码实现是个次要问题。
设计过程就是抽象归纳的过程。大抵有两种模式：
一是传统以数据模型驱动的设计思路，其特点是拿到一个需求，分析出一些基本的实体和关系（ER图）然后就去设计数据库和表关联了，这样做的好处就是建模速度快，缺点是实体类往往被数据库表牵着走，沦为数据模型的载体；由于着眼点偏于底层，没能从领域对象层面去抽出事物的本质，一旦需求发生变化，其维护和扩展性差。
二是OO思想，从业务需求分析领域模型，不去考虑持久化层面等问题，怎样存储和存储在哪不是设计阶段要考虑的问题，只是从对象和对象关系进行建模。其特点是好的类抽象设计，已经就能通过类（包括接口）之间的关联关系进行协作，在业务逻辑上实现功能需求了。数据库要跟着对象动。
由OOAD或DDD再到OOP等理念，就是看到需求是不稳定的这一问题，其精髓是从企业不稳定的需求中分析出稳定的对象，以企业对象为基础来组织需求、构架系统。一旦需求变化，只需要将稳定的企业对象重新组织就可以，这样抽象出的对象就是common bussiness object。
比如我做过一个需求，是要实现对停车场设备部署作业的开局登记，登记后可以从系统上导出excel表，这样施工人员可拿着表格去现场对照着作业（当然也可以现场登录系统查看）。在我没有oo的意识之初，我竟然天真的去根据同事提供的历史开局表格的表头进行抽象。后来一想，表格是哪来的？是从线上导出的！线上的信息是哪来的？是从数据库拿的字段！数据库字段是哪来的？是经由映射的实体类，从前台的vo传过来的！那么表格内容制式、表头要是变了呢？岂不天下大乱！所以我们都知道开发流程是需求分析->概要设计->详细设计->编码实现->测试->部署上线->运维,一旦设计工作本末倒置，或者囫囵吞枣其危害就是“基础不牢地动山摇”。这也再次印证OO的思想是力求抽象出好的静态领域模型，因为其具有相对的稳定性，能够良好的支持可维护性和可扩展性。
在实操层面，类的设计是没有标准的。十个人可能有10种不同的类设计。但要抽象和封装的恰到好处，这些类才好用。在什么粒度上抽象，类属性是否要引用其他实体类都值得推敲，诚然这是吃经验的，我在不断体会学习中。总之，设计要好好去做；但也没必要完全想清楚再编码，事实上也很难完全想清楚，总要有个迭代修改的过程。我觉得，可以先把所有名词和所有动作都简单粗暴的归纳出来，不怕细碎；动作归到接口类中，名词就先遍历抽象出各个类和域，名词（属性）和动作（功能）的抽取除了显而易见的因素之外，还可以按照5w1h来检核；最后考量实体类对业务的支持，不必要抽象的属性再进行合并到其他类里就可以。
接下来，便是界面草图设计和后端接口的进一步详细设计了。那么先写前端还是先写后端呢？我理解，上述的类图设计里，对象和功能已经具备一定的完备性了，或者说已经把整个业务需求做了粗粒度的实现。这时做完实体类编码和ORM映射数据库之后，仍然会发现前端一团麻，后端也无从下手的感觉。其实，前端界面设计和后端详细的接口设计，都不是分立的，而是统摄于更细化的需求分析了。这就是详细设计阶段，该阶段已经接近于编码实现，但此时仍然不急于编码实现，仍然可以停下来继续画更细粒度活动图，时序图，状态机等把需求屡清楚；高手所谓的编码不需要走脑子、编码的感觉等，吃的就是这块的经验；当脑袋里有足够多的业务模型积累时，自然就下笔如有神了。但建议像我一样，还没有达到那个层次的朋友，不妨以退为进，慢就是快，避免南辕北辙。
