最近好友在面向对象的设计思想切磋中发出一个疑问，当我在设计订座流程的时候，有个预定接口/seat/order，能不能直接应用在换订单/seat/reorder。我很干脆说不能，但是他说好的，第二天午睡后甩了这张图过来，呵呵，还挺不服气的:)
闲聊.png在他的观点看来，预定订单和修改订单本质上都是往后台发送订单数据，只是前者是仅仅带着商品信息，而后者还要多带一份已经生成的订单编号和待修改的商品信息即可。
对于面向对象来说，开宗祖师爷Alan Kay这么说的:"The best way to predict the future is to invent it"。
我的看法是从面向对象的角度来说，任务行为例如下订单、查看订单、修改订单等都是基于对象来做的，在商城系统中，需要有个顾客和商品对象，而下单行为是顾客发出的，和商品之间建立起多对多关系的过程，而这个订单对象的呈现就是这个关系的体现。那么对外呈现的时候，用户的想要下订单行为，需要通过addOrder来实现的，而修改订单则是通过updateOrder实现，addOrder应该是提供订单需要商品信息，后台根据商品信息生产对应的订单，而updateOrder需要提供的是订单的编号和商品信息来对订单信息进行修改，虽然创建和修改看起来差不多，可以经过适当提取有一小撮代码是相似的，可以复用，但这并不足以支撑成为接口可以复用的理由。毕竟使用方式和设计逻辑完全不一样，而这就是不能复用的根本原因。
回想自己在这两年的组件化设计的实践中也是这样，业务接口无论如何都不会被我复用，如果功能相似说明耦合度太高，设计不合理，要贯彻面向对象基本原则SOLID(单一功能、开闭原则、里氏替换、接口隔离以及依赖反转)。正常来说业务功能是由基础功能组装完成的，这一点在前端开发中尤为常见。比如说，对于一些运营平台，来说大致需要的元素是带翻页的表格和搜索框，其他的再根据需要定制而来，那么不妨把带翻页的表格和搜索框各自独立成基础模块
运营平台交互.png当模块独立完成之后，我们就可以像搭积木一样快速完成基础结构的搭建，之后才需要进行细致雕琢，如对css的控制，对传参和回调的管理等等，这些都是针对业务行为的具体开发。也就是所谓的抽象问题抽象解，具体问题具体分析。
代码语言：html复制 <div>
<Filter />
<Table />
</div>话又说回来，我们在写后端的时候，不管是Java也好Python也罢，我们不也是经常需要相关依赖包的协助嘛，重复造轮子的行为不管怎样都是浪费的表现，我们提取的组件本质上也是针对我们需要而进行高效代码开发的具体活动，也是另一种设计包的体现。
火车上闲来无事，谨以此文以记之
