目前公司的开发是采用事物脚本的方式,不管业务简单还是复杂,基本上就是过程式的代码。
java 作为一个面向对象的语言,用来写过程式的代码,这样做工程前期速度快,维护肯定很麻烦。
不知道大家都是这种情况,还是说只有外包采用这种方式,(外包基本上是不存在维护)。
面向对象已经出来了很多年了,从 7 几年的 smalltalk 到现在 jdk8 ,已经发展了这么多年了,也算是很成熟的技术了。 是什么原因导致面向对象的方式没有大规模的使用?是大部分公司浮躁还是别的什么原因
1
honam 2016-07-07 10:22:41 +08:00
具体情况具体分析吧,不可能写个 hello world 都要扯一堆设计模式。
|
2
VictoryMiKi 2016-07-07 10:27:25 +08:00
赞同楼上
|
3
heian0224 2016-07-07 10:27:30 +08:00 via Android
面向对象不能解决业务的复杂度,所以才会有 soa 和工作流
|
4
shyling 2016-07-07 10:40:21 +08:00 via Android
设计不好的 oo 模型也不是很好维护啊。。。水桶要先满足短板咯
|
5
murmur 2016-07-07 10:41:51 +08:00
那是因为面向对象部分框架都帮你做好了 做业务的就只剩下面向对象了
|
6
cuebyte 2016-07-07 11:45:05 +08:00
我相信是人的问题。
|
7
caixiexin 2016-07-07 12:07:50 +08:00 via Android
贴代码看看
|
8
zrc OP 我是觉得,业务复杂的项目完全可以用 oo 来实现,维护方便,而且能够留下来业务的模型。对企业很方便,但是前期投入比较多。
相对的,非 oo 的项目,很快就可以进入开发,然后项目上线快,后期维护成本大,积累少,适合业务简单的。 当然,这只是我个人的理解。 其实我是觉得设计不好,是因为开发懒,或者项目经理的安排有问题。敏捷开发的方法,可以避免很大一部分。 框架是解决了基本部分,但是复杂的业务,医疗这些,和业务模型不冲突吧。 |
9
weiweiwitch 2016-07-07 13:43:22 +08:00
代码不好维护不是因为 OO 或过程式代码的原因。这两种代码不管哪种,写的好都很好维护。
然后看具体情况来选择哪种方式写代码。 而要让项目好维护,需要在很多地方下功夫。命名、文件组织、方法体大小、模块依赖关系、注释、文档、逻辑表述、选择的库的易用性等等,各种细节都做好了,项目代码才好维护。维护问题不是说用 OO 就能解决的,更多的还是看人和管理模式。 |
10
YORYOR 2016-07-07 15:59:37 +08:00
oo 写的好 维护起来相对很简单, oo 过度或者经验不足,维护和接手都会更恶心 新人接受会比较慢
过程式的不用说 流程可能会看着很恶心, 但是风险比较低 |
11
jimrok 2016-07-07 16:08:31 +08:00
那还是因为不够复杂,可以造。
|