2,497
社区成员
发帖
与我相关
我的任务
分享討論：如何写出易维护和易扩展的程序?
欢迎大家讨论。
我感觉Delphi快速开发，在事件中写代码，很容易诱导我们写出，不易维护的代码！
大家都是如何改善的呢？
我感觉Delphi快速开发，在事件中写代码，很容易诱导我们写出，不易维护的代码！
大家都是如何改善的呢？
...全文
请发表友善的回复…
发表回复
snowflying928 2009-08-27
- 打赏
- 举报
[Quote=引用 32 楼 shuihan20e 的回复:]
菜鸟关注
[/Quote]
老大你就別嚇唬我們了 呵
菜鸟关注
[/Quote]
老大你就別嚇唬我們了 呵
shuihan20e 2009-08-27
- 打赏
- 举报
菜鸟关注
wzwcn 2009-08-27
- 打赏
- 举报
我以前写了一个bpl的框架，可以把所有业务等抽象成接口，实现界面与逻辑分离，可以看看这里(有源码)，希望和大家交流交流：http://hi.baidu.com/0xcea4/blog/item/54caa91a926e93118718bf45.html
haitao 2009-08-27
- 打赏
- 举报
[Quote=引用 27 楼 snowflying928 的回复:]
我目前的想法是，UI层面Form所对应的pas文件不容许写任何逻辑处理代码。更不能包含sql。
对业务逻辑做模块化处理封装在对象中存在不同的pas文件中。
尽量不要使用全局变量，不要在不同的单元中引用全局变量。
[/Quote]
在我的Client/Webserver架构里，客户端采用非db的界面控件来显示、编辑当前记录的各个字段，浏览采用dbgrid，数据源是一个类似clientdataset的内存表控件，内存表里的数据按INI@http的方式取自位于webserver的应用服务程序（isapi程序）。
需要保存非db的界面控件里的内容修改、新增时，自动根据控件的name组成相应的sql语句，通过ini@http提交给应用服务程序（isapi程序）去执行。
应用涉及的所有的表，都要有这样的几个字段：
fid：自动递增id字段（用户不可见）；fname：该记录的描述、识别文本；fdeleted：删除标志
update语句就是根据fid进行定位的
我目前的想法是，UI层面Form所对应的pas文件不容许写任何逻辑处理代码。更不能包含sql。
对业务逻辑做模块化处理封装在对象中存在不同的pas文件中。
尽量不要使用全局变量，不要在不同的单元中引用全局变量。
[/Quote]
在我的Client/Webserver架构里，客户端采用非db的界面控件来显示、编辑当前记录的各个字段，浏览采用dbgrid，数据源是一个类似clientdataset的内存表控件，内存表里的数据按INI@http的方式取自位于webserver的应用服务程序（isapi程序）。
需要保存非db的界面控件里的内容修改、新增时，自动根据控件的name组成相应的sql语句，通过ini@http提交给应用服务程序（isapi程序）去执行。
应用涉及的所有的表，都要有这样的几个字段：
fid：自动递增id字段（用户不可见）；fname：该记录的描述、识别文本；fdeleted：删除标志
update语句就是根据fid进行定位的
snowflying928 2009-08-27
- 打赏
- 举报
[Quote=引用 28 楼 smallhand 的回复:]
我想討論的是，如何撰寫代碼易於維護，和擴展。
封裝，繼承啊啥的都是理論層面的，
我想在代碼面的討論。
楼主此话差已！
理论都是来自于实践，由实践累积而来的。
举个简单的例子：
TMan = class
public
procedure speak;
end;
子类：
TChinese = class(TMan)
end;
TEnglish = class(TMan)
end;
如果让所有的子类都有新增加一个name的属性，最简单的方法是在父类增加就可以了。
那么，与你在所有的子类增加name属性是不是更改的更小了呢？
修改TMan
TMan = class
private
FName: string;
public
procedure speak;
property Name: string read FName write FName;
end;
这个只是最基本的，根据情况不同采用的方法也不同。
设计模式和敏捷开发等就是在编写千万代码总结出的经验！
还有就是看你具体的应用，如果你写的是上位机或者与硬件通讯
的程序，那么就另当别论了。毕竟面向对象在这种应用下，效率
没有过程来得高。
楼主自己多看多练，多想，慢慢揣摩吧！
[/Quote]
谢谢你的指教。
我们目前主要是开发制造业的MES系统，主要是与数据库相关。我们在架构层次上用到了继承等特性。
当时单支程式比如维护工艺资料，一般都是对数据集做操作。
这种特性很少用到。
我想討論的是，如何撰寫代碼易於維護，和擴展。
封裝，繼承啊啥的都是理論層面的，
我想在代碼面的討論。
楼主此话差已！
理论都是来自于实践，由实践累积而来的。
举个简单的例子：
TMan = class
public
procedure speak;
end;
子类：
TChinese = class(TMan)
end;
TEnglish = class(TMan)
end;
如果让所有的子类都有新增加一个name的属性，最简单的方法是在父类增加就可以了。
那么，与你在所有的子类增加name属性是不是更改的更小了呢？
修改TMan
TMan = class
private
FName: string;
public
procedure speak;
property Name: string read FName write FName;
end;
这个只是最基本的，根据情况不同采用的方法也不同。
设计模式和敏捷开发等就是在编写千万代码总结出的经验！
还有就是看你具体的应用，如果你写的是上位机或者与硬件通讯
的程序，那么就另当别论了。毕竟面向对象在这种应用下，效率
没有过程来得高。
楼主自己多看多练，多想，慢慢揣摩吧！
[/Quote]
谢谢你的指教。
我们目前主要是开发制造业的MES系统，主要是与数据库相关。我们在架构层次上用到了继承等特性。
当时单支程式比如维护工艺资料，一般都是对数据集做操作。
这种特性很少用到。
火龙岛主 2009-08-27
- 打赏
- 举报
我想討論的是，如何撰寫代碼易於維護，和擴展。
封裝，繼承啊啥的都是理論層面的，
我想在代碼面的討論。
楼主此话差已！
理论都是来自于实践，由实践累积而来的。
举个简单的例子：
TMan = class
public
procedure speak;
end;
子类：
TChinese = class(TMan)
end;
TEnglish = class(TMan)
end;
如果让所有的子类都有新增加一个name的属性，最简单的方法是在父类增加就可以了。
那么，与你在所有的子类增加name属性是不是更改的更小了呢？
修改TMan
TMan = class
private
FName: string;
public
procedure speak;
property Name: string read FName write FName;
end;
这个只是最基本的，根据情况不同采用的方法也不同。
设计模式和敏捷开发等就是在编写千万代码总结出的经验！
还有就是看你具体的应用，如果你写的是上位机或者与硬件通讯
的程序，那么就另当别论了。毕竟面向对象在这种应用下，效率
没有过程来得高。
楼主自己多看多练，多想，慢慢揣摩吧！
封裝，繼承啊啥的都是理論層面的，
我想在代碼面的討論。
楼主此话差已！
理论都是来自于实践，由实践累积而来的。
举个简单的例子：
TMan = class
public
procedure speak;
end;
子类：
TChinese = class(TMan)
end;
TEnglish = class(TMan)
end;
如果让所有的子类都有新增加一个name的属性，最简单的方法是在父类增加就可以了。
那么，与你在所有的子类增加name属性是不是更改的更小了呢？
修改TMan
TMan = class
private
FName: string;
public
procedure speak;
property Name: string read FName write FName;
end;
这个只是最基本的，根据情况不同采用的方法也不同。
设计模式和敏捷开发等就是在编写千万代码总结出的经验！
还有就是看你具体的应用，如果你写的是上位机或者与硬件通讯
的程序，那么就另当别论了。毕竟面向对象在这种应用下，效率
没有过程来得高。
楼主自己多看多练，多想，慢慢揣摩吧！
snowflying928 2009-08-27
- 打赏
- 举报
我目前的想法是，UI层面Form所对应的pas文件不容许写任何逻辑处理代码。更不能包含sql。
对业务逻辑做模块化处理封装在对象中存在不同的pas文件中。
尽量不要使用全局变量，不要在不同的单元中引用全局变量。
对业务逻辑做模块化处理封装在对象中存在不同的pas文件中。
尽量不要使用全局变量，不要在不同的单元中引用全局变量。
snowflying928 2009-08-27
- 打赏
- 举报
我现在最头痛的是，外包收回的代码，很难维护，想重构都不可能
我在想制订个标准来规范代码。
我们目前只有一个命名的规范，太过简单了
我在想制订个标准来规范代码。
我们目前只有一个命名的规范，太过简单了
snowflying928 2009-08-27
- 打赏
- 举报
[Quote=引用 24 楼 sz_haitao 的回复:]
很多问题还是框架的限制
比如，delphi的事件不是线程，我想在一个事件执行的时候，能并行执行另一个事件，2个事件的代码交替地执行，就无法做到
如果分别交由一个线程去执行，由会涉及vcl的线程支持问题
[/Quote]
我想討論的是，如何撰寫代碼易於維護，和擴展。
封裝，繼承啊啥的都是理論層面的，
我想在代碼面的討論。
很多问题还是框架的限制
比如，delphi的事件不是线程，我想在一个事件执行的时候，能并行执行另一个事件，2个事件的代码交替地执行，就无法做到
如果分别交由一个线程去执行，由会涉及vcl的线程支持问题
[/Quote]
我想討論的是，如何撰寫代碼易於維護，和擴展。
封裝，繼承啊啥的都是理論層面的，
我想在代碼面的討論。
dinoalex 2009-08-26
- 打赏
- 举报
模块和继承
ok1411 2009-08-26
- 打赏
- 举报
这个说的就多了
你要说具体一点，一个程序一种思路
你要说具体一点，一个程序一种思路
ZyxIp 2009-08-26
- 打赏
- 举报
易维护和易扩展 的代码和语言的关系不如和分析业务的关系大.
主要还是看如何分析业务,当然不可能一次分析好,只有不断的重构.
主要还是看如何分析业务,当然不可能一次分析好,只有不断的重构.
snowflying928 2009-08-26
- 打赏
- 举报
[Quote=引用 8 楼 yanele 的回复:]
要看整个框架是怎么的!
[/Quote]
框架可以做强制限制吗？
我们的框架是不限制这个的
要看整个框架是怎么的!
[/Quote]
框架可以做强制限制吗？
我们的框架是不限制这个的
7年 2009-08-26
- 打赏
- 举报
这问题得根据个人来定吧?
wintergoes 2009-08-26
- 打赏
- 举报
[Quote=引用 4 楼 wsxcdx 的回复:]
菜鸟关注
[/Quote]
~~~
菜鸟关注
[/Quote]
~~~
yanele 2009-08-26
- 打赏
- 举报
要看整个框架是怎么的!
apilove 2009-08-26
- 打赏
- 举报
这个得关注一下
liangpei2008 2009-08-26
- 打赏
- 举报
[Quote=引用 4 楼 wsxcdx 的回复:]
菜鸟关注
[/Quote]
!
菜鸟关注
[/Quote]
!
haitao 2009-08-26
- 打赏
- 举报
很多问题还是框架的限制
比如，delphi的事件不是线程，我想在一个事件执行的时候，能并行执行另一个事件，2个事件的代码交替地执行，就无法做到
如果分别交由一个线程去执行，由会涉及vcl的线程支持问题
比如，delphi的事件不是线程，我想在一个事件执行的时候，能并行执行另一个事件，2个事件的代码交替地执行，就无法做到
如果分别交由一个线程去执行，由会涉及vcl的线程支持问题
snowflying928 2009-08-26
- 打赏
- 举报
我现在想给新人写个一般性的指导原则。我是比较反对直接在事件中写代码的。这样的写的代码又长又难看。
尤其我们外包收回的程式很难维护。
一般新手的做法是，画好UI后直接在控件的事件中写代码，程式的员的思考点是从UI用户的操作上入手的。
我想参考面向对象的方法，把编写代码的思考点转到业务对象的操作上。利用对象和单元文件模块化。
写好对象的方法后，在思考UI的调用。大家有没有方面的经验最好能标准化，方便外包验收的。
尤其我们外包收回的程式很难维护。
一般新手的做法是，画好UI后直接在控件的事件中写代码，程式的员的思考点是从UI用户的操作上入手的。
我想参考面向对象的方法，把编写代码的思考点转到业务对象的操作上。利用对象和单元文件模块化。
写好对象的方法后，在思考UI的调用。大家有没有方面的经验最好能标准化，方便外包验收的。
加载更多回复（13）
