객체 지향 프로그래밍이 어떤 문제에 적합하지 않은가? [닫은]

이 질문에서 영감을 얻은 것 : 함수 프로그래밍이 어떤 일반적인 문제에 적합하지 않습니까? -그럼에도 불구하고 항상 원했던 질문이지만 너무 두려워서 물어 보지 않았습니다.

나는 ... 글쎄, 엔지니어링 소프트웨어 개발을 실제로 내 인생 전체 라고 부르며 , OO는 항상 (잘, 대부분 의 시간 동안) 있었지만 결코 사용할 필요가 없었습니다. "그 방법"도없고, 그 패러다임을 배우지도 않습니다. 우리는 항상 단순한 프로그램 구조, 루틴 / 함수 / 모듈을 사용해 왔으며, 오늘날의 프로그램 관리 (약 300k LOC, 너무 크지 않은 프로그램)를 관리하는 것이 오늘날의 모범 사례와 반대이지만 불가능하지는 않지만 결코 어려운 일이 아니라는 것이 증명되었습니다.

그래서 객체 지향 패러다임이 좋은 선택이 아닌 종류의 문제는 무엇입니까? 절차 적 프로그래밍과 비교하여?

객체 지향 프로그래밍 은 절차 적 프로그래밍입니다. Robert Harvey가 주석에서 언급했듯이 OO 객체 지향을 만드는 것은 OO가 특정 방식으로 데이터를 추상화한다는 것입니다 (즉, 해당 구조와 구조에서 작동하는 함수 묶음).

William Cook 은 객체와 추상 데이터 유형의 차이점을 잘 설명합니다.

따라서 쉽게 들리게 할 위험이 있으므로 데이터에서 수행하는 작업 수를 쉽게 확장해야 할 때 객체가 적합하지 않으며 다양한 구현을 할 필요가 없다고 말합니다. 데이터. 그렇게 말하면서 , 둘을 더 가깝게하기 위해 할 수있는 일이 있습니다 .

OO의 주요 가치는 시스템 구성 요소간에 디커플링을 제공하여 DRY 코드를보다 쉽게 ​​작성하고 설계에서 계획 한 특정 유형의 변경에 쉽게 적응할 수 있다는 것입니다. 비용은 간접 계층을 추가하여 코드를 추론하기 어렵고 예상치 못한 방식으로 수정하기가 더 어려워 질 수 있습니다 (디자인이 제공하는 분리에 의해 도움이되지 않는 방식). 따라서 제공하는 디커플링이 필요하지 않은 하위 문제는 시간 낭비입니다. 특히 DRY 코드를 코드없이 쉽게 작성할 수 있고 OO가 제공하는 강력한 디커플링의 이점이 있는 특정 요구 사항 변경을 예상하지 않으면 시간 낭비입니다 .

동시성 : 잠금 메커니즘은 문제가있는 것 같습니다. 아주 훌륭한 개발자들만이 프로젝트의 스레딩 부분에서 작업하게됩니다.

확장 : 현재 OO 언어가 얼마나 확장 가능한지 모릅니다. Java가 나쁘다는 것만 알고 있습니다. 따라서 DSL (도메인 특정 언어)은 프레임 워크로 구현되어야합니다. 반면 Clojure (기능적)에는 매크로가 있습니다.

OO에 정통한 여부에 관계없이 대부분의 프로그래머는 추상화, 정보 숨기기 및 코드와 같은 인터페이스와 같은 개념을 사용합니다. OO 언어는 이러한 개념이 이미 내장되어 있기 때문에 간단합니다. 직접 발명 할 필요는 없습니다.

핵심 알고리즘 qsort()은 임의의 객체를 비교하기 위해 추상화를 사용합니다. fread()인터페이스를 사용하여 스트림 등의 세부 정보를 추상화합니다.

이러한 관점에서 비 OO 접근 방식으로 더 잘 해결되는 특정 문제를 찾기가 어렵습니다.

웹 API (rest, xmlprc, plain curl / wget)를 통해 다른 시스템을 결합하는 시스템을 구축 할 때 OO 래퍼를 작성할 수는 있지만 분명히 편리하다고 생각합니다. 사용되는 웹 서비스가 단순하고 한두 줄의 문제라면 OO가 너무 많습니다. 반면에 복잡한 웹 API (예 : Amazon AWS)를 래핑해야하는 경우 래퍼 라이브러리 (예 : AWS의 Python의 boto)를 사용하는 것이 좋습니다.

생각?

PURE 객체 지향 언어는 많은 경우에 적합하지 않습니다. 순수한 객체 지향 언어가되기 위해 충족해야 할 몇 가지 기준이 있기 때문입니다. https : //.com/questions/250062/what-is-meant-by-the-term-true-object-orientation/250098#250098을
참조하십시오.

그러나 가장 널리 사용되는 프로그래밍 언어는 다중 패러다임입니다. 다양한 비 OO 기능을 통합하여 다양한 유형의 프로그래밍 및 개발 문제가 발생합니다. C ++, C #, Java 또는 Ruby에는 모두 비 OO 기능이 있습니다. 따라서 순수 OO가 좋지 않은 문제에 직면 할 수 있습니다.

객체 지향 프로그래밍을 사용하여 도메인을 모델링 할 수 있습니다. 클래스는 도메인 모델 내에서 엔티티, 집계, 협업, 서비스의 상태 및 동작을 나타내는 데 사용할 수 있습니다. 또한 객체 간의 메소드 호출 및 프로토콜은 엔티티 간의 동적 관계를 모델링 할 수 있습니다.

기술적 인 문제 (예 : 데이터베이스 사용, 메시지 큐 또는 사실 그것은 웹 응용 프로그램입니다). 주제에 관한 좋은 책은 도메인 기반 디자인입니다

여기서 주목해야 할 것은 위에서 언급 한 "엔티티"가 실제 객체에 매핑 될 필요가 없다는 것입니다! 응용 프로그램 도메인의 추상 부분을 나타낼 수 있습니다.

이것이 객체 지향 프로그래밍이 좋은 것이라면; 무엇이 좋지 않은가? 도메인 모델을 객체로 표현할 수없는 모든 것이 있습니다. 예를 들어, 수학, 통계, 논리 등의 일부 또는 기술 (예 : 컴파일러) 프로그램은 다른 스타일로 더 잘 표현할 수 있습니다. 비즈니스 워크 플로 응용 프로그램의 경우 OO와 사용자 지정 DSL 기술의 조합이 비즈니스 프로세스에서 발생하는 관계 및 이벤트의 종류를 모델링하는 데 매우 효과적이라는 것을 알았습니다. 순수한 기능은보다 직접적인 수학적 추론을 허용하기 때문에 프로그램 검증 및 자동 증거 확인을 위해 기능적 접근 방식이 종종 사용됩니다.