OOP 자체는 처음부터 변하지 않았습니다. 그것에 대한 몇 가지 새로운 각도가 탐구되었지만 핵심 원칙은 여전히 ​​동일합니다. 어쨌든, 수년간 수집 된 집단 지식은 프로그래머의 삶을 어렵게 만드는 것이 아니라 쉽게 만듭니다. 디자인 패턴은 방해가되지 않습니다. 수년간의 경험에서 추출 된 표준 문제에 대한 솔루션의 도구 상자를 제공합니다.

그렇다면 오늘날 OOP를 사용하기 시작했을 때보 다 더 복잡하다고 생각하는 이유는 무엇입니까?

한 가지 이유는 노출되는 코드가 더 복잡해지기 때문일 수 있습니다. OOP가 더욱 복잡해 졌기 때문이 아니라 학습 래더를 발전시키고 더 크고 복잡한 코드 기반을 읽었 기 때문입니다.

또 다른 이유는 복잡성 패러다임이 변경되지 않았지만 일반 소프트웨어 프로젝트의 크기와 복잡성이 매우 좋을 수 있기 때문입니다. 20여 년 전에 서버 에서 개발자의 꿈이었던 고객 급 휴대폰에서 처리 능력을 사용할 수있게 되면서 일반 대중은 기본적으로 가장 저렴한 응용 프로그램까지 매끄러운 애니메이션 GUI를 기대하고 엔트리 레벨 데스크탑 PC는 더욱 강력 해졌습니다. 1980 년대의 “슈퍼 컴퓨터”보다 스몰 토크와 C ++의 초기부터이 기준이 높아진 것은 당연하다.

그리고 현대 응용 프로그램에서는 동시성 및 병렬 처리가 예외가 아니라 표준이라는 사실이 있습니다. 응용 프로그램은 종종 여러 컴퓨터간에 통신하여 전체 프로토콜 동물원을 출력하고 파싱해야합니다. OOP는 조직적 패러다임으로서 훌륭하지만 다른 패러다임과 마찬가지로 한계가 있습니다. 예를 들어 동시성에 대한 많은 추상화를 제공하지 않습니다 (대부분의 구현은 다소 사후에 고려되거나 라이브러리에 완전히 아웃소싱됩니다) 파서를 작성하고 데이터를 변환하는 가장 좋은 방법은 아닙니다. 최신 프로그래밍은 종종 OOP 패러다임의 한계에 부딪치며 디자인 패턴은 지금까지만 가능합니다. (몸소, 패러다임이 이러한 솔루션을 즉시 제공한다면 패러다임이 이러한 문제에 대해 더욱 표현력이 좋으며 표준 솔루션이 분명 할 것입니다. 메소드 상속은 OOP의 핵심 기능이기 때문에 메소드 상속을 설명하는 디자인 패턴이 없습니다. 그러나 OOP는 객체를 다형성 및 투명하게 구성하는 명백한 자연적인 방법을 제공하지 않기 때문에 팩토리 패턴이 있습니다.)

이 때문에 대부분의 최신 OOP 언어는 다른 패러다임의 기능을 통합하여보다 표현력이 뛰어나고 강력하지만 복잡해집니다. C #은 이에 대한 주요 예입니다. 명백한 OOP 루트를 가지고 있지만 델리게이트, 이벤트, 형식 유추, 변형 데이터 형식, 특성, 익명 함수, 람다 식, 제네릭 등의 기능은 다른 패러다임, 특히 기능적 프로그래밍에서 비롯됩니다. .

답변

std::stack<int> s;
s.push(5);
s.pop();

var userId = Request.QueryString["UserID"].ToInt();
var user = new User(userId);
user.Name = ...;
...
user.Save();

Stock stock = new Stock();
stock.addItem(item);
stock.removeItem(item);
this.StockRepository.Add(stock);