我与同事讨论了我们项目中这些主题的方法。 我正在创建一个进度系统,简而言之是一个ProgressMonitor类和一个Task类,ProgressMonitor处理一系列任务。所有非常简单的东西。但是当涉及到ui任务时,我们不得不发表意见。 每个任务都有自己的UI。我们同意应该有一个用于处理UI的HUD类。 意见分歧是,他希望HUD处理每个特定任务的UI,因此HUD类将变得很大,并且该任务的UI几乎没有逻辑。 我认为,HUD将只处理项目中需要UI的所有事物都相同的逻辑,而所有特定逻辑均由需要UI的对象处理。 他的优点是拥有一些所有权(需要访问一些ui信息的对象可以从HUD轻松获取它) 我的优点是,HUD保持轻巧清洁且可重复使用。
根据OOP,更正确的方法是什么?
答案 0 :(得分:2)
我将从影响实施的问题开始:
问题1: 任务与其用户界面紧密相关吗?
问题2:所有任务的UI相同还是略有不同?
问题3:您是否需要根据特定任务为每个任务显示不同的UI?
如果对问题1 的回答为是,并且很难将两个职责区分开,则将UI逻辑添加到任务可以使事情变得简单很多。
如果对问题2 的回答为是,则使用经典的模型/视图分离将使编写新任务更加容易,因为您只需将任务逻辑添加到任务类。
您可以拥有一个 TasksHUD 类,该类将负责处理 TaskUI 类的列表。每个 TaskUI 类都将关联一个 Task ,并处理此特定任务的UI和表示逻辑的呈现。
这样,您的 TasksHUD 类将管理列表向用户显示的方式,而每个列表条目将由 TaskUI 类处理。任务演示代码将被重用。
任务仅负责执行,更改其状态以及任务必须在您的应用程序中执行的其他操作(如果您提供更多详细信息,我可以提供更多详细信息以及可能更准确的描述),而呈现任务的责任将分配给 TaskUI 。
这样,如果您需要更改呈现任务的逻辑,则只需更改 TaskUI 类。
您可以编写尽可能多的任务,而无需为这些任务编写与UI相关的代码。
如果您需要更改 Task 类,由于依赖项从 TaskUI 变为< strong>任务。某些更改会影响UI,而某些更改不会。
如果问题3 的答案是是,则:
您可以将处理UI的职责添加到任务。这样,更改它们将变得更加容易,因为它们属于同一类。这里的一个问题是 Task 类可能会增加承担多种责任。还共享类似任务等的渲染代码。
在这种情况下,您可以将 Task 与UI分离成两个类,即 Task 和 TaskUI ,但是您需要一种机制应用程序,它将特定的 Task 类与其 TaskUI 类相关联。这可能会导致更多的类,并且可能导致不必要的复杂性。从长远来看,它可以节省您的时间(主要是避免追查错误)。
这是一个伪代码示例:
interface TaskObserver {
void onTaskChanged(t);
}
interface TaskUI {
void render();
}
interface TaskUIFactory {
register(TaskUIFactoryRegistry registry);
TaskUI create(Task task);
}
interface Task {
TaskStatus status;
execute();
addEventListener(TaskObserver o);
}
class TaskA : Task {
// implementation.....
}
class TaskA_UI : TaskUI, TaskObserver {
TaskA mTask;
TaskA_UI(TaskA task) {
mTask = task;
mTask.addEventListener(this);
}
render() {
// rendering goes here
}
onTaskChanged(t) {
// raise an event or signal to the TaskHUD that a refresh is needed
}
}
class TaskA_UIFactory : TaskUIFactory {
void register(TaskUIFactoryRegistry registry) {
registry.Register(typeof(TaskA), this);
}
TaskUI createUI(Task task) {
return new TaskA_UI((TaskA)task);
}
}
添加任务后,您的TasksHUD可以使用TaskUIFactoryRegistry获取将创建TaskUI的TaskUIFactory。
您可以查看一些资源来讨论这类问题: