本人又在重复前辈开发中的困惑，不吝赐教！

[xuanyuancl]

随着工作的时间,编程1年多,有着自己的编程习惯,也有了自己的代码框架,问题就在这代码构架上,觉

得自己在走一些弯路,没有朝着正确的方向迈上那么一步,,现在叫我说出"什么叫面向对象",我都难以启齿,我都根

本不知道什么样的设计才叫做"面向对象",究竟"面向对象"能为我带来什么,说句自嘲的话,前些日子还在看"C#设计

模式",哼哼,简直是玷污了软件的设计现请高人指点,帮我走出这万般无赖的设计思路.

现在所有项目的设计思路如下:


数据库---->存储过程---->类(属性和方法调用存储过程)----->后台处理(调类)---->前台(与后台交互)


这很大可能上是符合三层架构的设计模式,但是什么事都是双方面的,有利就有弊,这样的一个最大的缺点就是:修改或

者添加数据库中一个字段,首先要修改存储过程,其次要修改类,然后要修改后台,最后还要修改前台,这样的流程,这样

的设计思路,简直是把项目重跑了一遍,工作量大,难维护,效率低.现阶段根据我的经验也不能拿出什么好的解决方案出

来,很迷惘,很伤心,总觉得自己在原地踏步,不能找到正确的方向昨晚想了很久,是不是面向对象的设计就能帮我解决以

上的这一连串的问题呢???还是另有原因???那么面向对象的程序设计究竟能给我们带来了什么???

我现在的认识就是:
与数据库的操作,无论是Insert,Update,还是Delete,Search也好,只要给你提供个接口,告诉你具体那张表,有几个字段,

你就给我Insert,Update,Delete,这个对于数据库来说,完成的就是这个任务,你只负责给我做相关的操作,面向对象的设

计是不是可以用一个通用的函数来实现与数据库的操作呢???这样的话只需要修改函数,再抽象点,将函数抽象化,只需修

改函数实现的接口就可以了呢???如果将存储过程全部替换为SQL语句,就可以达到目的,用不着每次都将项目跑一遍,那么

还用存储过程干嘛???数据执行的速度怎么能提升,项目的性能怎么得到合理的提高???

有人说过句话:当你发现你的代码每次都复制粘贴,复制粘贴的时候,你就可以考虑将它们重用,

我思路肯定是有有问题的,请大家不吝分享你们的经验,交流交流,给我提出点参考的方面,不慎感激
--------这是某前辈写的，我现在也是感同身受，困惑好长时间了。。。

[bwangel]

难道一个最简单的查询也用存储过程实现吗？这样也太那个了吧。
偶认为只有最关键，或使用最频繁，或对性能影响最大的查询才有必要用这个

[accp3sniper]

我也是有这样的问题，怎么样的程序才叫是面像对象的编程，还需要慢慢探索

[西安风影]

面向对象很难体会
2楼说的没错

当你做组件、类库、框架项目时候，就会对面像对象的编程有更深的体会~
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
而且刚开始还是有一点点体会，很微妙的。

[ahshow]

框架项目是比较有体验的，像nbibernater那种东西就挺面向对象的

[yanxw_227]

同样迷茫，我现在每天做的都是这样的操作！
一些建议：
1.完全明确用户需求，有条件的话让用户每天都陪着，便于了解需求；
2.总体规划好，尤其是那些彼此有影响的（专业词汇好像叫做耦合，不懂！）程序更要注意！

[bwangel]

只要你对项目熟悉，改动量应该很小，很快就可以完成。

[possible_Y]

你要首先知道做商业软件的目的：赚钱

那么降低成本就是很重要的，其中软件很大成本就在于需求变化和后期维护升级，另外复用也可以降低成本

所以我们核心要做是:
1. 提高复用性
2. 提高适应需求变化的能力（以前需求变了，可能我们要花1个月时间重写整个模块，现在我们只要稍许修改下代码，甚至只改下配置）

而面向对象的设计和编码就是提供一种方式，来帮组我们达到上面2个目的，从而最终赚到钱。

建议你先去体会多态的好处，为啥要用接口？为啥要写虚方法和override方法
然后去学习一下面向对象设计的一些基本原则，主要是体会遵守这些会有什么好处，违反了会有什么后果（其实好处和恶果都是围绕上面2点的）
再去看看开源社区的一些好的设计想法，比如MVC，IOC，AOP等
这是再配合来看那些模式的理论（最重要还是要理解它能带来的好处以及什么时候用用在什么地方才会带来好处）

最后就是无模式状态，做软件心中只要记住 赚钱 2个字就可以了

[asp_plus]

赚钱 2个字就可以了

我一定牢记在心

[码上有钱了]

Model层你用的不是太熟悉,可以多看看PetShop.看看反射的用法,体现IDAL和DALFactory,这样你的项目就灵活了,不至于牵一发而动全身

[走在落叶的秋天]

你说的就是现在一般都在用的三层架构，可是你却没有用到复用性更高的设计模式真是可惜。
原来三层架构是用来简化开发的，现在反倒成了加重开发量了的累赘。

[以专业开发人员为伍]

“最笨的拼凑方法、想尽办法拖延足够长开发时间”照样可以拼凑出应用程序！因此很多人会觉得软件工程是阳春白雪。不过如果你眼睛永远盯着2年以后你的项目变成产品之后的升级改造等市场需求，就会专心做设计而把简单体力活留给别人。

[bruda]

赚钱啊

[knowledge_Is_Life]

不会,帮顶

[meiZiNick]

不会,帮顶

[ElzaJiang]

不懂。帮顶一下。。

[dm1980_ren]

还是没有剥离好。命题太大了点

[jelous]

[Quote=引用 14 楼 sp1234 的回复:]
“最笨的拼凑方法、想尽办法拖延足够长开发时间”照样可以拼凑出应用程序！因此很多人会觉得软件工程是阳春白雪。不过如果你眼睛永远盯着2年以后你的项目变成产品之后的升级改造等市场需求，就会专心做设计而把简单体力活留给别人。
[/Quote]
同样迷茫，中国的软件开发就是抄抄写写

[生活真美好]

[Quote=引用 9 楼 possible_y 的回复:]
做软件心中只要记住 赚钱 2个字就可以了[/Quote]

[wulala11]

去看看UML，试着把
数据库---->存储过程---->类(属性和方法调用存储过程)----->后台处理(调类)
倒过来
后台处理(调类)---->类(属性和方法调用存储过程)---->存储过程---->数据库

[wanghui0380]

数据库---->存储过程---->类(属性和方法调用存储过程)----->后台处理(调类)

从这里看的出，你还陷在细节的处理上。

数据库设计-----那是细节--数据字典，主键外键，一对多，多对多。数据就是数据，数据难免琐碎细节。

存储过程------就更是细节，存储过程要有目标，没有目标就没有存储过程，所以他是细节，他针对的是一个具体的细节

类(属性和方法调用存储过程)----->还是细节，，类就是类，他没必要非要和存储过程挂一块的。如果基于存储过程这种细节上去编写类，那么这类难免还是细节，因为他的基础是细节

后台处理(调类)------任然是细节---以为他基于UI的动作细节，和上面一样。基础是细节，结局也难免细节


所以你的毛病就是太过依靠细节，一切依赖细节，结果自然是细节一变，大家都变。

面对对象----靠的是抽象，玩的是哲学。搞的是依赖抽象，而非依赖细节，这就是根本性的问题。
所以你要解决的问题是：依赖抽象而非依赖细节，细节需要延迟决定，而非预先决策，基本上只有到这个程度的程序员才算的上正真明白啥叫面对对象