2、面向类的程序可以像其他程序一样在逻辑上纠缠不清；
3、非面向类的但是良好分层的程序或许比没有分层的面向类的程序更加可维护；
4、类可以实现更精致的高级分层：类是分层的充分条件；
（引自：Tyson Gill《Visual Basic6：Error Coding and Layering》）
76 个解决方案
#1
试试什么是vb6的class吧！它是COM的class的概念，跟.net差得老远了。即使.net尚且不是很好的OOPL，从vb6出发的东西更有可能。
#2
楼主新年快乐！给你拜年啦
#3
类解决个体重用，是对象的标准件。
分层更象是零件到产品的制造组装工艺。
分层更象是零件到产品的制造组装工艺。
#4
喜欢在讨论编程问题的时候使用：标准、零件、制造、组装、工艺……等等这样的名词
#5
分层只是一种工程方法，可以用新的实现来替换原有层次的实现；
有利于标准化；
利于各层次之间的逻辑复用。
有利于标准化；
利于各层次之间的逻辑复用。
#6
学习了
分层在执行效率上来说降低了的
但是在开发和维护方面却是提高了一大截
#7
鱼与熊掌不可兼得~只有来个符合实际需求的设计就好了
#8
学习！！！！！！！！
#9
有点废话的说
炒菜需放盐，一盐出百味出。 但要炒的好菜却并不是单单一个放盐能解决的事情
这是所有的人都知道的事情，不用特别去强调吧
炒菜需放盐，一盐出百味出。 但要炒的好菜却并不是单单一个放盐能解决的事情
这是所有的人都知道的事情，不用特别去强调吧
#10
1、楼上的跟CSDN过不去，不跟我这儿撒气，我没惹过阁下吧；
2、楼上的绝对不是废话，您的这段言论复制到任何论坛都不是废话；
2、楼上的绝对不是废话，您的这段言论复制到任何论坛都不是废话；
#11
的确废话来着。
我想炒出一盘咸淡适宜的好菜，我放了1克盐，ok，刚刚好。
这个刚刚好取决与你想让他咸淡适宜，而不是因为你放了1克盐，所以他符合咸淡适宜这个标准
研究方法学，是通过方法学知道该方法的所体现的含义。而不是死套方法学
这段言论复制到任何论坛都不是废话，呵呵，如果说一个家庭主妇跑到一个厨师论坛上说：“我炒了一盘*的白菜，是因为我刚刚好放了1克盐，结论是盐不是炒出好白菜的必要条件，他是炒出好白菜的充分条件！”你认为这不是废话？？
我想炒出一盘咸淡适宜的好菜，我放了1克盐，ok，刚刚好。
这个刚刚好取决与你想让他咸淡适宜，而不是因为你放了1克盐，所以他符合咸淡适宜这个标准
研究方法学，是通过方法学知道该方法的所体现的含义。而不是死套方法学
这段言论复制到任何论坛都不是废话，呵呵，如果说一个家庭主妇跑到一个厨师论坛上说：“我炒了一盘*的白菜，是因为我刚刚好放了1克盐，结论是盐不是炒出好白菜的必要条件，他是炒出好白菜的充分条件！”你认为这不是废话？？
#12
说老实话，我不是反对你
而是反对现在很多人，把方法学当数学去研究。
方法学不是数学，他是只是策略和手段。
方法学实际是不可复制的，他取决与他要解决问题本身和你所持的策略
事易时移方法学本身不可复制，而我们所能复制的是方法学所代表策略。
所以你要研究方法学就千万别把他当数学公式，这个不是a+b=c，不要把自己陷在那些条条框框里。
而是反对现在很多人，把方法学当数学去研究。
方法学不是数学，他是只是策略和手段。
方法学实际是不可复制的，他取决与他要解决问题本身和你所持的策略
事易时移方法学本身不可复制，而我们所能复制的是方法学所代表策略。
所以你要研究方法学就千万别把他当数学公式，这个不是a+b=c，不要把自己陷在那些条条框框里。
#13
你去看看备受推崇的petshop的层里边都是些什么东西，就知道我为什么要摘录这段话了。
如果非要往烹饪上扯的话，那就是：从家庭主妇到专业大厨都能很恰到好处的使用盐以及其他调味品，
烹饪这门技术已经四五千年了，你认为和软件开发三四十年的历史比起来，还有什么不成熟的地方吗？
如果非要往烹饪上扯的话，那就是：从家庭主妇到专业大厨都能很恰到好处的使用盐以及其他调味品，
烹饪这门技术已经四五千年了，你认为和软件开发三四十年的历史比起来，还有什么不成熟的地方吗？
#14
我觉得 wanghui0380 说的挺有道理的。
解决问题的策略有N种，不一定面向对象，哪些更好或者更差罢了。
比如有些时候，我恨不得C#可以支持多继承……
解决问题的策略有N种，不一定面向对象，哪些更好或者更差罢了。
比如有些时候，我恨不得C#可以支持多继承……
#15
顶一下 顶到底 继续努力
#16
我回复一下，不用了，谢我
#17
好好好好好好好好好好好好
#18
分层是软件实现的一种方法，
类是面象对象编程语言的基础方式
分层离不开类
类是面象对象编程语言的基础方式
分层离不开类
#19
这个,应该是看你怎么分吧.
我一般的做法是.将类分为
一个是基础操作类.负责通用的算法,通用的数据库操作.通用的功能. 等模块.
在这个基础上,针对具体的业务逻辑,再继承基础类.业务逻回可以是一个中间件,一个服务等.
我一般的做法是.将类分为
一个是基础操作类.负责通用的算法,通用的数据库操作.通用的功能. 等模块.
在这个基础上,针对具体的业务逻辑,再继承基础类.业务逻回可以是一个中间件,一个服务等.
#20
该回复于2015-07-31 23:30:49被版主删除
#21
再看看18、19楼，你还觉得我说的是废话吗？
#22
看样子我是个初学者呀,还是不明白
#23
想怎么用着方便,就怎么用,关键是要决解问题
#24
各层次之间的逻辑复用
#25
典型的用 C 語言，寫的物件導向的程式，就是 GTK
#26
给楼主拜个年.很有才
#27
给楼主拜个年.很有才
#28
学习了！！！
#29
分层 不是面向对象也可以实现啊
c照样可以分层
和类没的必要关系
c照样可以分层
和类没的必要关系
#30
学习学习。。。00000
#31
学习学习
学习学习
学习学习
#32
学习了
#33
简单滴说，类和层只是不同级别滴抽象概念！
一般而言，先学分类，再学分层比较容易入手！
一般而言，先学分类，再学分层比较容易入手！
#34
该回复于2014-10-04 09:47:55被版主删除
#35
这个话题很好，值得讨论
#36
类 就像 车床上的模具，架构 就像 工厂的某条流水线。
生产100个同属性的产品，车床上只要安装一个模具即可，当然，你也可以去制作100个一样的模具，只是效率和成本就提高很多了，这就是类的代码复用缩影...
有了类可以改善分层，但是类不需要去保证分层，类不是为了分层而生的。
生产100个同属性的产品，车床上只要安装一个模具即可，当然，你也可以去制作100个一样的模具，只是效率和成本就提高很多了，这就是类的代码复用缩影...
有了类可以改善分层，但是类不需要去保证分层，类不是为了分层而生的。
#37
学习了
#38
我个人一直坚持一个原则:封装的功能越原始越好,接口越简单越好.
我上面上将逻辑放到中间层,实质上,我只有一个项目是这样做的.
当时使用的是VB6.0,用中间件COM+处理业务逻辑,然后与一个描述的数据库联合,
进行一个动态调用,想的时候觉得这个方式非常不错.写程序时也觉得挺好.感觉是很顺利的.
但是后来,由于甲方在上线调度时,对原来的一些逻辑进行调整时,这时我感觉非常痛苦了.
痛苦的原因是由于原来的应用分的层次过多.
数据库<--->COM+(业务逻辑)<--->代理类<---->UI
当我要修改业务逻辑时,如增加一个参数或取消一个参数时,COM+要更新,所有客户端的代理类必须重新导出重新安装.描述的数据库也必须更新,UI也要更新,几乎是一条线了.在这里我就耗了大量的人力和精力.
后来,将业务逻辑封装到中间件的做法,我再也不用.
后来到了NET,中间件换成了WEBSERVICES,但是,在VB6.0时代,COM/COM+留给我的阴影是很大的.COM陷井曾让我焦头烂额.甚至我现在一看到一个DLL/OCX文件名,就想到陷井.
我现在最直接的做法,基本结构是这样:
(服务器) 数据库<--->WEBSERVICES<--->(客户端) WEBSERVICES通信类<---->业务逻辑<---->UI
由于WEBSERVICES里再也没有逻辑,它只是一些数据库操作和验证,也包括了自定义的工作流.这些东西都是不变的,是任何一个系统都一样的.与这个服务配套的通信类,也是不变的.所以,无论业务逻辑怎样更新,只要更新业务逻回层(就一个类)就可以了,然后更新UI.由于现在所有的C/S都是可以远程更新的了,所以,将逻辑封装到客户端,也觉得没有什么不好.而且,业务逻辑是动态调用的FORM,这样也有利于小组开发,每个人负责自己相关的窗体即可.
当然,更复杂的功能,我宁愿用存储过程封装到数据库去,比如说:BOM的分解等...
当然,我也只是一家之言,至于更适合哪种模式,那也要看具体的业务.例如我最后做后个项目,将某种算法(相当于一个逻辑)就以动态的方式封装在服务层,因为这是功能性的封装,是一次性的.
我上面上将逻辑放到中间层,实质上,我只有一个项目是这样做的.
当时使用的是VB6.0,用中间件COM+处理业务逻辑,然后与一个描述的数据库联合,
进行一个动态调用,想的时候觉得这个方式非常不错.写程序时也觉得挺好.感觉是很顺利的.
但是后来,由于甲方在上线调度时,对原来的一些逻辑进行调整时,这时我感觉非常痛苦了.
痛苦的原因是由于原来的应用分的层次过多.
数据库<--->COM+(业务逻辑)<--->代理类<---->UI
当我要修改业务逻辑时,如增加一个参数或取消一个参数时,COM+要更新,所有客户端的代理类必须重新导出重新安装.描述的数据库也必须更新,UI也要更新,几乎是一条线了.在这里我就耗了大量的人力和精力.
后来,将业务逻辑封装到中间件的做法,我再也不用.
后来到了NET,中间件换成了WEBSERVICES,但是,在VB6.0时代,COM/COM+留给我的阴影是很大的.COM陷井曾让我焦头烂额.甚至我现在一看到一个DLL/OCX文件名,就想到陷井.
我现在最直接的做法,基本结构是这样:
(服务器) 数据库<--->WEBSERVICES<--->(客户端) WEBSERVICES通信类<---->业务逻辑<---->UI
由于WEBSERVICES里再也没有逻辑,它只是一些数据库操作和验证,也包括了自定义的工作流.这些东西都是不变的,是任何一个系统都一样的.与这个服务配套的通信类,也是不变的.所以,无论业务逻辑怎样更新,只要更新业务逻回层(就一个类)就可以了,然后更新UI.由于现在所有的C/S都是可以远程更新的了,所以,将逻辑封装到客户端,也觉得没有什么不好.而且,业务逻辑是动态调用的FORM,这样也有利于小组开发,每个人负责自己相关的窗体即可.
当然,更复杂的功能,我宁愿用存储过程封装到数据库去,比如说:BOM的分解等...
当然,我也只是一家之言,至于更适合哪种模式,那也要看具体的业务.例如我最后做后个项目,将某种算法(相当于一个逻辑)就以动态的方式封装在服务层,因为这是功能性的封装,是一次性的.
#39
我一般就用到类的继承 与封装。。多态好像 太难。不过，那好高深。。
#40
用C#是离不开类的.我只能这样说.
#41
代码零件被分的越细越好，但是它们需要以最低的耦合方式组装在一起，而且组装被推的越晚越好，最好是运行时组装，这种组装的一个重要步骤就是逻辑分层，
从你的描述我推断你们还在使用数据库驱动方式编程，
你如果还把数据库当作逻辑上的一个层，那么除了class，你还有什么好的方法分层呢？
#42
楼主新年快乐！谢谢楼主的分享！
#43
新年快乐，虎年吉祥如意！
#44
vb6跟.net区别很大的。
其实书的作者，都要找一些很细微的观点来证明自己，证明自己的理论和知识。
写程序用一个方法，重要的是自己熟悉，了解内幕，提高自己的工作效率等
其实书的作者，都要找一些很细微的观点来证明自己，证明自己的理论和知识。
写程序用一个方法，重要的是自己熟悉，了解内幕，提高自己的工作效率等
#45
学学各位的经验，但是csdn说回复太短了，只好再加半句。
#46
楼上， 适应就好了！
#47
学习学习。。。。。。up一下。。。。。。
#48
46楼是我能挑战的极限，大家也来试试看？
#49
？ ？
#50
作为软件开发者，csdn的这个规则应该很快适应的，
我看不少人心态不好，
46、49楼见证
我看不少人心态不好，
46、49楼见证
#1
试试什么是vb6的class吧！它是COM的class的概念，跟.net差得老远了。即使.net尚且不是很好的OOPL，从vb6出发的东西更有可能。
#2
楼主新年快乐！给你拜年啦
#3
类解决个体重用，是对象的标准件。
分层更象是零件到产品的制造组装工艺。
分层更象是零件到产品的制造组装工艺。
#4
喜欢在讨论编程问题的时候使用：标准、零件、制造、组装、工艺……等等这样的名词
#5
分层只是一种工程方法，可以用新的实现来替换原有层次的实现；
有利于标准化；
利于各层次之间的逻辑复用。
有利于标准化；
利于各层次之间的逻辑复用。
#6
学习了
分层在执行效率上来说降低了的
但是在开发和维护方面却是提高了一大截
#7
鱼与熊掌不可兼得~只有来个符合实际需求的设计就好了
#8
学习！！！！！！！！
#9
有点废话的说
炒菜需放盐，一盐出百味出。 但要炒的好菜却并不是单单一个放盐能解决的事情
这是所有的人都知道的事情，不用特别去强调吧
炒菜需放盐，一盐出百味出。 但要炒的好菜却并不是单单一个放盐能解决的事情
这是所有的人都知道的事情，不用特别去强调吧
#10
1、楼上的跟CSDN过不去，不跟我这儿撒气，我没惹过阁下吧；
2、楼上的绝对不是废话，您的这段言论复制到任何论坛都不是废话；
2、楼上的绝对不是废话，您的这段言论复制到任何论坛都不是废话；
#11
的确废话来着。
我想炒出一盘咸淡适宜的好菜，我放了1克盐，ok，刚刚好。
这个刚刚好取决与你想让他咸淡适宜，而不是因为你放了1克盐，所以他符合咸淡适宜这个标准
研究方法学，是通过方法学知道该方法的所体现的含义。而不是死套方法学
这段言论复制到任何论坛都不是废话，呵呵，如果说一个家庭主妇跑到一个厨师论坛上说：“我炒了一盘*的白菜，是因为我刚刚好放了1克盐，结论是盐不是炒出好白菜的必要条件，他是炒出好白菜的充分条件！”你认为这不是废话？？
我想炒出一盘咸淡适宜的好菜，我放了1克盐，ok，刚刚好。
这个刚刚好取决与你想让他咸淡适宜，而不是因为你放了1克盐，所以他符合咸淡适宜这个标准
研究方法学，是通过方法学知道该方法的所体现的含义。而不是死套方法学
这段言论复制到任何论坛都不是废话，呵呵，如果说一个家庭主妇跑到一个厨师论坛上说：“我炒了一盘*的白菜，是因为我刚刚好放了1克盐，结论是盐不是炒出好白菜的必要条件，他是炒出好白菜的充分条件！”你认为这不是废话？？
#12
说老实话，我不是反对你
而是反对现在很多人，把方法学当数学去研究。
方法学不是数学，他是只是策略和手段。
方法学实际是不可复制的，他取决与他要解决问题本身和你所持的策略
事易时移方法学本身不可复制，而我们所能复制的是方法学所代表策略。
所以你要研究方法学就千万别把他当数学公式，这个不是a+b=c，不要把自己陷在那些条条框框里。
而是反对现在很多人，把方法学当数学去研究。
方法学不是数学，他是只是策略和手段。
方法学实际是不可复制的，他取决与他要解决问题本身和你所持的策略
事易时移方法学本身不可复制，而我们所能复制的是方法学所代表策略。
所以你要研究方法学就千万别把他当数学公式，这个不是a+b=c，不要把自己陷在那些条条框框里。
#13
你去看看备受推崇的petshop的层里边都是些什么东西，就知道我为什么要摘录这段话了。
如果非要往烹饪上扯的话，那就是：从家庭主妇到专业大厨都能很恰到好处的使用盐以及其他调味品，
烹饪这门技术已经四五千年了，你认为和软件开发三四十年的历史比起来，还有什么不成熟的地方吗？
如果非要往烹饪上扯的话，那就是：从家庭主妇到专业大厨都能很恰到好处的使用盐以及其他调味品，
烹饪这门技术已经四五千年了，你认为和软件开发三四十年的历史比起来，还有什么不成熟的地方吗？
#14
我觉得 wanghui0380 说的挺有道理的。
解决问题的策略有N种，不一定面向对象，哪些更好或者更差罢了。
比如有些时候，我恨不得C#可以支持多继承……
解决问题的策略有N种，不一定面向对象，哪些更好或者更差罢了。
比如有些时候，我恨不得C#可以支持多继承……
#15
顶一下 顶到底 继续努力
#16
我回复一下，不用了，谢我
#17
好好好好好好好好好好好好
#18
分层是软件实现的一种方法，
类是面象对象编程语言的基础方式
分层离不开类
类是面象对象编程语言的基础方式
分层离不开类
#19
这个,应该是看你怎么分吧.
我一般的做法是.将类分为
一个是基础操作类.负责通用的算法,通用的数据库操作.通用的功能. 等模块.
在这个基础上,针对具体的业务逻辑,再继承基础类.业务逻回可以是一个中间件,一个服务等.
我一般的做法是.将类分为
一个是基础操作类.负责通用的算法,通用的数据库操作.通用的功能. 等模块.
在这个基础上,针对具体的业务逻辑,再继承基础类.业务逻回可以是一个中间件,一个服务等.
#20
该回复于2015-07-31 23:30:49被版主删除
#21
再看看18、19楼，你还觉得我说的是废话吗？
#22
看样子我是个初学者呀,还是不明白
#23
想怎么用着方便,就怎么用,关键是要决解问题
#24
各层次之间的逻辑复用
#25
典型的用 C 語言，寫的物件導向的程式，就是 GTK
#26
给楼主拜个年.很有才
#27
给楼主拜个年.很有才
#28
学习了！！！
#29
分层 不是面向对象也可以实现啊
c照样可以分层
和类没的必要关系
c照样可以分层
和类没的必要关系
#30
学习学习。。。00000
#31
学习学习
学习学习
学习学习
#32
学习了
#33
简单滴说，类和层只是不同级别滴抽象概念！
一般而言，先学分类，再学分层比较容易入手！
一般而言，先学分类，再学分层比较容易入手！
#34
该回复于2014-10-04 09:47:55被版主删除
#35
这个话题很好，值得讨论
#36
类 就像 车床上的模具，架构 就像 工厂的某条流水线。
生产100个同属性的产品，车床上只要安装一个模具即可，当然，你也可以去制作100个一样的模具，只是效率和成本就提高很多了，这就是类的代码复用缩影...
有了类可以改善分层，但是类不需要去保证分层，类不是为了分层而生的。
生产100个同属性的产品，车床上只要安装一个模具即可，当然，你也可以去制作100个一样的模具，只是效率和成本就提高很多了，这就是类的代码复用缩影...
有了类可以改善分层，但是类不需要去保证分层，类不是为了分层而生的。
#37
学习了
#38
我个人一直坚持一个原则:封装的功能越原始越好,接口越简单越好.
我上面上将逻辑放到中间层,实质上,我只有一个项目是这样做的.
当时使用的是VB6.0,用中间件COM+处理业务逻辑,然后与一个描述的数据库联合,
进行一个动态调用,想的时候觉得这个方式非常不错.写程序时也觉得挺好.感觉是很顺利的.
但是后来,由于甲方在上线调度时,对原来的一些逻辑进行调整时,这时我感觉非常痛苦了.
痛苦的原因是由于原来的应用分的层次过多.
数据库<--->COM+(业务逻辑)<--->代理类<---->UI
当我要修改业务逻辑时,如增加一个参数或取消一个参数时,COM+要更新,所有客户端的代理类必须重新导出重新安装.描述的数据库也必须更新,UI也要更新,几乎是一条线了.在这里我就耗了大量的人力和精力.
后来,将业务逻辑封装到中间件的做法,我再也不用.
后来到了NET,中间件换成了WEBSERVICES,但是,在VB6.0时代,COM/COM+留给我的阴影是很大的.COM陷井曾让我焦头烂额.甚至我现在一看到一个DLL/OCX文件名,就想到陷井.
我现在最直接的做法,基本结构是这样:
(服务器) 数据库<--->WEBSERVICES<--->(客户端) WEBSERVICES通信类<---->业务逻辑<---->UI
由于WEBSERVICES里再也没有逻辑,它只是一些数据库操作和验证,也包括了自定义的工作流.这些东西都是不变的,是任何一个系统都一样的.与这个服务配套的通信类,也是不变的.所以,无论业务逻辑怎样更新,只要更新业务逻回层(就一个类)就可以了,然后更新UI.由于现在所有的C/S都是可以远程更新的了,所以,将逻辑封装到客户端,也觉得没有什么不好.而且,业务逻辑是动态调用的FORM,这样也有利于小组开发,每个人负责自己相关的窗体即可.
当然,更复杂的功能,我宁愿用存储过程封装到数据库去,比如说:BOM的分解等...
当然,我也只是一家之言,至于更适合哪种模式,那也要看具体的业务.例如我最后做后个项目,将某种算法(相当于一个逻辑)就以动态的方式封装在服务层,因为这是功能性的封装,是一次性的.
我上面上将逻辑放到中间层,实质上,我只有一个项目是这样做的.
当时使用的是VB6.0,用中间件COM+处理业务逻辑,然后与一个描述的数据库联合,
进行一个动态调用,想的时候觉得这个方式非常不错.写程序时也觉得挺好.感觉是很顺利的.
但是后来,由于甲方在上线调度时,对原来的一些逻辑进行调整时,这时我感觉非常痛苦了.
痛苦的原因是由于原来的应用分的层次过多.
数据库<--->COM+(业务逻辑)<--->代理类<---->UI
当我要修改业务逻辑时,如增加一个参数或取消一个参数时,COM+要更新,所有客户端的代理类必须重新导出重新安装.描述的数据库也必须更新,UI也要更新,几乎是一条线了.在这里我就耗了大量的人力和精力.
后来,将业务逻辑封装到中间件的做法,我再也不用.
后来到了NET,中间件换成了WEBSERVICES,但是,在VB6.0时代,COM/COM+留给我的阴影是很大的.COM陷井曾让我焦头烂额.甚至我现在一看到一个DLL/OCX文件名,就想到陷井.
我现在最直接的做法,基本结构是这样:
(服务器) 数据库<--->WEBSERVICES<--->(客户端) WEBSERVICES通信类<---->业务逻辑<---->UI
由于WEBSERVICES里再也没有逻辑,它只是一些数据库操作和验证,也包括了自定义的工作流.这些东西都是不变的,是任何一个系统都一样的.与这个服务配套的通信类,也是不变的.所以,无论业务逻辑怎样更新,只要更新业务逻回层(就一个类)就可以了,然后更新UI.由于现在所有的C/S都是可以远程更新的了,所以,将逻辑封装到客户端,也觉得没有什么不好.而且,业务逻辑是动态调用的FORM,这样也有利于小组开发,每个人负责自己相关的窗体即可.
当然,更复杂的功能,我宁愿用存储过程封装到数据库去,比如说:BOM的分解等...
当然,我也只是一家之言,至于更适合哪种模式,那也要看具体的业务.例如我最后做后个项目,将某种算法(相当于一个逻辑)就以动态的方式封装在服务层,因为这是功能性的封装,是一次性的.
#39
我一般就用到类的继承 与封装。。多态好像 太难。不过，那好高深。。
#40
用C#是离不开类的.我只能这样说.
#41
代码零件被分的越细越好，但是它们需要以最低的耦合方式组装在一起，而且组装被推的越晚越好，最好是运行时组装，这种组装的一个重要步骤就是逻辑分层，
从你的描述我推断你们还在使用数据库驱动方式编程，
你如果还把数据库当作逻辑上的一个层，那么除了class，你还有什么好的方法分层呢？
#42
楼主新年快乐！谢谢楼主的分享！
#43
新年快乐，虎年吉祥如意！
#44
vb6跟.net区别很大的。
其实书的作者，都要找一些很细微的观点来证明自己，证明自己的理论和知识。
写程序用一个方法，重要的是自己熟悉，了解内幕，提高自己的工作效率等
其实书的作者，都要找一些很细微的观点来证明自己，证明自己的理论和知识。
写程序用一个方法，重要的是自己熟悉，了解内幕，提高自己的工作效率等
#45
学学各位的经验，但是csdn说回复太短了，只好再加半句。
#46
楼上， 适应就好了！
#47
学习学习。。。。。。up一下。。。。。。
#48
46楼是我能挑战的极限，大家也来试试看？
#49
？ ？
#50
作为软件开发者，csdn的这个规则应该很快适应的，
我看不少人心态不好，
46、49楼见证
我看不少人心态不好，
46、49楼见证