问题标签 [ooad]

我有一个场景，我正在为零售商设计一个系统。这不是一个合适的实时应用程序，而只是一个检查我的 OO 设计技能是否正确以及我的思维是否正确的场景。我还在这儿学习。我在 c# 中这样做。

场景是这样的：

一家销售固定产品的零售商想要设计一个系统，该系统将从他的各种固定数量的供应商中选择最优惠的价格并向该供应商下订单。为简单起见，我将固定产品缩减为同一公司的一种产品，即 XYZ 笔。当被询问时，每个供应商都将提供 XYZ 笔的报价，并且零售商系统从各个卖家中选择最优惠的价格并从该卖家下订单。

方法一：

1. 为供应商创建一个抽象类并为每个供应商创建一个实现。
2. 每个供应商实现都有一个 PlaceOrder() 方法和一个成本属性。
3. DataLayer 为每个供应商实现设置成本属性。
4. 创建一个 CheckBestRetailer 类，该类评估每个实现以获得最佳价格并在适当的实现上下订单。

方法二：

1. 使用 Cost 属性和 PlaceOrder() 方法创建类型供应商列表。
2. 对于每个供应商，数据层将新的供应商类型添加到列表中，并设置从数据库中获取的成本详细信息。
3. CheckBestRetailer 类循环遍历该列表并评估每个对象以获得最佳价格，并在适当的实现上下订单。

在上述两个中，我觉得方法 1 更接近 OOP，但前提是我有固定数量的供应商。如果供应商的数量可以根据从数据库中检索到的数据而改变，那么方法 2 会更好。

你怎么看？

我可能没有最好的方案来测试我的 OOAD。希望有一些我也可以使用的示例场景……如果可能的话，带有设计提示。

谢谢你的时间。

最近一直在学习一些面向对象的分析和设计，感觉总体感觉还不错。

但是这个小场景一直困扰着我。

假设我正在设计一个简单的棋盘游戏。我有班级游戏，其中包含有关董事会和球员的信息。播放器是从 Player 类创建的。所有玩家都有一个从 BankAccount 类创建的银行账户。

我的游戏处理关于移动后应该发生什么的逻辑。大多数情况下，这涉及从玩家的银行账户中提取或存入一些金额。

My BankAccount 有取款、存款和返还余额的方法。但我的游戏不知道玩家的银行账户。仅关于玩家。我是否给我的 Player 类一个方法 getAccount，以便我可以调用playerObject.getAccount().withdraw()？或者我该如何分配这种行为的责任？我的 Player 类是否应该实现一个withdraw()只调用account.withdraw()其关联帐户对象的方法？

在管理职业培训的系统中，我有一个CourseBase抽象类，我决定使用它来支持ICourse接口，因为我更愿意避免为从假设的基本Course实体派生的所有类重复实现代码。每门课程都有一个主题列表，其中任何主题都由SubjectBase抽象类定义。所以，我有例如

现在我想添加一个LocalCourse包含LocalCourseSubject对象集合的具体类，但是因为我没有使用接口CourseBase，所以我失去了协方差，我需要Subjects用我的新对象隐藏抽象基的属性：

我敢肯定，从 OO 的角度来看，我在这里遗漏了一些非常明显的东西，但我能看到的唯一解决方案是：

1. 从抽象基础中完全省略 Subjects，并且只向派生类添加特定类型的集合属性。
2. ISubjectCollectionOwner在抽象基类和具体类中实现接口。

请原谅我在这里的昏暗，我已经有一段时间没有遇到这样的设计问题了。

我正在开发一个以大约 4 个基本实体为核心的多线程应用程序

例如

我有一个 4 步流程，我使用带有 BlockingCollections 的生产者/消费者模式来管理这些流程。这是一条生产线，一旦完成，我会修改对象的状态，将统计信息和队列复制到下一个进程队列中，等待下一个进程/任务执行。

我正处于架构设计的关键时刻，我是否需要考虑将一些 BlockingCollections 序列化到 DB，或者我是否可以在高端服务器上的 Pipe 中运行大约 1000 万个上述类型的对象。

我有一个队列专用于每个进程的统计信息，即 UI 的 Timetaken/Success 或者我应该考虑将这些信息与对象一起存储吗？

速度/效率在此过程中至关重要。

有什么方法可以计算内存需求，或者这是一个糟糕的情况，看看

更新在这个阶段，我不需要为崩溃等保存数据，因为元数据对象被修改并写入磁盘......即未处理的文件夹/已处理的文件夹

我最近一直在做一些面向对象的设计。我还使用 EF 4.1 作为 ORM。现在，当我设计我的课程及其关联时，我可以考虑两种方法。一个是例如老师教一门学科。因此，Teacher 类可以将主题对象的引用作为属性（基于引用的方法），也可以将 SubjectId 作为属性（基于 ID 的方法）。我不确定应该采取哪种方法，为什么？我相信基于 ID 的方法更像是一种关系数据方法，而基于引用的方法是真正的 OO 方法。但我不确定。

我有一个解析 XML 文件的进程。

这发生在 PAckage 类中。

Package 类有一个 Delegate，它将对象设置为无效状态并捕获有关 Package Class 发生的错误的详细信息

为简单起见，我展示了传递给包的文件。

即`

在包裹里面我的验证看起来像这样

在此验证中，我检查是否为标签返回“”...如果是，则使用错误信息调用 Failpackage 并创建异常

通过包含的 try catch 块捕获

我担心的是我正在为程序流使用异常......我应该如何看待这个问题或者这是一个有效的模式。

我有一个类如下的 C# 组件：

在另一个现有的 C# 应用程序中，我引用了这个组件，我需要实例化这个相同的类，但使用如下的附加标识符。

在客户端应用程序中，有几种方法依赖于附加标识符。所以我很想模拟一个复制构造函数并创建这个对象并填写附加参数。这样我就可以使用现有的函数，只需对类进行最小的更改。

另一种方法是添加其余细节作为对客户端实现的参考。

哪个选项更好？这方面的最佳做法是什么？

环境：VS2008、C#、WinXP/Win7

以下有什么问题，我将如何使用 OO 原则更好地实现它？

我的应用程序包含一堆形状类，它们都继承自Shape- Circle, Rectangle,Triangle等。其中一些需要显示在屏幕上，在这种情况下它们需要利用通用屏幕逻辑，所以有一个ScreenShape包含通用逻辑的超类，和ScreenCircle,ScreenTriangle子类。

I have a code which was not refactored at all. I refactored it to some extent..but stuck at a point where I cannot think of anything further.

Tractor.java:

TractorInDitchException.java

MethodsInterface.java

What else could be refactored...any suggestions please?

假设我有一个要求，其中我有包含区域作为唯一操作的形状。那么我应该使用 area() 作为抽象方法的接口还是抽象类？问这个问题的原因是：在纯面向对象术语中，所有行为映射到方法，属性映射到数据成员。那么面积是类的行为或（计算的）属性？哪一个更适合特定用例？以 area() 作为方法的接口或以 area() 作为抽象方法的抽象类的接口？