OOP教程指南

公司接了个大项目，前期几乎没有任何架构设计，到了后期，代码混乱，SWITCH IF ELSE满天飞，性能问题严重，还有内存泄漏。这才使我认识到，JAVA的真谛在于面向对象的设计。现在开始努力学习设计模式等宏观设计的知识。

这几天在看SSH(Struts+Spring+Hibernate)，总觉得这种开发框架不是很符合面向对象的分析与设计。bojo已经退化成很单纯的一种数据结构struct，用来在三层间进行数据交换，不过是一种数据载体，说它是对象有点勉强；它没有业务操作行为，只有对本身数据的getter与set

看了论坛里很多关于多线程的帖子，banq不建议用jsp+javabean来做系统，我在想可不可以到底层去瞧瞧,下面是我的理解，jdon论坛，高手如云，如果有错误望大家指正。 php做的程序为什么简单的就能够支撑高负载？php是过程语言，函数式编程，内存在栈

在Jdon逛了这么久了，对领域建模有了一定的认识，感觉很好。可是，旁边的同学做项目时，都是先设计数据库表，然后增删改查，做界面，项目做的也是很快。而当我自己做项目时，自己想建立领域模型，然而发现，直接通过对数据库操作更直接，也更简单。而且一般不用担心效率问题。我学java也有一段时间了，通过banq

论坛里一直在讨论如何OO,如何建模,如何处理各种情景,那么,当我们面对旧系统,又有什么好办法处理这些问题? 当所有的类都是由关系数据库导出,不是使用组合而是添加了一个又一个字段进行关联.Hibernate成了另一种SQL语句,这种系

//筷子class Chopstick { private boolean taken;// 是否被拿起 public synchronized void take() { // .... }

小弟初到JDON，看了bang和道友的经典帖子感觉真的不错，看完后小弟有个疑问想请教各位：对于我们采用OO的设计理念进行的项目开发，对于采用DDD的设计方式，我们设计出的内容是完全不考虑数据库的，最后是在仓储中进行数据访问，那么疑惑出来了，对于以前说的表示层的VO和PO如果不匹配的话，或者一

　　在J道时间呆得久了，就越发得对公司现在的开发现状感到痛心和无奈。对自己得前途也不自觉得感到非常的担心。 　　我在一家专门从事电信行业开发的软件公司的工作。公司开发的项目主要采用得架构是前台用JAVA做开发，后台服务用pro C做开发，通过weblogi

看了很多关于 bang 的文章，感觉也很不错，但是待到实践之时，却又难以下手，思维从以数据库建模转化为面向对象方式遇到很大的障碍。现在有个很简单的问题想要问下，希望能够给予启迪，大恩言谢了。:-) 现有 服务请求方 和 服务应答方 两方 其中采用H

Java是命令式对象范式，这一点好像没有人注意。摘录一段大家讨论一下： 【不同于基于图灵机的命令范式和基于λ运算的函数范式，面向对象编程范式没有直接的理论模型来源。它似乎如同拼地图的男孩那样，仅仅是因为思考方式发生了变化，所以它的逻辑体系就自然出现

RTJ2EE架构的产品,三层全部公司自己的所有的业务运算均用PL/SQL完成J2EE到底有什么好处?我很迷惹.如果把业务运算放在数据库端完成,J2EE还有什么?

“软件以人为本”如果你是汽车得组装者，你拿到各个材料供应商得材料，你会不会有兴趣知道这个材料内部是怎么构成得？当然是“不”，没人关心这个（至少我是这样认为），恐怕软件公司也想学习汽车行业得这种工作方式吧？？通过明确得分工来提高效率，做架构得研究架构，做应用得学习使用架构等等。可是事与愿违，因

经理用隶属码标识数据间的结构。 如 A.1 是A.1.1的父节点这样做有什么问题吗？

目前正在做一个关于照片的项目，其中有一块设计请大家帮着看看有需要种类的商品，比如画册，海报等，而在这些种类里面呢，还包括了比如经典画册，正方形画册，海报中也是经典海报，迷你海报等等，而且他们还有不同的规格，比如7*5 10页画册，6*4 20页画册。海报呢又分为横向和纵向，7*5，6*4等等

最近两年来，经常在OO和SQL这两兄弟阵营里转来转去，总想做出个“决断”，结果却是谁也舍不得，手心手背都是肉啊。 十年前学应用开发的时候，SQL是绝对的王者，一直也就用了好几年，搞定了不少事情。有时候也觉着烦，尤其是许多不相干的调用代码，罗罗嗦嗦粘贴个没完

看了《什么是OO思想》帖abiandbel和zhaoping_yu说了很多，也让我明白了不少， 但如果能举些简单的例子，把OO思想运用的过程，从设计到最后的代码成型完成，帖出来，让大家