나는 pylint다른 정적 분석 도구가 모든 것을 알지 못한다는 것을 알고 있으며 때로는 그들의 조언에 불복종해야합니다. (이것은 conventions 뿐만 아니라 다양한 메시지 클래스에 적용됩니다 .)

내가 같은 수업이 있다면

class related_methods():

    def a_method(self):
        self.stack.function(self.my_var)

class more_methods():

    def b_method(self):
        self.otherfunc()

class implement_methods(related_methods, more_methods):

    def __init__(self):
        self.stack  = some()
        self.my_var = other()

    def otherfunc(self):
        self.a_method()

분명히, 그것은 고안되었습니다. 원하는 경우 더 좋은 예가 있습니다 .

이 스타일은 "mixins"를 사용한다고합니다.

다른 도구와 마찬가지로, pylint요금이 코드는 -21.67 / 10주로는 생각 때문에 more_methods그리고 related_methods이없는 self나 속성 otherfunc, stack,하는 Nd my_var코드를 실행하지 않고, 그것은 분명히 볼 수 없기 때문에 related_methods와 more_methods혼합에에 있습니다 implement_methods.

컴파일러와 정적 분석 도구가 항상 Halting Problem을 해결할 수 는 없지만 상속 된 implement_methods것을 보면 이것이 완전히 유효하다는 것을 알 수 있습니다. 매우 쉬운 일이라고 생각합니다.

정적 분석 도구가이 유효한 OOP 패턴을 거부하는 이유는 무엇입니까?

어느 한 쪽:

1. 그들은 심지어 상속을 확인 하려고 시도 하지 않거나

2. 믹스 인은 관용적이고 읽기 쉬운 파이썬에서는 사용하지 않는 것이 좋습니다

# 1 (에만 정의 된 것을 사용 pylint하는)을 상속받는 내 클래스에 대해 말하면 불평 하지 않기 때문에 분명히 잘못되었습니다 .unittest.TestCaseself.assertEqualunittest.TestCase

믹스 인은 비 피톤 적이거나 낙담합니까?

믹스 인은 도구에서 고려한 사용 사례가 아닙니다. 그것은 반드시 나쁜 유스 케이스라는 것을 의미하지는 않지만 파이썬에서는 드문 경우입니다.

믹스 인이 특정 상황에서 적절하게 사용되는지 여부는 또 다른 문제입니다. 내가 가장 자주 본 믹스 인 안티 패턴은 오직 하나의 조합 만 혼합하려는 경우 믹스 인을 사용합니다. 그것은 신 클래스를 숨기는 원형 길입니다. 믹스 인 중 하나를 교체하거나 제거 해야하는 이유를 지금 생각할 수 없다면 믹스 인이되어서는 안됩니다.

나는 Mixins가 절대적으로 Pythonic 일 수 있다고 생각합니다. 그러나, 린터를 침묵시키고 믹스 인의 가독성을 향상시키는 관용적 방법은 (1) 믹스 인의 자녀가 구현해야하는 방법 을 명시 적으로 정의하는 추상적 인 방법 을 정의하고 (2) 사전 정의하는 것입니다. None하위를 초기화해야하는 Mixin 데이터 멤버에 대한 값 필드

이 패턴을 예제에 적용 :

from abc import ABC, abstractmethod


class related_methods():
    my_var = None
    stack = None

    def a_method(self):
        self.stack.function(self.my_var)


class more_methods(ABC):
    @abstractmethod
    def otherfunc(self):
        pass

    def b_method(self):
        self.otherfunc()


class implement_methods(related_methods, more_methods):
    def __init__(self):
        self.stack  = some()
        self.my_var = other()

    def otherfunc(self):
        self.a_method()

나는 믹스 인이 좋을 것이라고 생각하지만,이 경우에는 pylint가 옳다고 생각합니다. 면책 조항 : 의견 기반의 내용은 다음과 같습니다.

믹스 인을 포함한 좋은 수업은 분명한 책임이 있습니다. 이상적으로, 믹스 인은 액세스하려는 모든 상태와이를 처리 할 논리를 전달해야합니다. 예를 들어 좋은 믹스 인은 last_updatedORM 모델 클래스에 필드를 추가하고 ,이를 설정하기위한 논리를 제공하며, 가장 오래된 / 최신 레코드를 검색하는 방법을 제공 할 수 있습니다 .

선언되지 않은 인스턴스 멤버 (변수 및 메소드)를 참조하면 약간 이상하게 보입니다.

올바른 접근 방식은 현재 진행중인 작업에 따라 다릅니다.

관련 상태 비트와 혼합되어있을 수 있습니다.

현재 믹스 인을 통해 배포하는 메서드가 기본 클래스에있는 반면 다른 수준의 구현 차이는 하위 클래스에 속하는 다른 클래스 계층 구조 일 수 있습니다. 이것은 스택 작업과 함께 귀하의 경우에 가장 적합합니다.

메소드를 추가하는 클래스 데코레이터 일 수 있습니다. 메소드 생성에 영향을 미치기 위해 데코레이터에 인수를 전달해야 할 때 일반적으로 의미가 있습니다.

문제를 설명하고 더 큰 디자인 문제를 설명하면 어떤 경우에 반 패턴이 있는지 논쟁 할 수 있습니다.

린 터는 클래스를 믹스 인으로 사용한다는 것을 인식하지 못합니다. Pylint는 클래스 이름 끝에 접미사 'mixin'또는 'Mixin'을 추가하면 믹스 인이 사용된다는 것을 알고 있습니다.

믹스 인 자체는 나쁘지 않거나 좋지 않으며 단지 도구 일뿐입니다. 당신은 그들을 잘 사용하거나 나쁜 사용으로 만듭니다.

믹스 인은 괜찮습니까?

파이썬 믹스 인은 안티 패턴입니까?

믹스 인은 사용하지 않는 것이 좋습니다. 다중 상속의 좋은 유스 케이스입니다.

당신의 린터가 왜 불평합니까?

Pylint은 어디를 모르기 때문에 분명히 불평 otherfunc, stack그리고 my_var 에서오고있다.

하찮은?

이 두 가지 방법을 문제의 예 또는 여기에 표시된 더 간단한 링크 된 예에서 별도의 부모 클래스로 분리해야 할 정당한 이유는 없습니다.

201
202 class OpCore():
203     # nothing runs without these
204
205 class OpLogik(): 
206     # logic methods... 
207 
208 class OpString(): 
209     # string things
210 
211 
212 class Stack(OpCore, OpLogik, OpString): 
213 
214     "the mixin mixer of the above mixins" 

믹스 인 및 소음 비용

당신이하는 일의 비용은 린터 보고서 노이즈를 만드는 것입니다. 이 노이즈는 코드에서 더 중요한 문제를 모호하게 할 수 있습니다. 이것은 무게를 측정하는 중요한 비용입니다. 또 다른 비용은 상호 관련 코드를 다른 네임 스페이스로 분리하여 프로그래머가 의미를 찾기 어렵게 만들 수 있다는 것입니다.

결론

상속은 코드 재사용을 허용합니다. 믹스 인으로 코드를 재사용하면 다른 비용보다 큰 가치를 창출 할 수 있습니다. 코드 라인의 코드 재사용 / 중복 제거를 얻지 못하면 믹스 인에 대해 많은 가치를 얻지 못할 수 있으며 그 시점에서 노이즈 비용이 이점보다 더 크다고 생각합니다.