Question

我有一个简短的问题。

通过返回的func初始化值是否更像pythonic：

class Game:

    def __init__(self, AMOUNT_OF_PLAYERS = 2, AMOUNT_OF_CARDS = 7):
        self.draw_stack = create_draw_stack()
        self.play_stack = [self.draw_stack.pop()]

def create_draw_stack():
    VALUES = list(range(1, 10))
    COLORS = ["Red", "Blue", "Yellow", "Green"]
    return [Card(value, color) for value in VALUES for color in COLORS]

还是应该看起来像这样：

class Game:

    def __init__(self, AMOUNT_OF_PLAYERS = 2, AMOUNT_OF_CARDS = 7):
        self.draw_stack = []
        self.play_stack = []
        self.create_draw_stack()
        self.create_play_stack()

    def create_draw_stack(self):
        VALUES = list(range(1, 10))
        COLORS = ["Red", "Blue", "Yellow", "Green"]
        cards = [Card(value, color) for value in VALUES for color in COLORS]
        self.draw_stack = cards

    def create_play_stack(self):
        self.play_stack = [self.draw_stack.pop()]

在此特定问题上我找不到任何东西。是否有经验法则可以直观地找出类似的问题？

谢谢。

Answer 1

这不是关于“ pythonic”的问题，而是关于构图的问题（请注意，这是带有重观点的）。

关于您的代码。方法2有什么好处：与Game相关的所有代码都“封装”到单个类中（至少，它位于同一位置）。这样一来，将来就可以轻松管理-轻松查找所有创建/更改Game的内容。

方法1有什么好处：您拥有更多的“纯”功能，可以在以后重新使用，并且单独进行测试要容易一些。从理论上讲，可重用性是一件好事，但过分考虑并进行过早的优化则不是一个好主意，尤其是对于可读性的价格而言。

您可以将两者结合起来做一件事：保持“无状态”卡片组的创建而不是改变对象状态，并在__init__中进行调用，但是将您的create_draw_stack纳入类（即使其成为类） @staticmethod）表示堆栈已在类范围内的某处使用，并且[到目前为止]这是Game逻辑的一部分。

Answer 2

使用Pythonic解决方案说明Slam的答案：

class Game:

    VALUES = list(range(1, 10))
    COLORS = ["Red", "Blue", "Yellow", "Green"]

    @classmethod
    def create_draw_stack(cls):
        return  [Card(value, color) for value in cls.VALUES for color in cls.COLORS]       

    def __init__(self, players_count=2, cards_count=7):
        self.draw_stack = self.create_draw_stack()
        self.play_stack = [self.draw_stack.pop()]

您还问过：

是否有经验法则可以直观地找出类似的问题？

“直觉”部分主要是经验问题（“经验”与“花时间做某事”不同-它还意味着阅读，实验，思考等）。

wrt /“经验法则”：

高凝聚力：一个“单元”（无论是模块，类，方法还是函数）应该只涉及一件事，而只能涉及一件事（有时，“一件事”可能相当广泛，但无论如何）
位置：应该一起使用的东西应该放在一起（这样一来，您不必在编辑器中打开十几个文件即可了解整个作品的工作原理）
低耦合：一个“单位”应直接依赖于尽可能少的其他单位
可读性：代码应尽可能清晰易读（好，这里有一些主观部分）
可测试性：该代码应易于隔离测试（参见“低耦合”）
简单性：根据问题的复杂程度，代码应尽可能简单。
可用性：您的“单元” API应当设计成尽可能易于用于客户端代码

还有什么pythonic？更改就地或返回值

2 个答案: