Function 只使用一个函数处理多个逻辑（N个客户端）。都调用同一个函数，怎么办？_Function

Function 只使用一个函数处理多个逻辑（N个客户端）。都调用同一个函数，怎么办？

function

Function 只使用一个函数处理多个逻辑（N个客户端）。都调用同一个函数，怎么办？,function,Function,我有一个用python/Django编写的公司应用程序（回答这个问题不需要python经验）。基本上是SAAS。似乎很少有客户对一些模块有不同的要求。假设有一个URL www.xyz.com/groups 它被所有客户端使用，但少数客户端希望在调用同一URL时有不同的输出。我想知道在不为每个客户机编写新函数或在单个函数中编写条件的情况下如何做到这一点。我知道这是一个愚蠢的问题，但我知道一定有解决方案。如果你的代码需要对案例“a”执行“a”，对案例“B”执行“B”，对案例“C”执行“C”，

我有一个用python/Django编写的公司应用程序（回答这个问题不需要python经验）。基本上是SAAS。似乎很少有客户对一些模块有不同的要求。假设有一个URL www.xyz.com/groups 它被所有客户端使用，但少数客户端希望在调用同一URL时有不同的输出。我想知道在不为每个客户机编写新函数或在单个函数中编写条件的情况下如何做到这一点。

我知道这是一个愚蠢的问题，但我知道一定有解决方案。

如果你的代码需要对案例“a”执行“a”，对案例“B”执行“B”，对案例“C”执行“C”，那么不管你选择什么解决方案，代码中的某个地方必须存在某种东西，决定案例“a/B/C”何时出现，在这种情况下，必须存在能够发送正确的“A/B/C”操作的东西，当然这些A/B/C操作也必须写在代码中的某个地方

跳出代码，思考一下。如果它被指定并且必须发生-它必须被编码在某个地方。你无法逃避。现在，如果案例/操作是琐碎和典型的，那么您可能会发现一些更多甚至更多的可配置库，它意外地允许您配置此类案例和操作，并且您可以使用它“无代码”和“无杂乱”。但从形式上看，代码在库中很深。因此，决策者、调度员和操作都被编码。只是不是你，不是那些猜到你需要什么的人

但是，如果您的需求非常重要且非常具体，例如，如果它需要您的各种条件来决定哪种情况是a/b/c，那么您很可能必须自己编写“决策者”部分。这意味着大量的IFs树、嵌套开关、规则n循环，或者任何你喜欢或觉得合适的东西。在此之后，您将进入dispatch/execute阶段，这可以通过多种方式实现——即策略模式——正是它：dispatch（通过与案例相关的具体类）和execute（具体策略具有案例的具体代码）

让我们尝试类似OO的方法：

例如，如果用户类型U1、U2、U3有案例a/b/c，则可以引入三个类：

UserType1 inherits from abstract UserType or implements "DoAThing" interface
UserType2 inherits from abstract UserType or implements "DoAThing" interface
UserType3 inherits from abstract UserType or implements "DoAThing" interface

UserType1 implements virtual method 'doTheThing' that executes actionA
UserType2 implements virtual method 'doTheThing' that executes actionB
UserType3 implements virtual method 'doTheThing' that executes actionC

your Users stop keeping "UserType" of type "int" equal to '1/2/3' - now their type is an object: UserType1, UserType2 or UserType3

每当您必须为给定用户执行操作时，您现在只需：

result = user.getType().doTheThing( ..params..)

所以，不要使用iffing/switch，而是使用OO:

tell，not ask

规则。如果要执行的操作完全依赖于UserType，那么让UserType执行它。生成的代码尽可能短，但代价是要创建的类的数量，以及

。。。决策者、调度员和操作仍在代码中。在不同的用户类型类别中，操作是显而易见的。通过公共抽象基方法分派-明显-虚拟调用。还有决策者。。？嗯：在某个时刻，必须为用户选择并构造正确的UserType对象。如果用户存储在数据库中，如果“usertype”只是一个整数1/2/3，那么在ORM层的某个地方，这些1/2/3数字必须被解码并转换为UserType1/2/3类/对象。这意味着，你需要有一个ifs树或者一个开关等等。或者，如果你有一个足够聪明的ORM，你只需要设置一堆规则，它就可以为你做，但这只是再次将工作的一部分委托给更多甚至更多的可配置库。没有提到您的UserType1/2/3类实际上变得有些。。战略
好的，让我们攻击“选择”部分
你可以在某个地方建立一个ifs或开关树来决定和分配，但命令似乎有味道。或者，使用OO，您可以尝试对某个对象进行多态化，以便“它只会做正确的事情”，但它不会解决任何问题，因为您必须再次选择某个对象类型。所以，让我们试试数据驱动：让我们使用查找

we've got five implementations of an action create a hash/dictionary/map add usertype1->caseA to the map add usertype2->caseC to the map add usertype3->caseB to the map add usertype4->caseA to the map add usertype5->caseE to the map ....
现在，无论何时你有一个用户需要决定，只要查一下就可以了。您可以持有一个策略的随时可用对象，而不是“案例”。或者一个可调用的方法。或者一个打字名。或者你需要的任何东西。关键是，与其写作

if( user.type == 1) { ... } else if( user.type == 2) ...
或切换，您只需查找：

thing = map[ user.type ] if ( thing is null ) ???
但是，请注意，如果不小心，您有时可能在地图上找不到匹配项。而且，必须为所有情况预定义映射。因此，简单的
如果X<100
可能会在地图中变成100个条目0..99
当然，您可以使用一些规则引擎，而不是映射，您可以定义一个映射，如

X<100 -> caseA X>=100 -> caseB

X案例a 十> =100->caseB
然后针对您的用户类型“运行”规则，并获得一个“结果”，告诉您“caseA”
等等
每个部分——决策、分派、执行——您可以以不同的方式实现，更短或更长，更多或更少的可扩展性，更多或更少的可配置性，如OO/命令式/数据驱动/功能性/等等——但您不能逃避它们：

您必须定义案例的判别式

您必须定义操作的实现

您必须定义案例到操作的映射

如何做到这一点，取决于你的审美观、语言特征、框架、库和。。您想花在创建和维护上的时间。
策略模式，根据ClientID？thx动态选择策略，以获得最佳解决方案。这个模式涉及很多抽象，当我实现这个抽象时，我将为每个客户机编写一个派生函数。是否有任何方法可以编写一个包含从调用函数或全局常量文件处理的常量的函数？Thx再次提醒，我不理解问题中的“从调用函数处理的常量”部分。假设我有一个函数get_all_groups（）。用户A使用此函数获取所有组并列出它们，用户B使用此函数获取所有组以及相关组的详细信息。现在有两种不同的需求