我有一个抽象基类和两个派生类。基类包含6个属性,这些属性都可以在表单上维护。
两个派生类别都有1个额外属性。这两个属性也可以在同一个表单上维护。
在我的表单中,我现在有这样的代码:
btnSomething.visible = (myObject is DerivedA);
pnlPanel.visible = !(myObject is DerivedA);
if(myObject is DerivedA)
myBindingSource.DataSource = myObject as DerivedA
mySecondBindingSource = myObject;
我对这种方法不是很满意,它闻起来很香。所以我的问题是,什么是一个整洁/好的方式来使这更多的OO?因为未来DerivedC可能会出现......
我认为这种方法打破了OCP原则(可能还有其他原则)
答案 0 :(得分:2)
您可以在此处使用多态和继承:
定义界面
interface ICommonFeatures
{
bool ContainsFoo {get;}
//yak-yak
}
然后你的派生类实现它
class DerivedA: ICommonFeatures
{
bool ContainsFoo {get {return true;}}
//so-and-so
}
class DerivedB: ICommonFeatures
{
bool ContainsFoo {get {return false;}}
//this-and-that
}
当你使用它时,你只处理界面
ICommonFeatures foo = new DerivedB();
btnSomething.visible = foo.ContainsFoo;
pnlPanel.visible = foo.Prop2;
myBindingSource.DataSource = foo.CurrentDataSource
答案 1 :(得分:0)
一个疯狂的想法是让UI可扩展。 您可以使表单实现基本表单。
然后在派生的表单类中,您只会为其模型类插入缺少的控件和行为。 在派生的模型类或库中,您可以对正确的表单进行某种排序绑定。
这方面的一个好方法是遵循一些MVP原则。
希望它能以某种方式帮助你......
答案 2 :(得分:0)
我会为需要根据基础类型执行的每个控件声明一个抽象的布尔方法/属性。
例如
// to handle pnlPanel.visible = !(myObject is DerivedA);
abstract bool SupportsPanel{get;}
至于您的绑定来源,我还会提供一些虚拟BindingSource
和SecondBindingSource
属性。
也许像(纯粹是一个例子)
public abstract class BaseClass
{
// All your exising class declaration here
public virtual object BindingSource
{
get
{
// By default, a BaseClass is not valid as a binding source
return null;
}
}
public virtual object SecondBindingSource
{
get
{
// By default, a BaseClass is a valid Second Binding source
return this;
}
}
}
public class DerivedA : BaseClass
{
// All your exising class implementation here
public override object BindingSource
{
get
{
// For DerivedA, the data sourse is itself.
// other classes might have their own implementations.
return this;
}
}
// No need to override SecondBindingSource as the BaseClass one works as expected.
}
因此,您的代码可能会停止关注对象类型,如下所示:
myBindingSource.DataSource = myObject.BindingSource;
mySecondBindingSource = myObject.SecondBindingSource;
希望这有帮助。