请问大家怎么样一个结构才算是符合OOP思想的设计？

Question

请问大家：我在设计一个  客户 产品 订单 管理系统系统我分别要对 客户以及客户名下的订单  产品 进行 添加删除等管理操作。谁能提供一下这样一个系统 类结构吗？不要详细的代码，只要提供各个类之间的关系就行。我主要是对类之间的关系要怎么组织不太清楚，比如我要为客户添加一个订单，我是要在我的客户类添加一个方法以及订单有关的属性？还是把订单类作为客户类的属性（这样就形成一个 聚合还是联合关系？）来处理？谁能提供一个符合面向对象思想的架构吗？

Answer 1

你这个问题太大了先学面向对象，
http://www.cnblogs.com/healerkx/category/136925.html再学设计模式，再看看面向对象设计的原则，比如OCP，LSP，DIP，等等。

Answer 2

你写的这两个，不知道怎么才能更加“符合面向对象的思想”。OOAD并不是往八股文里一套就好。所以很多东西首先要看是否自然、真实，而不是为了套用模式而写程序。客户有太多的东西需要“关心”，所以添加订单通常既不是客户的方法职责，也不是它的属性。事实永远胜于雄辩，需求的真实合理性也比任何教条更有用。在开发订单系统时，是首先在别的地方有了独立的客户管理系统，然后订单系统拿来客户概念进行架构，于是它不可能去破坏客户概念来加入什么自己的方法或者属性，也就是说客户不依赖于订单而是订单依赖于客户（关联的方向和依赖的方向并不一定相同）。

Answer 3

"也就是说客户不依赖于订单而是订单依赖于客户（关联的方向和依赖的方向并不一定相同）。"说的很好，问题是有这样一个典型的 小系统 UML 分析的图吗吗？让我学学？

Answer 4

首先（以及始终）是关心真实性，然后才是技术。客户不可能知道它自己有什么订单，那么好，订单来知道它自己所属于的客户。这就足够了！假设一个订单有多个客户，那么我们就单独为这种关联建立对象（类）就好了。从真实的需求出发，保持灵活性。这是太简单的东西，希望你不要把这个看作“OOP”的困难，而应该看作入门前的一点小疑惑而已。这种东西不应该制造太多的疑惑。

Answer 5

自己画吧！如果倒退15年，痴迷UML或许是大多数OO工程人员的通病，但是自从上个世纪末以后，它被各种流派（特别是敏捷开发流派）越来越排斥了。

Answer 6

如果说画两个方框、然后画一个箭头，也要审查别人是否画得和你的一样，你会很慢地掌握OOP。软件并不是画个类型关联图，然后大家围着他畅想一番。软件设计中，画出类型关联图只是最静态、最简单的一步，软件设计需要对动态的东西：用例、时序、状态、活动、功能、界面驱动、通讯、各种底层机制进行分析设计。可是我们看到很多人花了好几年，只是学会了画类型关联图，而对其它设计图画不出来。其实这样的人除了数据库表设计，还能做多少设计？

Answer 7

用例、时序、状态、活动、功能、界面驱动、通讯、各种底层机制进行分析设计,这些不是也可以用UML图画出来分析，这样会对系统全貌有个了解不是有帮助？请问  
sp1234 是老师吗，如果是我到你那里去学习