4
私は、時折Single Responsibility Principleを破ることが許容されるのか、まったく避けるべきかを理解するのが難しいです。SRPは常に尊重されるべきですか？
次のコードは、関連する部分のみを保持するために簡略化されています。
私は文字を表すHeroクラスを持っていますが、それは異なるItemsの倍数を持つことができます。
私はItemsを継承する倍数クラスを持っています。例えば、QuestItemsとBackpackItemsです。
私はにItemを追加したいときは、種類によってはItemと違うはずです。
私は最初のものは、SRPを尊重することを行うには2つの異なる方法を試してみた：
public abstract class Item
{
private string _Name{get;set;}
public string Name
{
get
{
return _Name;
}
protected set
{
if (_Name != value)
{
_Name = value;
}
}
}
}
public class QuestItem: Item
{
public QuestItem(String name)
{
Name = name;
}
}
public class BackpackItem: Item
{
public BackpackItem(String name)
{
Name = name;
}
}
public class Hero
{
public void AddItem(Item item){
if(item is QuestItem){
//Do stuff to add QuestItem
return;
}
if(item is BackpackItem){
//Do stuff to add BackpackItem
return;
}
}
}
利点：SRPが
デメリットを尊重している：私は一種Itemから継承する新しいアイテムを作成し、私を変更することを忘れた場合をAddItemの機能はHeroです。
SRPを尊重していない私の第二の溶液：
public abstract class Item
{
private string _Name{get;set;}
public string Name
{
get
{
return _Name;
}
protected set
{
if (_Name != value)
{
_Name = value;
}
}
}
public abstract void AddToHero(Hero hero);
}
public class QuestItem: Item
{
public QuestItem(String name)
{
Name = name;
}
public override void AddToHero(Hero hero)
{
//Do my stuff to add my QuestItem to Hero
}
}
public class BackpackItem: Item
{
public BackpackItem(String name)
{
Name = name;
}
public override void AddToHero(Hero hero)
{
//Do my stuff to add my BackpackItem to Hero
}
}
利点：：私はからのaddメソッドを忘れることができない
私のAddItemメソッドの機能は、私のアイテムクラスになる
public void AddItem(Item item){
item.AddToHero(this);
}
になりますコンパイル時にエラーが発生するので、新しいItemの種類。 短所：私はSRPを尊重していませんが、今は私が本当になぜそれが悪いのか分かりません。
どのような実装を使いたいですか？ （別のもの？）
あなたはSRPだけ、またはすべてのSOLIDに興味がありますか？最初の例では、Hero.AddItemメソッドがOpen/Closeの原則を破るためです。 –
私はコードの品質を向上させるためのベストプラクティスを学び、適用する方法に興味があります。 私は本当に変えるべきことは何でもあります。 – Belterius