编辑1:忘记添加嵌套属性曲线球。
更新:我选择了@mtazva的答案,因为这是我的具体案例的首选解决方案。回想起来,我用一个非常具体的例子提出了一个一般性问题,我相信这最终让每个人(或者也许只是我)对问题到底是什么感到困惑。我确实相信一般问题也已得到解答(请参阅策略模式答案和链接)。谢谢大家!
大型 switch 语句显然气味,我已经看到了一些关于如何使用 < 来做到这一点的链接a href="http://elegantcode.com/2009/01/10/refactoring-a-switch-statement/" rel="nofollow noreferrer">映射到的字典功能。但我想知道是否有更好(或更聪明)的方法来做到这一点?在某种程度上,这是一个我一直在脑海中盘旋的问题,但从未真正找到一个好的解决方案。
这个问题源于我之前问的另一个问题: 如何使用 C# 在 .Net 中的类型化对象列表中选择对象属性的所有值
这是我正在使用的一个示例类(来自外部的来源):
public class NestedGameInfoObject
{
public string NestedName { get; set; }
public int NestedIntValue { get; set; }
public decimal NestedDecimalValue { get; set; }
}
public class GameInfo
{
public int UserId { get; set; }
public int MatchesWon { get; set; }
public long BulletsFired { get; set; }
public string LastLevelVisited { get; set; }
public NestedGameInfoObject SuperCoolNestedGameInfo { get; set; }
// thousands more of these
}
不幸的是,这是来自外部来源......想象一下来自侠盗猎车手之类的巨大数据转储。
我只想获取这些对象列表的一小部分。想象一下,我们希望能够将您与您朋友的一堆游戏信息对象进行比较。一个用户的单独结果如下所示:
public class MyResult
{
public int UserId { get; set; } // user id from above object
public string ResultValue { get; set; } // one of the value fields from above with .ToString() executed on it
}
以及我想要用更易于管理的内容替换的示例(相信我,我不想维护这个怪物 switch 语句):
const int MATCHES_WON = 1;
const int BULLETS_FIRED = 2;
const int NESTED_INT = 3;
public static List<MyResult> GetMyResult(GameInfo[] gameInfos, int input)
{
var output = new List<MyResult>();
switch(input)
{
case MATCHES_WON:
output = gameInfos.Select(x => new MyResult()
{
UserId = x.UserId,
ResultValue = x.MatchesWon.ToString()
}).ToList<MyResult>();
break;
case BULLETS_FIRED:
output = gameInfos.Select(x => new MyResult()
{
UserId = x.UserId,
ResultValue = x.BulletsFired.ToString()
}).ToList<MyResult>();
break;
case NESTED_INT:
output = gameInfos.Select(x => new MyResult()
{
UserId = x.UserId,
ResultValue = x.SuperCoolNestedGameInfo.NestedIntValue.ToString()
}).ToList<MyResult>();
break;
// ad nauseum
}
return output;
}
所以问题是有没有合理的如何管理这个野兽?我真正想要的是一种动态方式来获取此信息,以防初始对象发生更改(例如添加更多游戏信息属性)。有没有更好的方法来构建它,使其不那么笨拙?
EDIT 1: Forgot to add the nested property curve ball.
UPDATE: I have chosen @mtazva's answer as that was the preferred solution for my specific case. In retrospect, I asked a general question with a very specific example and I believe that ended up confusing everyone (or maybe just me) as to what the question was exactly. I do believe the general question has been answered as well (see the Strategy pattern answers and links). Thanks everyone!
Large switch statements obviously smell and I have seen some links on how you could do this with a dictionary that maps to functions. But I'm wondering if there is a better (or smarter way) to do this? In a way, this is a question I've always sort of had rolling around in the back of my head but never really had a good solution to.
This question stemmed from another question I asked earlier: How to select all the values of an object's property on a list of typed objects in .Net with C#
Here is an example class I'm working with (from an external source):
public class NestedGameInfoObject
{
public string NestedName { get; set; }
public int NestedIntValue { get; set; }
public decimal NestedDecimalValue { get; set; }
}
public class GameInfo
{
public int UserId { get; set; }
public int MatchesWon { get; set; }
public long BulletsFired { get; set; }
public string LastLevelVisited { get; set; }
public NestedGameInfoObject SuperCoolNestedGameInfo { get; set; }
// thousands more of these
}
Unfortunately, this is coming from an external source... imagine a HUGE data dump from Grand Theft Auto or something.
And I want to get just a small cross section of a list of these objects. Imagine we want to be able to compare you with a bunch of your friends' game info objects. An individual result for one user would look like this:
public class MyResult
{
public int UserId { get; set; } // user id from above object
public string ResultValue { get; set; } // one of the value fields from above with .ToString() executed on it
}
And an example of what I want to replace with something more manageable (believe me, I DON'T want to be maintaining this monster switch statement):
const int MATCHES_WON = 1;
const int BULLETS_FIRED = 2;
const int NESTED_INT = 3;
public static List<MyResult> GetMyResult(GameInfo[] gameInfos, int input)
{
var output = new List<MyResult>();
switch(input)
{
case MATCHES_WON:
output = gameInfos.Select(x => new MyResult()
{
UserId = x.UserId,
ResultValue = x.MatchesWon.ToString()
}).ToList<MyResult>();
break;
case BULLETS_FIRED:
output = gameInfos.Select(x => new MyResult()
{
UserId = x.UserId,
ResultValue = x.BulletsFired.ToString()
}).ToList<MyResult>();
break;
case NESTED_INT:
output = gameInfos.Select(x => new MyResult()
{
UserId = x.UserId,
ResultValue = x.SuperCoolNestedGameInfo.NestedIntValue.ToString()
}).ToList<MyResult>();
break;
// ad nauseum
}
return output;
}
So the question is are there any reasonable ways to manage this beast? What I'd really like is a dynamic way to get this info in case that initial object changes (more game info properties are added, for instance). Is there a better way to architect this so it's less clumsy?
发布评论
评论(10)
我认为你的第一句话回避了可能是最合理的解决方案:某种形式的字典将值映射到方法。
例如,您可以定义一个静态
Dictionary>
,其中 MATCHES_WON 等每个值都将添加相应的 lambda,以提取适当的值(假设您的常量等的定义如您的示例中所示):然后您可以使用此字典来提取示例方法中的值:
在此选项之外,您可能会使用某种文件/数据库/存储的查找数字和属性名称,然后使用反射来提取值,但这显然效果不佳。
I think your first sentence eluded to what is probably the most reasonable solution: some form of dictionary mapping values to methods.
For example, you could define a static
Dictionary<int, func<GameInfo, string>>
, where each value such as MATCHES_WON would be added with a corresponding lambda that extracts the appropriate value (assuming your constants, etc are defined as shown in your example):You can then use this dictionary to extract the value in your sample method:
Outside of this option, you could potentially have some sort of file/database/stored lookup with the number and the property name, then use reflection to extract the value, but that would obviously not perform as well.
我认为这段代码有点失控了。您有效地使用常量来索引属性 - 这会创建脆弱的代码,您希望使用某些技术 - 例如 - 反射、字典等 - 来控制增加的复杂性。
实际上,您现在使用的方法最终会得到如下代码:
另一种方法是定义一个扩展方法来让您执行此操作:
这是强类型的,它不需要常量、switch 语句、反射或任何神秘的东西。
只需编写这些扩展方法就可以了:
这对您有用吗?
I think this code is getting out of hand a bit. You're effectively using constants to index properties - and this is creating fragile code that you're looking to use some technique - such as - reflection, dictionaries, etc - to control the increased complexity.
Effectively the approach that you're using now will end up with code like this:
The alternative is to define an extension method that lets you do this:
This is strongly-typed, it doesn't require constants, switch statements, reflection, or anything arcane.
Just write these extension methods and you're done:
Does that work for you?
您可以将反射用于这些目的。您可以实现自定义属性、标记您的属性等。此外,如果类发生更改,它也是获取类信息的动态方式。
You can use reflection for theses purposes. You can implement custom attributes, mark your properties, etc. Also, it is dynamic way to get info about your class if it changes.
如果您想管理开关代码,我会向您推荐《设计模式》一书(GoF),并建议您可能查看诸如
Strategy
和可能的Factory
之类的模式(这就是我们谈论一般性的模式)案例使用,您的案例不太适合工厂)并实现它们。虽然在重构模式完成后, switch 语句仍然必须留在某处(例如,在通过 id 选择策略的地方),但代码将更加可维护和清晰。
这就是关于一般交换机维护的情况,如果它们变得像野兽一样,鉴于您的案例陈述看起来多么相似,我不确定其最佳解决方案。
我 100% 确定您可以创建一些方法(可能是扩展方法)来接受所需的属性访问器 lambda,在生成结果时应该使用该方法。
If you want to manage switch code I would point you at Design Patterns book (GoF) and suggest possibly looking at patterns like
Strategy
and possiblyFactory
(thats when we talk about general case use, your case isn't very suited for Factory) and implementing them.While switch statement still has to be left somewhere after refactoring to pattern is complete (for example, in a place where you select strategy by id), code will be much more maintanable and clear.
That said about general switch maintenance, if they become beast like, I am not sure its best solution given how similar your case statements look.
I am 100% sure you can create some method (possibly an extension method) that will be accepting desired property accessor lambda, that should be used when results are generated.
如果您希望您的代码更通用,我同意字典或某种查找模式的建议。
您可以将函数存储在字典中,但它们似乎都执行相同的操作 - 从属性获取值。反思的时机已经成熟。
我会将所有属性存储在一个字典中,并以枚举(更喜欢枚举而不是 const)作为键,以及 PropertyInfo - 或者不太优选的描述属性名称的字符串- 作为值。然后,您可以调用 PropertyInfo 对象上的
GetValue()
方法来从对象/类中检索值。下面是一个示例,我将枚举值映射到类中的“同名”属性,然后使用反射从类中检索值。
您可以将 const 值映射到属性名称、与这些属性相关的 PropertyInfo 对象、将检索属性值的函数......无论您认为适合您的需要。
当然,您将需要一些映射 - 在此过程中,您将根据输入值(
const
)映射到特定属性。您获取此数据的方法可能会确定最适合您的映射结构和模式。If you want your code to be more generic, I agree with the suggestion of a dictionary or some kind of lookup pattern.
You could store functions in the dictionary, but they seemly all perform the same operation - getting the value from a property. This is ripe for reflection.
I'd store all your properties in a dictionary with an enum (prefer an enum to a
const
) as the key, and a PropertyInfo - or, less preferred, a string which describes the name of the property - as the value. You then call theGetValue()
method on the PropertyInfo object to retrieve the value from the object / class.Here's an example where I'm mapping enum values to their 'same named' properties in a class, and then using reflection to retrieve the values out of a class.
You can map your
const
values to the names of the properties, PropertyInfo objects which relate to those properties, functions which will retrieve the property values... whatever you think suits your needs.Of course you will need some mapping - somewhere along the way you will be depending on your input value (the
const
) mapping to a specific property. The method by which you can get this data might determine the best mapping structure and pattern for you.我认为要走的路确实是从一个值(int)到某种知道如何提取值的函数的某种映射。
如果您确实想保持它的可扩展性,以便您可以轻松添加一些而不需要接触代码,并且可能访问更复杂的属性(即嵌套属性,进行一些基本计算),您可能希望将其保留在单独的源中。
我认为做到这一点的一种方法是依赖脚本服务,例如评估一个简单的 IronPython 表达式来提取值...
例如,在文件中您可以存储类似 : 的内容
,然后,根据请求的统计数据,您最终总是会检索一般的 GameInfos。您可以使用某种 foreach 循环:
请参阅 http://www.voidspace.org .uk/ironpython/dlr_hosting.shtml 有关如何在 .NET 应用程序中嵌入 IronPython 脚本的示例。
注意:在处理此类内容时,有几件事您必须真正小心:
I think the way to go is indeed some kind of mapping from one value (int) to something that is somehow a function that knows how to extract a value.
If you really want to keep it extensible, so that you can easily add some without touching the code, and possibly accessing more complex properties (ie. nested properties, do some basic computation), you may want to keep that in a separate source.
I think one way to do this is to rely on the Scripting Services, for instance evaluating a simple IronPython expression to extract a value...
For instance in a file you could store something like :
and then, depending on the requested stat, you always end up retrieving the general GameInfos. You can them have some kind of foreach loop with :
See http://www.voidspace.org.uk/ironpython/dlr_hosting.shtml for examples on how to embed IronPython Scripting in a .NET application.
NOTE: when working with this kind of stuff, there are several things you must really be careful about:
我没有办法解决您的开关问题,但是您当然可以通过使用可以自动映射您需要的所有字段的类来减少代码。查看 http://automapper.org/。
I don't have a solution to your switch problem off the top of my head, but you could certainly reduce the code by using a class that can automatically map all the fields you need. Check out http://automapper.org/.
我一开始就不会编写
GetMyResult
方法。它所做的就是将 GameInfo 序列转换为 MyResult 序列。使用 Linq 会更容易且更具表现力。为了
而不是调用,而是简单地调用
使其更简洁,您可以在构造函数重构中传递
UserId
和ResultValue
,,只有当您看到选择重复太多时。
I would not have written the
GetMyResult
method in the first place. All it is doing is transformingGameInfo
sequence intoMyResult
sequence. Doing it with Linq would be easier and more expressive.Instead of calling
I would simply call
To make it more succinct you can pass the
UserId
andResultValue
in constructorRefactor only if you see the selects getting duplicated too much.
这是一种不使用反射的可能方法:
This is one possible way without using reflection:
纯粹就大型 switch 语句的问题而言,值得注意的是,常用的圈复杂度度量有两种变体。 “原始”将每个 case 语句计为一个分支,因此它将复杂度度量增加 1 - 这会导致由许多开关引起的非常高的值。 “变体”将 switch 语句视为单个分支 - 这实际上将其视为一系列非分支语句,这更符合控制复杂性的“可理解性”目标。
Purely on the question of large switch statements, it is notable that there are 2 variants of the Cyclomatic Complexity metric in common use. The "original" counts each case statement as a branch and so it increments the complexity metric by 1 - which results in a very high value caused by many switches. The "variant" counts the switch statement as a single branch - this is effectively considering it as a sequence of non-branching statements, which is more in keeping with the "understandability" goal of controlling complexity.