아무것도 나타내지 않는 클래스-맞습니까?

응용 프로그램을 설계하고 있는데 SOLID와 OOP를 올바르게 이해하고 있는지 잘 모르겠습니다. 수업은 한 가지 일을하고 잘해야하지만 다른 한편으로는 우리가 다루는 실제 사물을 나타내야합니다.

필자의 경우 데이터 세트에서 기능 추출을 수행 한 다음 기계 학습 분석을 수행합니다. 세 개의 클래스를 만들 수 있다고 가정합니다.

1. 특징 추출기
2. 데이터 세트
3. 분석기

그러나 FeatureExtractor 클래스는 아무것도 나타내지 않으며 클래스보다 루틴을 더 많이 만드는 것을 수행합니다. 사용할 함수는 하나만 있습니다 : extract_features ()

한 가지를 나타내지 않지만 한 가지를하는 클래스를 작성하는 것이 맞습니까?

편집 : 중요한지는 확실하지 않지만 Python을 사용하고 있습니다.

extract_features ()가 다음과 같이 보일 경우 : 해당 메소드를 보유 할 특수 클래스를 작성하는 것이 가치가 있습니까?

def extract_features(df):
    extr = PhrasesExtractor()
    extr.build_vocabulary(df["Text"].tolist())

    sent = SentimentAnalyser()
    sent.load()

    df = add_features(df, extr.features)
    df = mark_features(df, extr.extract_features)
    df = drop_infrequent_features(df)
    df = another_processing1(df)
    df = another_processing2(df)
    df = another_processing3(df)
    df = set_sentiment(df, sent.get_sentiment)
    return df

수업은 1 가지를하고 잘해야합니다

예, 일반적으로 좋은 접근 방식입니다.

그러나 다른 한편으로는 우리가 작업하는 실제 대상을 나타내야합니다.

아닙니다. IMHO의 일반적인 오해입니다. 초보자가 OOP에 액세스하는 것은 종종 "실제 세계의 것을 나타내는 객체로 시작" 하는 것입니다.

그러나 이것으로 멈추지 않아야합니다 !

클래스는 다양한 방법으로 프로그램을 구성하는 데 사용될 수 있습니다. 실제 세계에서 객체를 모델링하는 것은 이것의 한 측면이지만 유일한 것은 아닙니다. 특정 작업에 대한 모듈이나 구성 요소를 만드는 것은 클래스의 또 다른 합리적인 사용 사례입니다. "기능 추출기"는 아마도 그러한 모듈이며, 하나의 공용 메소드 만 extract_features()포함하고 있지만 많은 개인 메소드와 공유 상태가 포함되어 있지 않으면 놀랍습니다. 따라서 수업 FeatureExtractor을 갖는 것은 이러한 개인 메소드의 자연스러운 위치를 소개합니다.

참고 사항 : 별도의 모듈 개념을 지원하는 Python과 같은 언어 FeatureExtractor에서는 이것을 위해 모듈 을 사용할 수도 있지만이 질문의 맥락에서 이것은 무시할만한 IMHO입니다.

또한, "피처 추출기"는 "피처를 추출하는 사람 또는 봇"으로 생각 될 수있다. 그것은 추상적 인 "것", 아마도 당신이 실제 세계에서 찾을 수있는 것이 아닐 수도 있지만, 이름 자체는 유용한 추상화입니다. 그래서 나는이 클래스가 "아무것도 대표하지 않는다"는 것에 동의하지 않습니다.

Doc Brown은 현장에 있습니다. 클래스는 실제 객체를 나타낼 필요가 없습니다. 그들은 단지 유용 할 필요가있다 . 수업은 근본적으로 단지 추가 종류, 어떤 수행 int또는 string해당하는 실제 세계에? 그것들은 구체적이고 구체적인 유형이 아닌 추상적 설명입니다.

즉, 귀하의 경우는 특별합니다. 설명에 따르면 :

extract_features ()가 다음과 같이 보일 경우 : 해당 메소드를 보유 할 특수 클래스를 작성하는 것이 가치가 있습니까?

당신이 절대적으로 맞습니다 : 코드가 표시된 것처럼 클래스로 만들면 아무 소용이 없습니다. 거기에 유명한 이야기 파이썬에서 클래스의 이러한 사용은 코드 냄새 있다고 주장하고 간단한 기능은 종종 충분하다. 당신의 경우는 이것의 완벽한 예입니다.

클래스의 남용은 1990 년대에 OOP가 Java의 주류가 되었기 때문입니다. 불행히도 당시 Java에는 몇 가지 최신 언어 기능 (예 : 클로저)이 없었으므로 클래스를 사용하지 않으면 많은 개념을 표현하기가 어렵거나 불가능했습니다. 예를 들어, 자바에서 최근까지 상태를 유지하는 메소드 (즉, 클로저)를 갖는 것은 불가능했습니다. 대신 상태를 전달하기 위해 클래스를 작성해야했으며 단일 메소드 ()가 노출되었습니다 invoke.

불행히도이 스타일의 프로그래밍은 이러한 대안이 필요없는 언어에서도 Java보다 훨씬 인기가 있습니다 (부분적으로 는 매우 유용한 영향력있는 소프트웨어 엔지니어링 책 으로 인해 ).

파이썬에서 클래스는 분명히 매우 중요한 도구이므로 자유롭게 사용해야합니다. 그러나 이것이 유일한 도구 는 아니며, 이해가되지 않는 곳에서 사용할 이유가 없습니다. 자유 기능이 OOP에서 자리를 차지하지 않는다는 것은 일반적인 오해입니다.

응용 프로그램을 설계하고 있는데 SOLID와 OOP를 올바르게 이해하고 있는지 잘 모르겠습니다.

20 년 동안이 일을 해왔으며 확실하지 않습니다.

수업은 1 가지를하고 잘해야합니다

여기서 잘못 가기가 어렵습니다.

그것들은 우리가 작업하는 실제 객체를 나타내야합니다.

아 진짜? 가장 인기 있고 성공적인 단일 클래스를 소개합니다 : String. 우리는 그것을 텍스트로 사용합니다. 그리고 그것이 나타내는 실제 세계 객체는 다음과 같습니다.

모든 프로그래머가 낚시에 집착하는 것은 아닙니다. 여기서는 은유라는 것을 사용합니다. 실제로 존재하지 않는 것들의 모델을 만들어도됩니다. 분명해야 할 아이디어입니다. 독자의 마음에 이미지를 만들고 있습니다. 그 이미지는 실제 일 필요는 없습니다. 쉽게 이해할 수 있습니다.

좋은 OOP 설계는 데이터 (상태) 주위에 메시지 (메소드)를 클러스터링하여 해당 메시지에 대한 반응이 해당 데이터에 따라 달라질 수 있습니다. 그렇게하는 것이 실제적인 일이라면, 스파이 그렇지 않다면, 오 잘. 독자에게 이해가되는 한 괜찮습니다.

이제 다음과 같이 생각할 수 있습니다.

그러나 은유를 사용하기 전에 이것이 현실 세계에 존재한다고 생각한다면, 프로그래밍 경력은 많은 예술과 공예를 포함 할 것입니다.

조심해! SOLID는 클래스가 "한 가지만"해야한다고 말하지 않습니다. 이 경우 클래스에는 단일 메서드 만있을 수 있으며 클래스와 함수 사이에는 실제로 차이가 없습니다.

SOLID는 수업이 하나의 책임을 나타내야한다고 말한다 . 이들은 팀 구성원의 책임과 같습니다. 운전자, 변호사, 소매치기, 그래픽 디자이너 등 각 직원은 여러 가지 (관련된) 작업을 수행 할 수 있지만 모두 단일 책임과 관련이 있습니다.

요점은 요구 사항이 변경되면 이상적으로 단일 클래스 만 수정하면된다는 것입니다. 이를 통해 코드를 이해하기 쉽고 수정하고 위험을 줄일 수 있습니다.

객체가 "실제"를 나타내야한다는 규칙은 없습니다. OO가 처음 에 시뮬레이션에 사용하기 위해 발명 되었기 때문에 이것은화물에 대한 지식 입니다. 그러나 프로그램은 시뮬레이션이 아니므로 (현대 OO 응용 프로그램은 거의 없음)이 규칙은 적용되지 않습니다. 각 학급에 명확한 책임이있는 한 괜찮습니다.

클래스가 정말 단 하나의 방법이있는 경우 와 클래스가 어떤 상태가없는, 당신은 그것을 독립적 인 기능을 고려할 수 있습니다. 이것은 문제가되지 않으며 KISS 및 YAGNI 원칙을 따릅니다. 함수로 클래스를 풀 수 있다면 수업을 만들 필요가 없습니다. 반면에 내부 상태 또는 다중 구현이 필요할 수 있다고 생각할만한 이유가 있다면이를 선불 클래스로 만들 수도 있습니다. 여기서 최선의 판단을해야합니다.

한 가지를 나타내지 않지만 한 가지를하는 클래스를 작성하는 것이 맞습니까?

일반적으로 괜찮습니다.

좀 더 구체적으로 설명하지 않으면 FeatureExtractor클래스가 정확히 무엇을해야하는지 말하기 어렵다.

어쨌든 FeatureExtractor공개 extract_features()기능 만 노출 하더라도 Strategy클래스를 사용하여 구성하는 것을 생각할 수 있으며 추출을 정확히 수행 해야하는 방법을 결정합니다.

또 다른 예는 Template 함수 가있는 클래스입니다 .

그리고 클래스 모델을 기반으로 한 더 많은 행동 디자인 패턴 이 있습니다.

설명을 위해 몇 가지 코드를 추가했습니다.

extract_features ()가 다음과 같이 보일 경우 : 해당 메소드를 보유 할 특수 클래스를 작성하는 것이 가치가 있습니까?

라인

 sent = SentimentAnalyser()

전략 으로 클래스를 구성 할 수 있음을 정확하게 구성했습니다 .

해당 SentimentAnalyser클래스에 대한 인터페이스가있는 경우 FeatureExtractor함수의 특정 구현에 직접 연결하는 대신 구성 지점에서 클래스에 인터페이스를 전달할 수 있습니다.

패턴 따로 모든 멋진 언어 / 개념 : 당신이 우연히 발견 한 것은입니다 작업 또는 일괄 처리 .

하루가 끝나면 순수한 OOP 프로그램조차도 실제로 작업을 수행하기 위해 무언가에 의해 구동되어야합니다. 어떻게 든 진입 점이 있어야합니다. 예를 들어 MVC 패턴에서 "C"ontroller는 GUI에서 click etc. 이벤트를 수신 한 후 다른 구성 요소를 오케스트레이션합니다. 고전적인 명령 행 도구에서 "기본"기능은 동일합니다.

한 가지를 나타내지 않지만 한 가지를하는 클래스를 작성하는 것이 맞습니까?

당신의 클래스 는 무언가를하고 다른 모든 것을 오케스트레이션 하는 엔티티를 나타냅니다 . 이름을 Controller , Job , Main 또는 무엇이든 생각할 수 있습니다 .

extract_features ()가 다음과 같이 보일 경우 : 해당 메소드를 보유 할 특수 클래스를 작성하는 것이 가치가 있습니까?

상황에 따라 다릅니다 (그리고 파이썬에서 수행되는 일반적인 방법에 익숙하지 않습니다). 이것이 작은 원샷 커맨드 라인 툴이라면 클래스 대신 메소드가 좋습니다. 프로그램의 첫 번째 버전은 확실히 방법으로 벗어날 수 있습니다. 나중에 수십 가지의 메소드, 전역 변수가 혼합 된 경우에도 클래스로 리팩토링 할 때입니다.

OOP 는 시스템의 동작을 모델링 하는 것으로 생각할 수 있습니다 . 실제 은유가 때때로 유용 할 수 있지만 (예 : "파이프 라인", "공장"등) 시스템 은 '실제 세계'에 존재할 필요 는 없습니다 .

우리가 원하는 시스템이 한 번에 모델링하기에 너무 복잡한 경우, 작은 조각으로 나눠서 "문제 도메인"을 모델링 할 수 있습니다. 이러한 문제는 더 이상 분해 될 수 있으며 행동이 일치하는 조각에 도달 할 때까지 계속됩니다 숫자, 문자열, 목록 등과 같은 내장 언어 객체의 객체입니다.

일단 우리가 그 간단한 조각들을 가지고 나면, 더 큰 조각들의 행동을 설명하기 위해 그것들을 함께 결합 할 수 있습니다. 우리는 더 큰 조각들로 결합 할 수 있습니다. 체계.

우리가 몇몇 클래스를 작성할 수있는 것은이 "결합"단계입니다. 원하는 방식으로 작동하는 기존 객체가 없을 때 클래스를 작성합니다. 예를 들어, 도메인에는 "foos", "bars"라는 foo 모음 및 "bazs"라는 모음 모음이 포함될 수 있습니다. 우리는 foo가 문자열로 모델링하기에 충분히 간단하다는 것을 알 수 있습니다. 우리는 막대가 내용이 파이썬이 제공하는 것과 일치하지 않는 특정 제약 조건을 준수해야한다는 것을 알았습니다.이 경우이 제약 조건을 적용하기 위해 새 클래스를 작성할 수 있습니다. 아마도 baz는 그러한 특성이 없으므로 목록으로 나타낼 수 있습니다.

우리가주의 할 수 이러한 구성 요소 (FOOS, 바, bazs)의 모든 사람을위한 새로운 클래스를 작성,하지만 우리는하지 않습니다 필요가 이미 올바른 동작 뭔가있을 경우에. 특히, 클래스에 대해 뭔가를 '제공'할 필요가 유용하다는 것을 우리는 사용자 정의 클래스의 많은 레이어가 그렇게해도 (데이터, 방법, 상수, 서브 클래스 등) 해야한다 결국 사용을 일부 내장 기능; 예를 들어, foos에 대한 새로운 클래스를 작성했다면 아마도 문자열 만 포함하고있을 것입니다. foo 클래스를 잊어 버리고 bar 클래스에 대신 해당 문자열을 포함 시키십시오. 클래스는 내장 객체이며 특히 융통성이 있습니다.

일단 우리가 도메인 모델을 가지고 나면, 우리는 그 조각들의 특정 인스턴스 를 가져 와서 우리가 모델링하고자하는 특정 시스템의 "시뮬레이션"으로 배열 할 수 있습니다 (예 : "기계 학습 시스템 ...").

일단 우리가이 시뮬레이션을 가지고 나면, 우리는 그것을 실행할 수 있고, 그리고 presto, 우리는 ... (또는 우리가 모델링하고있는 다른 것)을위한 작동하는 머신 러닝 시스템을 갖게됩니다.

이제 특정 상황에서 "피처 추출기"구성 요소의 동작을 모델링하려고합니다. 문제는 "기능 추출기"처럼 동작하는 내장 객체가 있습니까, 아니면 더 간단한 것으로 분리해야합니까? 피처 추출기는 함수 객체와 매우 유사하게 작동하므로 모델로 사용하는 것이 좋습니다.

이러한 종류의 개념에 대해 배울 때 명심해야 할 것은 언어마다 다른 내장 기능과 객체를 제공 할 수 있다는 것입니다 (물론 "개체"와 같은 용어도 사용하지 않습니다!) 따라서 한 언어에서 의미가있는 솔루션은 다른 언어에서는 그다지 유용하지 않을 수 있습니다 (이는 같은 언어의 다른 버전에도 적용될 수 있습니다!).

역사적으로, 많은 OOP 문헌 (특히 "디자인 패턴")은 파이썬과는 다른 Java에 중점을두고 있습니다. 예를 들어 Java 클래스는 객체가 아니며 Java는 최근까지 함수 객체가 없었습니다 .Java는 엄격한 유형 검사 (인터페이스 및 하위 클래스를 장려합니다)하면서 Python은 오리 타이핑을 장려하고 Java에는 모듈 객체가 없습니다 .Java 정수 / 수레 / 등. 객체가 아니고 Java의 메타 프로그래밍 / 내부 검사에는 "반사"가 필요합니다.

나는 Java를 선택하려고하지 않고 (또 다른 예로서, 많은 OOP 이론이 Smalltalk에 관한 것인데, 파이썬과는 매우 다릅니다) 문맥에 대해 매우 신중하게 생각해야한다는 것을 지적하려고합니다. 솔루션이 개발 된 제약 조건과 현재 상황과 일치하는지 여부

귀하의 경우 함수 객체는 좋은 선택처럼 보입니다. 왜 "모범 사례"가이드 라인이 함수 객체를 가능한 해결책으로 언급하지 않는지 궁금하다면, 그 가이드 라인이 이전 버전의 Java 용으로 작성 되었기 때문일 수 있습니다!

실용적으로 말하면, "중요한 일을하고 별도의 일을해야하는 기타 일"이 있고, 분명한 집이 없을 때, 나는 그것을 Utilities섹션에 넣고 그것을 내 이름 규약으로 사용합니다. 즉. FeatureExtractionUtility.

클래스의 메소드 수는 잊어 버리십시오. 오늘날 단일 방법은 내일 5 가지 방법으로 성장해야 할 수도 있습니다. 중요한 것은 기타 기능 수집을위한 유틸리티 영역과 같이 명확하고 일관된 조직 구조입니다.