실제로 객체 지향 프로그래밍을 언제 사용합니까? [닫은]

기본적으로 문자열을 조작하는 Python으로 프로그램을 작성 중이며 OOP 원칙을 사용하여 수행해야하는지 궁금합니다. 그는 코드에 대해 상관하지 않는다 말하지 않았다 클라이언트는, 그는 단지 것은이 원하는 일 .

객체 지향 코드는 정의에 의한 것이 아니며 반대로 비 OO 코드는 정의에 의한 엉터리가 아닙니다. 내가 묻는 질문은 다소 의견을 기반으로 할 수 있지만 알지 못하는 규칙이있을 수 있습니다.

수행 할 작업에 대한 추가 정보 :

• .csv파일을 구문 분석하고 구성 파일을 기반으로 데이터를 처리하십시오 (열의 수 또는 보유하는 데이터와 같이 열이 다를 수 있음)
• 위의 처리 된 데이터를 사용하여 새로운 사용자 정의 형식의 데이터 (또는 위의 값 중 일부를 기반으로하는 여러 파일)를 작성하십시오.
• 마지막 형식의 데이터를 사용하여 XML 파일을 만듭니다.
• 복수의 XML 파일을 분할하는 XML내용에 따라 s의
• 응용 프로그램은 CLI 기반이어야합니다
• 물론 일부 이벤트 로깅, CLI 인수 구문 분석 등과 같은 다른 것들도 있습니다.

이제 이것은 전혀 크거나 어려운 응용 프로그램이 아니며 거의 완료되었지만 전체 개발 프로세스 중에 OOP를 사용하여 수행 해야하는지 여부를 계속 묻습니다.

그래서 내 질문은 : 응용 프로그램에서 OOP 를 언제 사용할지 알고 결정 하는 방법은 무엇입니까?

파이썬은 다중 패러다임 언어이므로 작업에 가장 적합한 패러다임을 선택할 수 있습니다. Java와 같은 일부 언어는 단일 패러다임 OO이므로 다른 패러다임을 사용하려고하면 두통이 발생합니다. "항상 OO를 사용한다"는 포스터는 아마도 그런 언어의 배경에서 나올 것입니다. 그러나 다행히도 선택의 여지가 있습니다!

귀하의 프로그램은 일부 입력 (csv 및 구성 파일)을 읽고 일부 출력 (xml 파일)을 생성하지만 대화식이 아니므로 상태 저장 GUI 또는 API가없는 CLI 응용 프로그램입니다. 이러한 프로그램은 자연스럽게 입력에서 출력까지의 기능으로 표현되며 하위 작업의 다른 기능을 위임합니다.

반면 OO는 변경 가능한 상태를 캡슐화하는 것과 관련이 있으므로 대화 형 응용 프로그램, GUI 및 API의 변경 가능한 상태를 표시하는 데 더 적합합니다. OO가 첫 번째 GUI와 병행하여 개발 된 것은 우연이 아닙니다.

OO는 다형성으로 인해보다 느슨하게 결합 된 아키텍처를 허용하므로 동일한 인터페이스의 다른 구현을 쉽게 대체 할 수 있다는 또 다른 이점이 있습니다. 의존성 주입과 결합하면 의존성 및 기타 멋진 것들을 구성 기반으로로드 할 수 있습니다. 이것은 대부분 매우 큰 응용 프로그램에 적합합니다. 설명하는 크기의 프로그램의 경우 별다른 이점이없이 많은 오버 헤드가 발생합니다.

실제로 파일을 읽고 쓰는 함수 외에도 대부분의 논리는 부작용이없는 함수로 작성되어 일부 입력을 받고 다른 출력을 반환합니다. 종속성을 테스트해야하는 OO 단위를 테스트하는 것보다 훨씬 간단하게 테스트하기가 쉽습니다.

결론 : 많은 기능이 조직을 위해 모듈로 나뉘 지 만 객체는 제안하지 않는 것이 좋습니다.

GUI의 버튼을 고려하십시오. 상태 (크기, 색상, 위치, 레이블 등)가 있습니다. 상황이 발생할 수 있습니다 (클릭, 다시 그리기 등이 필요함). 이러한 상황에서는 객체로 모델링하는 것이 좋습니다. 객체는 객체의 상태, 객체에 대해 수행 할 수있는 일련의 동작 (메서드)을 포함 할 수 있으며, 이벤트를 발생시켜 애플리케이션의 다른 부분에 이벤트가 발생했음을 알릴 수 있습니다.

OOP는 GUI 및 시스템의 일부가 일시적인 상태를 처리하는 기타 상황을 처리하기위한 최상의 도구입니다.

소스에서 데이터를 읽고 처리하고 대상에 기록하는 다른 상황 (예 : 선언적 (또는 함수) 프로그래밍)이 다른 상황에서 잘 처리됩니다. 데이터 처리를위한 선언적 코드는 OOP 솔루션보다 읽기 쉽고 짧습니다.

망치와 톱이 올바르게 사용될 때 강력한 도구 인 것처럼 객체 지향적이고 선언적인 프로그래밍 기술도 마찬가지입니다. 톱의 손잡이로 못을 나무 조각에 박을 수 있습니다. 마찬가지로 망치로 나무 조각을 반으로 깰 수 있습니다. 마찬가지로 기능만으로 GUI를 생성하고 객체로 데이터를 처리 할 수 ​​있습니다. 그래도 도구를 올바르게 사용하면 결과가 더 깨끗하고 간단 해집니다.

내가 사용하는 일반적인 경험 법칙은 상태가 많거나 사용자 상호 작용이 필요한 경우 객체를 사용한다는 것입니다. 그렇지 않으면 (가능한 경우 순수하고 높은 순서로) 기능을 사용합니다.

객체 지향 프로그래밍 은 무기고에 네 가지 새로운 도구 를 추가합니다 .

1. 캡슐화
2. 추출
3. 계승
4. 다형성

이러한 도구를 활용할 수있을만큼 충분히 크고 복잡하게 커지면 응용 프로그램에서 OOP를 사용합니다.

이 질문은 조금 혼란스러워 보입니다. 파이썬으로 작성한다면 객체 를 사용할 것 입니다. 파일을 열면 객체가 반환됩니다. 결과를 얻으면 반복자 객체를 반환합니다. 생성하는 각 함수는 객체입니다. 파이썬 응용 프로그램에서 OO의 가치에 의문을 제기하는 것은 가장 이상하게 들립니다.

여기의 의견을 바탕으로 Python은 기능적 패러다임을 지원하지만 주로 객체 기반입니다. 언어 자체와 내장 라이브러리는 객체를 중심으로합니다. 예. Java 및 OO로 일반적으로 설명되는 다른 언어와 마찬가지로 람다를 지원하지만 실제 기능 언어와 비교하여 의도적으로 단순합니다.

아마도 OO 디자인과 기능적 디자인에 대한 이러한 차이점은 더 이상 사용되지 않습니다. OO로 설계된 Object *에서 다형성 함수를 만들고 기능적으로 스타일이 지정된 함수에 대한 매개 변수로 객체의 해당 함수에 대한 포인터를 전달하면 OO입니까, 아니면 기능입니까? 나는 그것이 문제를 해결하는 데 효과적인 방법이라고 생각합니다.

실제 질문은 '자신의 클래스 디자인을 시작해야 할 때와 함수가있는 모듈을 만들어야하는 경우'입니다. 그에 대한 정답은 솔루션 단순화를 도울 때입니다. 객체 지향 언어에 대해 동일한 기본 답변을 제공합니다.

* 중복성은 의도적입니다 : 여기서 객체가 OO이거나 기능이 작동한다고 가정하고 비난하고 싶지 않습니다.

객체 지향 프로그래밍의 가장 큰 장점 중 하나는 프로그램 흐름에 대한 추론 대신 상태에 대한 추론을 시작한다는 것입니다.

여러 번 객체를보고 메소드를 보았지만 코드 뒤에있는 생각은 상태가 아니라 흐름이라는 것입니다.

상태를 추론하면 코드가 너무 복잡해지면 더 이상 상태를 추론 할 수없고 리팩터링해야한다는 사실을 알기 때문에 좋은 OOP 코드를 쉽게 작성할 수 있습니다.

예를 들어보십시오. csv 파일을 구문 분석하려고합니다. 디스크의 파일 : 어디에서 왔습니까? 그것을로드하고 메모리에 넣고 구문 분석합니다. 이제 귀하의 클라이언트가옵니다. 웹에서 파일을 구문 분석하고 싶습니다. 따라서 파일을로드하기위한 멋진 인터페이스를 만들고 웹에서 파일을 가져 오는 코드 만 작성하면 나머지 프로그램은 정확히 동일하게 유지되므로 행복합니다.

그리고 좋은 점은 테스트 할 수 있다는 것입니다.

평신도의 관점에서 :

• 원하는 모든 종류의 프로젝트에서 OOP 또는 비 OOP를 사용할 수 있습니다.
• OOP는 만병 통치약은 아니지만 복잡성을 관리하는 데 도움이됩니다.
• 모듈화를 뛰어 넘어 구획화에 관한 것입니다. 선체가 손상된 경우 선박이 부력을 유지하기 위해 가지고있는 다른 구획을 생각하십시오.
• OOP는 종속성을 관리하는 방법이므로 프로그램의 다른 구성 요소가 다른 요소와 통신 할 수있는 정의 된 방법 세트 만 있기 때문에 버그를 쉽게 추적 할 수 있습니다.
• 프로그램에는 변수, 상수, 메소드, 파일, 매개 변수, 함수, 모듈 등 여러 가지 작업이 있습니다. 때로는 예측할 수없는 방식으로 서로 상호 작용할 수 있습니다. OOP는 서로 상호 작용할 수있는 방법의 수를 줄이는 일련의 원칙입니다. 그렇게하기 위해 OOP를 사용하지 않아도되지만 도움이됩니다.

그러나 고려해야 할 다른 요소가 있습니다.

• 프로그래머가 OOP / OOD에 능숙합니까?
• 프로그래머가 OOP 언어에 능숙합니까?
• 소프트웨어가 시간이 지남에 따라 복잡해질 것이라고 생각하십니까?
• 향후 코드를 확장하거나 재사용 할 계획입니까?
• "디자인"이 자산이 될 수 있다고 생각하십니까? 즉, 성장을 위해 또는 향후 프로젝트의 기초로 활용할 수 있습니까?

오해하지 마십시오 : OOP를 사용하지 않고 모든 것을 달성 할 수 있지만 OOP를 사용하면 더 쉬울 것입니다.

그러나...

팀이 OOP / OOD에 능숙하지 않고 해당 분야에 대한 전문 지식이없는 경우 보유한 리소스를 활용하십시오.

그래서 내 질문은 : 응용 프로그램에서 OOP를 언제 사용할지 알고 결정하는 방법은 무엇입니까?

항상 사용하십시오. 일단 익숙해지면 모든 용도로 사용됩니다. 이것은 기능과 사용 사이에 좋은 추상화를 보장하는 좋은 방법이며 유지 관리에 큰 이점이 있습니다. 예를 들어

• 예를 들어 작은 데이터 구조 객체는 다형성이기 때문에, 예를 들어 무언가를 구문 분석 한 후의 중간 데이터 구조는 종종 여러 개의 작은 엔티티를 가지는데, 이는 공통적 인 동작을 가지면서도 전문화되어 있습니다. 이들은 특수한 구현 및 동작, 즉 클래스 계층 (다형성)과 함께 공통 기본 클래스 또는 인터페이스에 대한 유스 케이스입니다.

• 예를 들어 로깅은 다른 로거를 쉽게 대체 할 수 있기 때문에

• 여러 개의 동시 구조를 활용하고 다중 CPU 프로세서를 활용할 수 있기 때문에 대규모 프로그램 구조. 예를 들어, 웹 서버는 객체로 인해 여러 개의 동시 요청 핸들러를 사소하게 사용할 수 있습니다.

앞에서 언급했듯이 리팩토링과 재사용이 더 쉬워 지므로 좋은 추상화가 가능 해져 유지 관리가 쉬워진다. OOP는 항상 수용되고 사용되어야합니다. 좋은 OOP 프로그래밍은 정적 메소드 및 / 또는 정적 데이터를 피하고 모든 것을 위해 객체를 사용합니다.

객체 지향 프로그래밍은 프레임 워크를 작성하는 도구를 제공합니다. 이러한 도구는 캡슐화, 추상화, 상속 및 다형성입니다. 이 아이디어는 프로그램을 두 섹션으로 나누는 데 도움이됩니다.

방법-이것은 코드의 프레임 작업 부분으로, 일종의 추상화를 생성하고, 블록의 일반적인 작동 방식과 다른 블록과의 상호 작용 방식을 결정합니다.

해야 할 일-이 부분은 블록이 실제 작업을 수행하는 곳입니다. 이 클래스는 "How to section"에서 생성 된 기본 클래스에서 파생됩니다.

OOPS의 혜택을 크게 누릴 수 있습니다

1. 기존 프레임 워크를 재사용 할 수 있고 "할 일"섹션에서 특정 세부 사항 만 구현해야하는 경우.
2. 현재 프로젝트를 위해 구현되고있는 기능은 일반적 / 일반적으로 사용되는 기능이며 다른 프로젝트 / 미래 프로젝트는 현재 프로젝트를 개발하는 동안 생성 된 프레임 워크에서 이점을 얻을 수 있습니다.
3. 거대한 프로젝트를 일반적으로 알려진 패턴으로 분류하여 큰 문제를 해결합니다.
4. 소규모 프로젝트에도 OOPS를 사용하여 사용 습관을 들이고 1 ~ 3 가지 유형의 문제가 발생하면 준비하십시오