拆分继承的类以跨团队共享 [英] Splitting an inherited class to share across teams

问题描述

嗨


我有一个数据访问层方案的通用模型。我有一个抽象的

基类，名为DalBase，它包含一系列抽象方法。让我们给b / b
打电话给他们：

public abstract void Shine（）;

public abstract void Flow（）;

public abstract void Float（）;


然后我有一个继承的类，名为DalMain，其中包含这些方法的具体实现

实现


DalMain：DalBase

{

public override void Shine（）

{

。 ..

}


public override void Flow（）

{

... < br $>
}


公共覆盖void Float（）

{

...

}

}


我有第三个类，DataAccessBaseClass，它有一个静态方法叫做

GetDalLayer（ ）检查DalMain的类型是否为DalBase，如果它是
，则返回DalMain类的类型。这样做的好处是，如果我需要在商务舱中调用Flow（），我需要做的就是：


DalBase dal = DataAccessBaseClass .GetDalLayer（）;

// dal现在是DalMain类型

dal.Flow（）;


这将是在DalMain类中调用Flow（）。一切都很好！


但是，我在团队环境中，我在
DalBase中有100多个抽象方法。这意味着DalMain的需求不断增加并造成了b
开发瓶颈。


我想将DalMain拆分为单独的负责任。课程，以便

分享功能，减轻整个团队编辑

DalMain课程的负担。

我需要做些什么来保持调用DalBase

方法的相同模式，但是从这些类中的具体实现：


公共课月亮

{

公共覆盖无效Shine（）

{

...

}

}


公共类液体

{

public override void Flow （）

{

...

}

}


公共舱气球

{

公共覆盖void Float（）

{

...

}

}


我希望能够调用Flow（）方法


DalBase dal = DataAccessBaseClass.GetDalLayer（）;

dal.Flow（）;


这将调用Liquid类中的Flow（） - 现在有了

的实现Flow（）的用法。对于Moon中的其他方法和

气球课程也一样。


我该怎么办？

Hi

I have a common model for a Data Access Layer scenario. I have an abstract
base class, called DalBase which contains a list of abstract methods. Lets
call them:
public abstract void Shine();
public abstract void Flow();
public abstract void Float();

I then have an inherited class, called DalMain which contains the concrete
implementations of these methods

DalMain : DalBase
{
public override void Shine()
{
...
}

public override void Flow()
{
...
}

public override void Float()
{
...
}
}

I have a third class, DataAccessBaseClass, which has a static method called
GetDalLayer() which checks that the type of DalMain is DalBase, and if it
is, returns the type of the DalMain class. The beauty of this is, if I need
to call Flow() in a business class, all I need to do is:

DalBase dal = DataAccessBaseClass.GetDalLayer();
//dal is now of type DalMain
dal.Flow();

and this will call the Flow() in the DalMain class. All nice and good!

However, I am in a team environment, and I have a 100+ abstract methods in
DalBase. Which means that DalMain is in constant demand and causing a
development bottleneck.

I want to split up DalMain into separate "responsible" classes, so as to
share out the functionality and place less of a burden on the editing of the
DalMain class by the entire team.

What do I need to do to retain the same mode of invoking the DalBase
methods, but from concrete implementations in these classes:

public class Moon
{
public override void Shine()
{
...
}
}

public class Liquid
{
public override void Flow()
{
...
}
}

public class Balloon
{
public override void Float()
{
...
}
}

I want to be able to call the Flow() method

DalBase dal = DataAccessBaseClass.GetDalLayer();
dal.Flow();

and this will call the Flow() in the Liquid class - which now has the
implentation for Flow(). And the same for the other methods in the Moon and
Balloon classes.

What should I do?

推荐答案

如果您使用的是.NET 2.0，请查看部分类。


John Puopolo


Codex Twin <共同*** @ more.com>在消息中写道

新闻：eZ ************** @ tk2msftngp13.phx.gbl ...

If you are using .NET 2.0, check out partical classes.

John Puopolo

"Codex Twin" <co***@more.com> wrote in message
news:eZ**************@tk2msftngp13.phx.gbl...

嗨

我有一个数据访问层场景的通用模型。我有一个抽象的基类，叫做DalBase，它包含一系列抽象方法。让我们打电话给他们：
public abstract void Shine（）;
public abstract void Flow（）;
public abstract void Float（）;

我然后有一个继承的类，名为DalMain，其中包含这些方法的具体实现

DalMain：DalBase
{
公共覆盖无效Shine（）
{
...
}
公共覆盖无效流量（）
{
...
}

public override void Float（）
{
...
}
我有第三个类，DataAccessBaseClass，它有一个静态方法
调用GetDalLayer（），它检查DalMain的类型是否为DalBase，如果它是
，则返回DalMain类的类型。这样做的好处是，如果我需要在商务舱中调用Flow（），我需要做的就是：

DalBase dal = DataAccessBaseClass.GetDalLayer（）;
// dal现在是DalMain类型
dal.Flow（）;

这将调用DalMain类中的Flow（）。一切都很好！

然而，我处于团队环境中，而且我在DalBase中有100多种抽象方法。这意味着DalMain的需求不断增加并导致了开发瓶颈。

我想将DalMain拆分为独立的负责任。课程，以便分享功能，减轻整个团队编辑DalMain课程的负担。

我需要做什么保留调用DalBase
方法的相同模式，但是从这些类中的具体实现：

public class Moon
{
公共覆盖void Shine（）
{
...
}

公共类液体
{
公共覆盖无效流量（）
{
...
}

公共课气球
{
公共覆盖void Float（）
{
...
}

我希望能够调用Flow（）方法

DalBase dal = DataAccessBaseClass.GetDalLayer （）;
dal.Flow（）;

这将调用Liquid类中的Flow（） - 它现在具有Flow（）的实现功能。对于Moon
和Balloon课程中的其他方法也一样。

我该怎么办？

Hi

I have a common model for a Data Access Layer scenario. I have an abstract
base class, called DalBase which contains a list of abstract methods. Lets
call them:
public abstract void Shine();
public abstract void Flow();
public abstract void Float();

I then have an inherited class, called DalMain which contains the concrete
implementations of these methods

DalMain : DalBase
{
public override void Shine()
{
...
}

public override void Flow()
{
...
}

public override void Float()
{
...
}
}

I have a third class, DataAccessBaseClass, which has a static method called GetDalLayer() which checks that the type of DalMain is DalBase, and if it
is, returns the type of the DalMain class. The beauty of this is, if I need to call Flow() in a business class, all I need to do is:

DalBase dal = DataAccessBaseClass.GetDalLayer();
//dal is now of type DalMain
dal.Flow();

and this will call the Flow() in the DalMain class. All nice and good!

However, I am in a team environment, and I have a 100+ abstract methods in
DalBase. Which means that DalMain is in constant demand and causing a
development bottleneck.

I want to split up DalMain into separate "responsible" classes, so as to
share out the functionality and place less of a burden on the editing of the DalMain class by the entire team.

What do I need to do to retain the same mode of invoking the DalBase
methods, but from concrete implementations in these classes:

public class Moon
{
public override void Shine()
{
...
}
}

public class Liquid
{
public override void Flow()
{
...
}
}

public class Balloon
{
public override void Float()
{
...
}
}

I want to be able to call the Flow() method

DalBase dal = DataAccessBaseClass.GetDalLayer();
dal.Flow();

and this will call the Flow() in the Liquid class - which now has the
implentation for Flow(). And the same for the other methods in the Moon and Balloon classes.

What should I do?

Codex Twin< co *** @ more.com>写道：


< snip>

Codex Twin <co***@more.com> wrote:

<snip>

但是，我在一个团队环境中，我在
我想将DalMain拆分为独立的负责任。课程，以便分享功能，减轻整个团队编辑DalMain课程的负担。

However, I am in a team environment, and I have a 100+ abstract methods in
DalBase. Which means that DalMain is in constant demand and causing a
development bottleneck.

I want to split up DalMain into separate "responsible" classes, so as to
share out the functionality and place less of a burden on the editing of the
DalMain class by the entire team.

几种可能性：


1）首先没有一个基类 - 将它分成几个
。这听起来好像是个好主意。


2）将DalBase更改为多个接口，并有一个代理类

实现所有接口。将DalMain拆分为几个较小的

类，每个类都实现一个接口。代理类将

创建每个较小类的实例，并将每个接口的

方法调用转发到相应的实现。

-

Jon Skeet - < sk *** @ pobox.com>
http://www.pobox.com/~skeet

如果回复该群组，请不要给我发邮件。 />

A couple of possibilities:

1) Don''t have a single base class in the first place - split it into
several. This sounds like it would be a good idea anyway.

2) Change DalBase to several interfaces, and have a proxy class which
implements all the interfaces. Split DalMain into several smaller
classes, each implementing a single interface. The proxy class would
create an instance of each of the smaller classes, and forward the
method calls for each interface to the appropriate implementation.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

" Jon Skeet [C＃MVP]" < SK *** @ pobox.com>写道：

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote:

几种可能性：

1）首先没有一个基类 - 将其拆分为
一些。这听起来好像无论如何都是个好主意。

2）将DalBase更改为多个接口，并拥有一个代理类，
实现所有接口。将DalMain拆分为几个较小的
类，每个类实现一个接口。代理类将
创建每个较小类的实例，并将每个接口的
方法调用转发到适当的实现。

A couple of possibilities: 1) Don''t have a single base class in the first place - split it into several. This sounds like it would be a good idea anyway. 2) Change DalBase to several interfaces, and have a proxy class which implements all the interfaces. Split DalMain into several smaller classes, each implementing a single interface. The proxy class would create an instance of each of the smaller classes, and forward the method calls for each interface to the appropriate implementation.

Jon


谢谢！我真的很喜欢你所解释的第二个想法的声音。


从我的解决方案和代理设计模式的阅读（我看起来是
up），这是我对你的建议的理解：


1）DalBase类改为更小的接口：


IDalBalloon和IDalLiquid <它们分别包含Float（）和Flow（）的定义。


2）将DalMain分成较小的类，每个类实现一个较小的接口：


//气球 - 现在包含Float（）的具体实现


公共类气球：IDalBalloon


{


public void Float（）


{。}


}


//液体 - 现在包含Flow的具体实现（）


公共类液体：IDalLiquid


{


public void Flow（）


{。}


}


3）H ave一个代理，实现所有接口并创建一个实例

的各个类：


公共类DalProxy：IDalBalloon，IDalLiquid


{


//会员


//某种形式的实例化


气球气球=新气球（）;


//施放到IDalBalloon以检查它是否是IDalBalloon


IDalBalloon isBalloon = balloon作为IDalBalloon;


液体液体=新液体（）;


//施放到IDalLiquid以检查它是否是IDalLiquid


IDalLiquid isLiquid =液体作为IDalLiquid;


Public void Float（）


{


if（isBalloon！= null）


isBalloon.Float（）;


else


抛出新的异常（气球必须

实施IDalBalloon）;


}


Public void Flow（）


{


if（i液体！= null）


isLiquid.Flow（）;


其他


扔新品例外（Liquid必须

实施IDalLiquid）;


}


}


4）然后在客户端。


DalProxy p =新的DalProxy;


//调用Flow（）


p.Flow（）;


//调用Float（）


p。 Float（）;


这解决了我的两个问题中的第一个问题：具有

类的逻辑层，它们执行所有具体实现并且必须是

可互换。换句话说，我现在可以拥有一个SQL类库：

（实现IDalBalloon的SqlBalloon）和Oracle

类的替代库（实现IDalBalloon的OracleBalloon）。


但是，使用一个代理类（DalProxy）来调用方法

会出现同样的问题，即我在我的
中遇到一个DalMain
解决方案。这意味着让编辑DalProxy的团队排在队伍中的开发瓶颈仍然存在！


但好的是，我可以拥有专业代理类的数量，

DalBalloonProxy和DalLiquidProxy分别实现了IDalBalloon和

IDalLiquid接口，每个接口都对他们的方法负责

具体来说。


再次感谢。

Jon

Thanks! I really like the sound of the second idea you''ve explained.

From my reading of your solution and the Proxy design pattern (which I
looked up), this is my understanding of your suggestion:

1) The DalBase class is changed to smaller interfaces:

IDalBalloon and IDalLiquid

They contain definitions for Float() and Flow() respectively.

2) Split DalMain into smaller classes each implementing a smaller interface:

// Balloon - now contains a concrete implementation of Float()

public class Balloon : IDalBalloon

{

public void Float()

{.}

}

//Liquid - now contains a concrete implementation of Flow()

public class Liquid : IDalLiquid

{

public void Flow()

{.}

}

3) Have one proxy which implements all the interface and creates an instance
of the individual classes:

public class DalProxy : IDalBalloon, IDalLiquid

{

//Members

//some form of instantiation

Balloon balloon = new Balloon();

//cast to IDalBalloon to check if it is an IDalBalloon

IDalBalloon isBalloon = balloon as IDalBalloon;

Liquid liquid = new Liquid();

//cast to IDalLiquid to check if it is an IDalLiquid

IDalLiquid isLiquid = liquid as IDalLiquid;

Public void Float()

{

if (isBalloon != null)

isBalloon.Float();

else

throw new Exception("Balloon must
implement IDalBalloon");

}

Public void Flow()

{

if (iLiquid != null)

isLiquid.Flow();

else

throw new Exception("Liquid must
implement IDalLiquid");

}

}

4) Then in a client.

DalProxy p = new DalProxy;

//invoke Flow()

p.Flow();

//invoke Float()

p.Float();

This solves the first of my two problems: that of having a logical layer of
classes which do all the concrete implementation and have to be
interchangeable. In other words I can now have a library of SQL classes:
(SqlBalloon implementing IDalBalloon) and an alternative library of Oracle
classes (OracleBalloon implementing IDalBalloon).

However, using one single Proxy class (DalProxy) for invoking the methods
would present the same problem of having one DalMain, that I faced in my
solution. It means that the development bottleneck of having the team lining
up to edit DalProxy would still be there!

But the good thing is, I can have a number of specialist Proxy classes,
DalBalloonProxy and DalLiquidProxy which each implements the IDalBalloon and
IDalLiquid interfaces respectively, and each is responsible to their methods
specifically.

Thanks again.

这篇关于拆分继承的类以跨团队共享的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！