OOP는 언제 더 적합합니까?[닫은]

https://stackoverflow.com/questions/6703

08-06-2019
|

문제

객체지향 프로그래밍을 공부하기 시작한 이래로 기능이 더 좋다거나 모든 문제를 객체로 모델링해서는 안 된다는 기사/블로그를 자주 읽었습니다.개인적인 프로그래밍 경험을 통해 언제 문제가 OOP로 더 잘 해결된다고 생각하시나요?

해결책

엄격하고 빠른 규칙은 없습니다.문제를 해결하고 OO 사고방식으로 사고하는 데 능숙할 때 문제는 OOP로 더 잘 해결됩니다.객체 지향은 컴퓨팅을 문제 해결을 위한 더 나은 도구로 만들기 위한 노력을 통해 탄생한 또 다른 도구일 뿐입니다.

그러나 이는 더 나은 코드 재사용을 허용하고 더 깔끔한 코드로 이어질 수도 있습니다.그러나 이러한 높은 평가를 받는 자질은 실제로는 실제 가치가 거의 없는 경우가 많습니다.기존의 기능적 애플리케이션에 OO 기술을 적용하면 실제로 많은 문제가 발생할 수 있습니다.기술은 다양한 기술을 배우고 당면한 문제에 가장 적합한 기술을 적용하는 데 있습니다.

OO는 종종 소프트웨어 개발에 대한 너바나와 같은 솔루션으로 인용되지만 당면한 문제에 적용하는 것이 적절하지 않은 경우가 많습니다.완벽한 솔루션에 도달하기 위해 문제를 과도하게 엔지니어링하는 경우가 종종 있지만 실제로는 필요하지 않은 경우가 많습니다.

본질적으로 OOP는 실제로 객체 지향 프로그래밍이 아니지만 객체 지향 사고를 OO 기술을 지원할 수 있는 프로그래밍 언어에 매핑합니다.OO 기술은 본질적으로 OO가 아닌 언어에서 지원될 수 있으며 기능적 언어 내에서 이점을 활용하기 위해 사용할 수 있는 기술이 있습니다.

예를 들어, 나는 지금까지 약 20년 동안 OO 소프트웨어를 개발해왔기 때문에, 문제를 해결할 때 어떤 언어를 사용하든 OO 용어로 생각하는 경향이 있습니다.현재 저는 기본적으로 지원하지 않는 Perl 5.6을 사용하여 다형성을 구현하고 있습니다.개발 문제가 아닌 코드의 유지 관리 및 확장을 간단한 구성 작업으로 만들기 때문에 이 작업을 선택했습니다.

이것이 명확한지 확실하지 않습니다.OO법정에서 힘든 사람이 있고, 기능법정에서 힘든 사람이 있습니다.그리고 두 가지를 모두 시도하고 각각의 장점을 최대한 활용하려고 노력하는 사람들이 있습니다.둘 다 완벽하지는 않지만 둘 다 언어에 관계없이 활용할 수 있는 매우 좋은 특성을 가지고 있습니다.

OOP를 배우려는 경우 OOP에만 집중하지 말고 문제 해결의 전체 스펙트럼에 객체 지향 분석 및 일반적인 OO 원칙을 활용하십시오.

다른 팁

나는 노련한 사람이지만 오랫동안 OOP를 프로그래밍해 왔습니다.나는 개인적으로 OOP를 단지 사용하기 위해 사용하는 것에 반대합니다.나는 사물이 존재하는 구체적인 이유를 갖고 있고, 구체적인 것을 모델로 삼고, 의미가 있는 사물을 선호합니다.

많은 신규 개발자들이 겪고 있는 문제는 자신이 만든 코드와 함께 소비하는 리소스에 대한 개념이 없다는 것입니다.많은 양의 데이터를 처리하고 데이터베이스에 액세스할 때 "완벽한" 개체 모델은 성능과 리소스 측면에서 최악의 방법일 수 있습니다.

결론은 개체 모델 구현이 성능/리소스에 미치는 영향을 고려하는 한 개체로서 의미가 있다면 개체로 프로그래밍하는 것입니다.

나는 이것이 상태와 응집력 있는 무언가를 모델링하고 해당 상태에 대한 관련 동작을 모델링할 때 가장 적합하다고 생각합니다.좀 모호한 것 같지만 여기에 완벽한 답이 있는지는 모르겠습니다.

OOP의 장점은 데이터와 정보를 캡슐화하고 추상화할 수 있다는 것인데, 이는 대규모 시스템을 구축하는 데 있어 큰 이점이 됩니다.다른 패러다임에서도 동일한 작업을 수행할 수 있지만 이 범주에서는 OOP가 특히 유용한 것 같습니다.

또한 사용하는 언어에 따라 다릅니다.풍부한 OOP 지원을 제공하는 언어라면 이를 활용하는 것이 좋습니다.그렇지 않은 경우 문제를 더 작고 쉽게 테스트할 수 있는 조각으로 나누는 데 도움이 되는 다른 메커니즘을 찾아야 할 수도 있습니다.

나는 OOP에 팔렸습니다.

문제에 대한 개념을 정의할 수 있는 경우 언제든지 개체로 래핑될 수 있습니다.

OOP의 문제점은 일부 사람들이 OOP를 과도하게 사용하여 코드를 이해하기 더욱 어렵게 만들었다는 것입니다.객체에 넣는 것과 서비스(정적 클래스)에 넣는 것에 주의를 기울이면 객체를 사용하는 것이 좋습니다.

처음에는 생각하지 못했던 새로운 작업을 수행하고 리팩토링하고 해당 기능을 추가하는 가장 좋은 방법을 찾으려면 개체가 필요하기 때문에 개체에 속하지 않는 것을 개체에 넣지 마십시오.

객체 기반, 기능적 또는 절차적 코드보다 객체 지향을 선호해야 하는지 여부에는 5가지 기준이 있습니다.이러한 스타일은 모든 언어로 제공된다는 점을 기억하세요. 스타일.모두 "이 상황에서 OO를 선호해야 할까?"라는 문체로 쓰여있습니다.

시스템은 매우 복잡하며 약 9,000개 이상의 LOC(임의 수준)를 갖습니다.-- 시스템이 더욱 복잡해짐에 따라 복잡성을 캡슐화하여 얻는 이점도 상당히 늘어납니다.OO를 사용하면 다른 기술과 달리 점점 더 많은 복잡성을 캡슐화하는 경향이 있는데, 이는 이 수준에서 매우 가치가 있습니다.그 전에는 객체 기반 또는 절차적 방식을 선호해야 합니다.(이것은 특정 언어를 옹호하는 것이 아닙니다. OO씨 내 생각에는 이러한 기능이 OO C++보다 더 적합합니다. 추상화 누출로 악명 높고 평범하고 완고한 프로그래머 1명과 함께 점심 식사를 할 수 있는 능력이 있는 언어입니다.

귀하의 코드는 데이터에 대한 작업이 아닙니다(예:데이터베이스 기반 또는 수학/분석 기반).데이터베이스 기반 코드는 절차적 스타일을 통해 더 쉽게 표현되는 경우가 많습니다.분석 기반 코드는 함수형 스타일로 더 쉽게 표현되는 경우가 많습니다.

귀하의 모델은 무언가의 시뮬레이션입니다(OO는 시뮬레이션에 뛰어납니다).

OO의 객체 기반 하위 유형 디스패치가 중요한 작업을 수행하고 있습니다(즉, 특정 유형 및 다양한 하위 유형의 모든 객체에 메시지를 보내고 이들 모두에서 적절하지만 다른 반응을 얻어야 함). .

특히 작업자가 아닌 작업 메서드 유형의 코드베이스에서는 앱이 다중 스레드가 아닙니다.OO는 다중 스레드로 구성되어 있고 다른 작업을 수행하기 위해 다른 스레드가 필요한 프로그램에서 상당히 문제가 많습니다.프로그램이 하나 또는 두 개의 기본 스레드와 동일한 작업을 수행하는 많은 작업자 스레드로 구성된 경우 모든 작업자 스레드가 접촉하는 대상에서 격리되고 다음과 같이 간주될 수 있으므로 OO 프로그램의 혼란스러운 제어 흐름을 처리하기가 더 쉽습니다. 코드의 모놀리식 섹션.실제로 다른 패러다임을 고려하십시오.기능적 기능은 멀티스레딩에서 탁월하며(부작용이 없다는 것은 큰 이점입니다), 객체 기반 프로그래밍은 OO의 일부 캡슐화를 통해 이점을 제공할 수 있지만 코드베이스의 중요한 섹션에서 보다 추적 가능한 절차 코드를 사용합니다.물론 절차는 이 분야에서도 탁월합니다.

OO가 좋지 않은 곳은 SQL과 같은 데이터 "세트"를 다루는 곳입니다.OO는 두 집합의 교집합이나 두 집합의 상위 집합을 최적으로 취하도록 실제로 설계되지 않았기 때문에 집합 기반 연산을 더 어렵게 만드는 경향이 있습니다.

또한 다음 예제에서 가져온 것과 같이 기능적 접근 방식이 더 의미가 있는 경우도 있습니다. MSDN:

예를 들어, XML 문서를 다른 형식의 데이터로 변환하는 프로그램을 작성한다고 생각해 보세요.XML 문서를 구문 분석하고 다양한 if 문을 적용하여 문서의 여러 지점에서 수행할 작업을 결정하는 C# 프로그램을 작성하는 것이 확실히 가능하지만, 틀림없이 더 나은 접근 방식은 변환을 확장 가능한 스타일시트로 작성하는 것입니다. XSLT(언어 변환) 프로그램.당연히 XSLT 내부에는 기능주의가 많이 담겨 있습니다.

나는 주어진 문제를 '사물'의 관점에서 생각하는 것이 도움이 된다고 생각합니다.

문제가 하나 이상의 '사물'을 갖는 것으로 생각할 수 있고, 각 '사물'에는 해당 상태를 참조하는 여러 속성 또는 정보 조각과 수행할 수 있는 여러 작업이 있는 경우 OOP입니다. 아마도 갈 길일 것입니다!

객체지향 프로그래밍 학습의 핵심은 디자인 패턴을 배우는 것입니다.디자인 패턴에 대해 배우면 클래스가 필요할 때와 필요하지 않을 때를 더 잘 알 수 있습니다.프로그래밍에 사용되는 다른 모든 것과 마찬가지로 OOP 언어의 클래스 및 기타 기능 사용은 디자인 및 요구 사항에 따라 다릅니다.알고리즘과 마찬가지로 디자인 패턴은 더 높은 수준의 개념입니다.

디자인 패턴은 전통적인 프로그래밍 언어의 알고리즘과 비슷한 역할을 합니다.디자인 패턴은 유용한 작업을 수행하기 위해 객체를 생성하고 결합하는 방법을 알려줍니다.최고의 알고리즘과 마찬가지로 최고의 디자인 패턴은 다양한 공통 문제에 적용할 수 있을 만큼 충분히 일반적입니다.

내 생각에는 그것은 인간으로서의 당신에 관한 질문에 더 가깝습니다.어떤 사람들은 기능적 측면에서 더 잘 생각하고 다른 사람들은 클래스와 객체를 선호합니다.나는 OOP가 세계의 내부(주관적) 정신 모델과 일치할 때 더 적합하다고 말하고 싶습니다.

객체지향 코드와 절차적 코드는 확장성 포인트가 다릅니다.객체 지향 솔루션을 사용하면 기존 함수를 수정하지 않고도 새 클래스를 더 쉽게 추가할 수 있으며(개방 폐쇄 원칙 참조), 절차 코드를 사용하면 기존 데이터 구조를 수정하지 않고도 함수를 추가할 수 있습니다.시스템의 다양한 부분에는 예상되는 변경 유형에 따라 다양한 접근 방식이 필요한 경우가 많습니다.

OO를 사용하면 개체와 관련된 논리를 단일 위치(클래스 또는 개체) 내에 배치하여 분리할 수 있고 디버그 및 유지 관리가 더 쉬워집니다.

내가 관찰한 바에 따르면 모든 앱은 OO와 절차적 코드의 조합입니다. 여기서 절차적 코드는 모든 개체를 함께 묶는 접착제입니다(적어도 기본 기능의 코드).절차적 코드를 OO로 더 많이 변환할수록 코드를 유지 관리하는 것이 더 쉬워집니다.

프로그래밍에 OOP가 사용되는 이유:

유연성 - OOP는 사용 구현 측면에서 정말 유연합니다.
소스 코드를 99.9% 이상 줄일 수 있습니다. 너무 과장된 것처럼 들릴 수도 있지만 사실입니다.
보안 구현이 훨씬 쉽습니다. 웹 개발에 있어서 보안이 중요한 요구 사항 중 하나라는 것을 우리 모두 알고 있습니다.OOP를 사용하면 웹 프로젝트의 보안 구현이 쉬워집니다.
코딩을 더욱 체계적으로 만듭니다. 우리 모두는 클린 프로그램이 클린 코딩이라는 것을 알고 있습니다.절차적 대신 OOP를 사용하면 일이 더 체계화되고 체계화됩니다(분명히).
이는 팀이 서로 쉽게 협력하는 데 도움이 됩니다. 여러분 중 일부는 팀 프로젝트를 경험했거나 경험한 적이 있다는 것을 알고 있으며 일부는 동일한 방법, 구현, 알고리즘 등을 갖는 것이 중요하다는 것을 알고 있습니다.

문제에 따라 다릅니다.OOP 패러다임은 사용자의 작업 중에 많은 엔터티가 존재하는 분산 시스템이나 프레임워크를 설계하는 데 유용합니다(예:웹 애플리케이션).

그러나 수학 문제가 있는 경우에는 기능적 언어(LISP)를 선호할 것입니다.성능이 중요한 시스템의 경우 ADA 또는 C 등을 사용합니다.

OOP 언어는 프로그램 실행 시 가비지 수집기(메모리 자동 사용)를 사용하기 때문에 유용합니다.C로 프로그래밍하는 경우 메모리 문제를 수동으로 디버깅하고 수정해야 하는 경우가 많습니다.

OOP는 물건이 있을 때 유용합니다.소켓, 버튼, 파일.er에서 클래스를 종료하면 거의 항상 클래스인 척하는 함수입니다.TestRunner는 테스트를 실행하는 함수(그리고 아마도 실행 테스트라고 명명될 수도 있음)일 가능성이 높습니다.

개인적으로 OOP는 모든 대규모 애플리케이션에 실질적으로 필요하다고 생각합니다.OOP를 사용하지 않고 10만 줄이 넘는 코드가 있는 프로그램을 만드는 것은 상상할 수 없습니다. 이는 유지 관리 및 설계에 악몽이 될 것입니다.

OOP가 나쁠 때 알려드립니다.

설계자가 매우 복잡하고 문서화되지 않은 OOP 코드를 작성할 때.프로젝트 중간에 종료됩니다.그리고 그가 다양한 프로젝트에서 사용한 많은 공통 코드에는 누락된 코드가 있습니다..NET Reflector를 주셔서 감사합니다.

그리고 조직에서는 Visual Source Safe 또는 Subversion을 실행하지 않았습니다.

그리고 미안해요.로그인을 위한 2페이지의 코드는 귀엽게 OOP되어 있어도 다소 우스꽝스럽습니다....

라이센스 : CC-BY-SA ~와 함께 속성

제휴하지 않습니다 StackOverflow