软件，很多写起来的时候讲究一些格式。不怎习惯去看那些方式和经验，因为没怎么遇到过使用场景，没有类似的思考。现在在编程中了，主要考虑怎么把功能分到合适的类里，或者仅仅是分配职责。
没怎么找到以自己想到的出发点进行的思考。于是自己写一些进行分析。
最近，比较开心的，是遇到一前辈，他说了一句话，把功能放到“一个”地方容易维护。场景是很多地方都要完成这个功能，而且根据场景不同功能有些细节的变化。更重要的是 是一块很大的功能，不是那么容易编排和移动。如果只是为了实现需求的话，可能就需要写在两三个地方。因为这个功能里边处理的事情比较多，后期有变动的话可能就要在“两三个”地方做改动。这份功能本来就很大，一个小改动就比较耗时或者说需要小心认真，如果每个小改动都要维护多份的话，就太头大了。
他说这话让我感受到一些，c++系的思考。比较透彻，这语言的分类就有些向简单直接地把 功能放到唯一一个地方，容易维护。如果是java 系的话，思考起来就更像是划分职责。这个职责归谁所有，然后把这个职责分配给它。不把它考虑成一个功能，考虑成一份职责。
在代码功能分配的初始，就划分好每一部分必须要完成的事情。也就是为什么需要这一部分，存在的必要性是什么。确定每一个区域的基本职责之后，再把需要完成的功能朝这些区域分配。更适合哪个区域就给哪个区域，这样再设计的初始就尽量避免让各区域出现重复的代码 重复的责任。
不过最根本，这样做的原因，也就是把 某种业务逻辑放到唯一一个地方，以后改动起来方便。
本来写程序就是想要达到更大程度这样。结合面向对象的话会有一个稍微清晰一些的思考，如果是c++系，偏向最简便的方式实现功能的话，可能就难一点。后者要求了更高的专业度和行业经验，思考量比较大。用面向对象 即职责划分的思维的话，显得比较容易一些。
做好分类，不用承载太多的计算量和代码逻辑量。至少会稍微优化一些。这是一种思想，最终目的也是和前辈的一样，放在同一个地方好维护。只是为怎么做到提供了一个理论参考的方法。
对功能进行职责划分，分到具体区域里去。对每个功能区域进行反思，思考它存在的必然性确定它的基本职责。两者结合。
另一个是数据库方面的例子，还没有思考很清。
都会遇到一个类似出库表或者收据表。承载普通收据上那些东西。有的存放方式是通用信息放一个表，收据上的每一项放另一个表然后和前者关联；也有存放方式是全部都放在一个表中，每一行数据都由通用信息和三条项目占用的空间组成。
前者，自己看到的一般都这样用，随着数据量的增多，两个表之间的关联情况会越来越 远。后者，有的场景在用着，这种更符合面向对象。面向对象的功能建模就是参考实际，这样会好一点。具体意思就是平时生活中收据都是这么用的，这样建立以后，平时生活对收据的各种操作也能比较简单的映射到编程中，不用做过多的思考。存放的是一个现实对象，不是一个为实现功能的拆分。至于三项不满出现空余，这个就不要紧了，生活中也是这样空余。
不过改成后者之后，发现另一个问题，检索。用单联的话检索一个特定商品，做统计就比较容易。做成多联的话，每个商品都需要在单条的三个条目中依次搜索。当然啦，生活中， 在还没有出现电脑取代的时候，都是存放在多联里，可能需要搜查的数据另外统计在另一个手写表里。只是在做的项目，如果改成多联的话model类和一些相关的东西也要改，于是一时没做起来。
从职责划分角度，做成三项存一条 多联 比较好。
总之，对对象进行职责划分和功能职责分配是比较好的方式。我在这方面还在学习和发现更多。