在设计模式和面向对象应用经验不足的情况下如何使程序稳定,可扩展(0分)

阿朱

Unregistered / Unconfirmed
GUEST, unregistred user!
这只是我个人在编程职业中零散总结的心得,希望对大家有所启发和借鉴
我对设计模式和面向对象的分析,设计,应用不是很灵活,所以我宁愿在角色,
角色的权责,工作内容,工作流程分析清晰的基础上用开发经验来弥补,使程序稳定,
可扩展,有效率。而实用,易用另有专人负责,不属于编码技术范畴
六个分离:
数据和流程
流程和界面
定义和实现
不变和变化
正常业务和异常业务
输入[输出]和输入[输出]校验
接口定义:
接口参数的定义,错误处理参照winapi的定义思想
两个模块[对象]之间交流太频繁,我会拿出两个中间模块[对象]专职交流充当通道,
防止通道双工破坏数据结构,如果双方通讯的内容差不多,我会创建一个中间模块,
对中间模块的公共数据,用get set来操作
另外软件之势,分久必合,合久必分,在定义层次时这是一个原则。平时我主要看看
windows框架和tcp/ip框架,有很多好想法由此产生,不妨大家试试
 
你的建议很有价值,不过我想问你一下,如何把业务逻辑中的类做到最大的抽象话
从而最大程度的实现代码的复用!
 
我的最终目标是结构清晰,改变灵活
复用,对象化都是手段,我用一个形象的比喻来解释
钢精结构-细节砖块-水泥粘合
太注意结构会使层次太多,中间关节太多,对于效率和编程都不好
太注意个体的封装会使结构很散,极端都是偏颇,但是我们一定不要忘了我们的目标
不管用什么方法,对我的开发团队适用并拿出有质量的产品是最主要的
 
有启发...
3x
 
结构如果清晰,维护性,可读性就好
接口定义灵活,扩展性就强
遵循合合分分单向依赖的层次思想就层次分明,关系就不会变的复杂,错误也不会扩散
产品也就稳定了
我对对象应用的不多,一般函数较多,函数有两个作用,一个是重用,一个是理清思路
函数一般在80-100行之间,多于100行,就分出一个小函数,如果一个函数小于30行,
我就不会使其成为一个函数,如果它为了重用也可以是一个函数,但重用必须在3次以上。
这样函数粒度大了,可读性就不好,扩展也不灵活。函数粒度小了,可读性也不好,扩展是
灵活,但可维护性差了,因为太多的函数跳转,让你跳的头痛。其实划分对象粒度也是
这个指导思想。
一般拿到一个业务描述说明,我先找到关键词,关键流程点,关键人,然后在每个关键
流程点阶段进一步分解,把数据和流程分开,我会最后把流程和界面连一起,进行输入输出
编码
作为一个代码员:结构清晰,接口灵活,层次分明,产品稳定,可维护,可读,可扩展
我想这正是商业开发中需要的合格的代码员了
记住一句话:开发工具和开发技术,面向对象,组件体系只是实现客户需求的一种手段,
我们可以通过各种方式来满足客户的种种需求,不一定非是技术,也就是说,一切都是手段,
达到目的就可以了,希望大家在研究技术的时候不要本末倒置
 
再废话一篇:
这是我对新程序员的几个素质要求
基本要求
怎么模仿用户体验用户需求
怎么写文档让下一个流程的角色看懂
怎么交流让下一流程的角色听懂
怎么写代码结构清晰,可读,可扩展
优秀程序员要求
总结各个相似产品的共性 如COM VS。CORBA
借鉴经典产品结构和写法,如DELPHI
听取研究领域领导人的思想
快速抓住中心的分析问题方法
怀疑态度
写应用行业软件的技术基础
数据库 数据库访问接口,如ADO ODBC
操作系统
TCP/IP
对开发工具和语言,组件体系我不严格要求,因为一个勤奋和有以上技术基础的程序员,
这些都会很快适应和掌握,现在很多新思想都是对低层的一个包装和整合,或是另一种观察
角度,使结构更易于应用开发和扩展,本质并没有质的变化。
 
耳目一新,请大侠继续。。。
 
难道中国的软件都是“业务”“企业逻辑”之类的东西吗
 
接受答案了.
 

Similar threads

S
回复
0
查看
3K
SUNSTONE的Delphi笔记
S
S
回复
0
查看
2K
SUNSTONE的Delphi笔记
S
D
回复
0
查看
2K
DelphiTeacher的专栏
D
顶部