想起来之前的时候,看到think in java 里边写的关于类和它的成员类,可以双向维护一个功能.
当时只是想着看上去确实是这样,书上说这是一个比较好的功能,我并没有看到那种特别好.
最近在做C#的一些项目,看着用框架的话,从前端接收的数据回被自动填装到action方法写明的类参数中,和类的成员变量名及类型相匹配.大概是把字符串转换成相应的类型并根据参数名匹配. 这个类一般只是一个接收参数的模型,里边有一系列成员和前端对应,除了get set 没有别的方法. 这里,如果需要去掉传递过来的参数的空格,trim()一下.这个操作可以在处理action的里边进行,也可以直接写进模型类里,直接模型类.trim()把所有需要去空格的参数都去一下.
去首位空的功能就很好地被关联到了模型类上,在action中调用这个模型类的方法就可以,看上去比较简洁好理解.这大概就是双向维护的意思:这个功能可以放在使用类的地方写,也可以封装到类里边到时直接调用.而且很容易找相应的处理,以后如果有变化的话也容易更改.
另一种情况,遇到的,是在使用类的方法中需要对临时类进行一系列处理,处理比较多,使用频次也比较多,于是在方法外单独写一个私有方法来处理,很多方法都可以用这个功能.如果这个功能和被使用的类相关性很强的话,比如传递的参数大多都和该类相关,可以直接把这个方法写进被使用的类中.这样就不用传一些和类相关的参数,直接传其它辅助参数就可以.调用起来也比较清晰.
之前被告诉 那些编程思想的书,不适合初学者.现在看来可能还真是这种情况.一般都是在编程中思考遇到问题,总结的一些问题该怎么处理,如果没有碰到过只能听个过场的样子.不过居然能让人还存有印象,应该也算是写的比较好了.
实际代码里我没有把"另一种情况"写进类里,直接在action里写了相应的功能.于是每个类似的action都粘贴复制一段代码.牵扯的东西有些多,有点改不动了,只是想到可以这样.
开发一天到晚在做功能,并不在乎性能,在乎快速实现,老板等着验收.如果短时间内没完成,基本上短时间内就被砍掉了.快节奏的变化里,没有时间去想编程的事.不是很容易遇到相关的讨论.
有些编码里还在讲究着这些,看一些前辈写的代码,做的功能.或许没有考虑这些事,只是被教会的习惯和规范.用最小的数据类型传递过网络,批量字符串拼接用辅助类而不是加号,相同的功能维护到一个方法中.其中有些讲究并不是不去做,是在有限的时间内做不到.想包装包方法就比较考验人.对功能的分类.
大概编码有实现功能和功能分类,把合适的代码放到相关的筐子里,程序就容易拓展维护.再加上有些习惯是对计算量的讲究,对运转性能的讲究,让代码看上去比较舒适.
写代码有一些顾虑,除了怎么实现功能,还有怎么把功能放到合适的位置方便拓展,怎么占用较小的计算和缓存资源来确保程序的健壮性.功能 分类 和精化.后两者不怎么影响开发,是一些有趣的思考的积累.另外加上业务功能的实现方式,也就是业务运转框架在软件中的组成实现方式.让编程显得既有困难,又有很广阔的探索空间.
很期望有更多机会去探索这个空间,可以让自己变得更强大,不依赖装备的情况下拥有更高的输出.