循环依赖:IVisitor 和 Datas
Cyclic depenency: IVisitor and Datas
我最近问的是循环依赖。答案是将一个项目专门用于接口 (MyProject.Abstractions
)。现在,这个项目是另一个循环依赖的原因,具有访问者模式。
namespace MyProject.Abstractions
{
public interface ICharacter { }
public interface ICharacterVisitor
{
// References MyProject.Characters
void Visit(Warrior warrior);
void Visit(Wizard wizard);
}
}
namespace MyProject.Characters
{
// References MyProject.Abstractions
public abstract class CharacterBase : ICharacter { }
public class Warrior : CharacterBase { }
public class Wizard : CharacterBase { }
}
这是否意味着我的 ICharacterVisitor 应该在我的 MyProject.Characters
项目中?我将整个解决方案作为我的 SOLID 训练练习。
访客是一种适用于现有结构但不是其一部分的工具。因此,我会将访问者与您正在访问的数据分开。
namespace MyProject.Abstractions.Characters
{
public interface ICharacter { }
}
using MyProject.Abstractions.Characters;
namespace MyProject.Characters
{
public abstract class CharacterBase : ICharacter { }
public class Warrior : CharacterBase { }
public class Wizard : CharacterBase { }
}
using MyProject.Abstractions.Characters;
using MyProject.Characters;
namespace MyProject.Abstractions.Visitors
{
public interface ICharacterVisitor
{
// References MyProject.Characters
void Visit(Warrior warrior);
void Visit(Wizard wizard);
}
}
using MyProject.Abstractions.Characters;
using MyProject.Abstractions.Visitors
using MyProject.Characters;
namespace MyProject.Visitors
{
// Concrete visitors here
}
您不一定需要为每个命名空间创建一个单独的项目。访客资料可能与 MyProject.Characters
在同一个项目中。 SOLID 是关于代码的逻辑组织,而不是物理的。这个对 benefits of multiple Projects and One Solution 的回答列出了拥有多个项目的充分理由。
就其本质而言,访问者模式确实倾向于引入循环依赖 - 访问者界面必须知道它所操作的所有不同 classes,并且每个人都必须以某种方式知道如何调用正确的访问者上的方法,这意味着了解访问者 class.
您可以通过以下方式打破这种循环依赖:
// Abstractions project
interface ICharacter
{
string Name { get; }
}
interface IWarrior : ICharacter
{
void Attack();
}
interface IWizard : ICharacter
{
void CastSpell();
}
interface IVisitor
{
void Visit(IWarrior w);
void Visit(IWizard w);
}
// implementations project
abstract class CharacterBase : ICharacter
{
public string Name { get; }
public abstract void Accept(IVisitor v);
}
class Warrior : CharacterBase, IWarrior
{
public void Attack()
{
// do warrior things
}
public override void Accept(IVisitor v)
{
v.Visit(this);
}
}
class Wizard : CharacterBase, IWizard
{
public void CastSpell()
{
// do wizardly things
}
public override void Accept(IVisitor visitor)
{
visitor.Visit(this);
}
}
假设您确实需要 "CharacterBase" class 来保存字符之间的某种共享 functionality/properties。
这是否值得是您必须做出的决定,因为访客模式的性质才是真正的问题 - 您将来添加更多字符类型的可能性有多大?您添加更多访问者的可能性有多大?有没有一种方法可以让每种类型的角色自己决定在特定场景中需要采取什么行动?
我最近问的是循环依赖。答案是将一个项目专门用于接口 (MyProject.Abstractions
)。现在,这个项目是另一个循环依赖的原因,具有访问者模式。
namespace MyProject.Abstractions
{
public interface ICharacter { }
public interface ICharacterVisitor
{
// References MyProject.Characters
void Visit(Warrior warrior);
void Visit(Wizard wizard);
}
}
namespace MyProject.Characters
{
// References MyProject.Abstractions
public abstract class CharacterBase : ICharacter { }
public class Warrior : CharacterBase { }
public class Wizard : CharacterBase { }
}
这是否意味着我的 ICharacterVisitor 应该在我的 MyProject.Characters
项目中?我将整个解决方案作为我的 SOLID 训练练习。
访客是一种适用于现有结构但不是其一部分的工具。因此,我会将访问者与您正在访问的数据分开。
namespace MyProject.Abstractions.Characters
{
public interface ICharacter { }
}
using MyProject.Abstractions.Characters;
namespace MyProject.Characters
{
public abstract class CharacterBase : ICharacter { }
public class Warrior : CharacterBase { }
public class Wizard : CharacterBase { }
}
using MyProject.Abstractions.Characters;
using MyProject.Characters;
namespace MyProject.Abstractions.Visitors
{
public interface ICharacterVisitor
{
// References MyProject.Characters
void Visit(Warrior warrior);
void Visit(Wizard wizard);
}
}
using MyProject.Abstractions.Characters;
using MyProject.Abstractions.Visitors
using MyProject.Characters;
namespace MyProject.Visitors
{
// Concrete visitors here
}
您不一定需要为每个命名空间创建一个单独的项目。访客资料可能与 MyProject.Characters
在同一个项目中。 SOLID 是关于代码的逻辑组织,而不是物理的。这个对 benefits of multiple Projects and One Solution 的回答列出了拥有多个项目的充分理由。
就其本质而言,访问者模式确实倾向于引入循环依赖 - 访问者界面必须知道它所操作的所有不同 classes,并且每个人都必须以某种方式知道如何调用正确的访问者上的方法,这意味着了解访问者 class.
您可以通过以下方式打破这种循环依赖:
// Abstractions project
interface ICharacter
{
string Name { get; }
}
interface IWarrior : ICharacter
{
void Attack();
}
interface IWizard : ICharacter
{
void CastSpell();
}
interface IVisitor
{
void Visit(IWarrior w);
void Visit(IWizard w);
}
// implementations project
abstract class CharacterBase : ICharacter
{
public string Name { get; }
public abstract void Accept(IVisitor v);
}
class Warrior : CharacterBase, IWarrior
{
public void Attack()
{
// do warrior things
}
public override void Accept(IVisitor v)
{
v.Visit(this);
}
}
class Wizard : CharacterBase, IWizard
{
public void CastSpell()
{
// do wizardly things
}
public override void Accept(IVisitor visitor)
{
visitor.Visit(this);
}
}
假设您确实需要 "CharacterBase" class 来保存字符之间的某种共享 functionality/properties。
这是否值得是您必须做出的决定,因为访客模式的性质才是真正的问题 - 您将来添加更多字符类型的可能性有多大?您添加更多访问者的可能性有多大?有没有一种方法可以让每种类型的角色自己决定在特定场景中需要采取什么行动?