1. 技术文章
  2. What's the best way to resolve a combinatorial explosion of interactions?

What's the best way to resolve a combinatorial explosion of interactions?

由 守給你的承諾、 提交于 2019-12-03 06:14:32

An interesting potential option would be to use a variant of the Visitor Pattern.

Judith Bishop and R. Nigel Horspool wrote a paper about design pattern efficiency in which they explained various variants on the classic visitor pattern using C# 3 features.

In particular, I would take a look at how they work with delegates to handle the visitor pattern. Using a list or stack of delegates could potentally give you an interesting way to handle multiple effects from multiple objects, and be much easier to extend either side of the class hierarchy (add ships or add effects) without huge breaking code changes.

Not quite an answer, but to me this fairly screams "properties pattern". There's a well-known yegge rant about this, I think it'll offer you some decent pointers.

http://steve-yegge.blogspot.com/2008/10/universal-design-pattern.html

This looks like the classical OOP polymorphism/visitor dilemma. However, your requirements make it easier.

Basically, I would create a base class Ship that all concrete Ships derive from. This class would have methods:

class Ship
{
  void encounterBlackHole() {}
  void encounterNebula() {}
  ... etc. ...
};

with empty default bodies. When you add a new Phenomenon, you just add new method with empty body. (The methods may have arguments, like coordinates or weight of the black hole etc.)

For the Effects and their interaction - I think you should add more information about how you want it, eg. are the interactions rare or usual, are they cumulative in some sort, are they confined to a limited set of variables they control ...

Sounds like a classic multiple dispatch problem to me.

Interesting question

In a way or an other, A ship will have to know what phenomena can affect it and a phenomena which effects it has on which ship.

This could be stored in an xml file parsed at run-time.

Maybe you could use the Decorator pattern to calculate the effects. You generate various phenomenas at run-time.

Suppose your ships implement an Interface IShip and everywhere in your code, you use IShips.

Now, suppose all your phenomena also implement the Interface IShip (required by the decorator design pattern).

IShip myShip = myShip.AddPhenomena(PhenomenaGeneratedByAFactoryForThisShip);

In the phenomena, you wrap the methods from the original ship, so you can perform modification to properties and all.

Also, if you use the strategy pattern you can generate any kind of phenomena you'd like.

Removing a phenomena, can be used by walking the pile of decorated ships you have, and rewrapping it, so I see no problem there.

As for the synergies, I think I would use a slightly modified phenomena, which works only if the target ship has all the phenomenas on itself.

either every Ship will have to know how to handle every Phenomenon, or every Phenomenon will have to know about every Ship.

I think this is the key to your problem and it's true if every ship-phenomena interaction is unique. In the table you created, that appears to be the case, so for n ships and m phenomena, you need to specify n*m interaction. You are right to smell a maintenance issue.

The only way out is to make ship-phenomena interactions not as unique by making the effect of phenomena depend on the properties of the ship. For example, we could say only ships built with strange-alumina will survive a black hole.

But having only one property doesn't buy you anything, you could've just as easily specified which ships are affected by black holes. The key is that multiple properties exhibit the same combinatorial explosion.

So ships built with strange-alumina will survive black holes, and ships built without can go faster. 1 Property allows you to specify 2 things (1 bit = 2 possibilities). Ships built with corbite engines will go faster in a warp zone. Ships with both corbite engines and strange-alumina will gain 50% shield in a nebula field, etc.

The addition of properties to ships allows you to avoid specifying how every phenomena interacts with every ship, and yet still have every phenomena and every ship exhibit an appropriate behavior.

If there are M ships, then you only need log2(M) properties to give every ship a unique behavior.

I think the answer of a problem is depend on how good the question ask.

I think the way to design is depend on what the question is(or the question will goes in the future)

you give a table, then I think the solution is maintain a table and query it.

python code here:(not tested and just shows for a example)

class Ship():
     def __init__(self,type):
         self.type=type
     def encounterPhenomena(self,type): # let Phenomena to process ship
         p = Phenomena(type)
         p.process(self)

class Phenomena():
     processTable = {}
     def __init__(self,type):
         self.type=type
     def process(self,ship):
         try:
             self.processTable[self.type](ship.type) #query the internal table to process ship
         except:
             pass #if Phenomena don't know this ship type then no process..
     def addType(type,processMethod):
         processTable[type]=processMethod #add new Phenomena, and add processMethod

def run():
    A = Ship(type = 'RedShip')
    A.encounterPhenomena(type='GravityWell');

If process method changed, simply modify the process method in the Phenomena class.

If you think ship need to know how to process Phenomena, then change process method into the ship class.

or you think there are other things not only Phenomena need to change status of ship(like other ships, shoal rock), you need to maintain a process table in ship class and make Phenomena one of it,

speak again, how to design is depend on the question its self.

标签
c#
design-patterns
software-design
易学教程内所有资源均来自网络或用户发布的内容，如有违反法律规定的内容欢迎反馈！
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!