OOP 기술 사망 [폐쇄]

9

측면 지향 프로그래밍에 대해 여러 번 들었습니다. 주로 프로그래밍의 "차세대"기술이며 OOP를 '죽일'것입니다.

맞아? OOP가 죽거나 그 이유는 무엇입니까?

object-oriented

— 비인간 화
소스

40

누군가 하나의 소프트웨어 기술이 다른 소프트웨어 기술을 죽이거나 전체 시장 / 사용 / 청중을 지배한다고 말할 때마다 다음을 기억하십시오.

건전한 (동적이지만 안정적인) 생태계는 매우 다양한 종으로 구성됩니다.

즉, 새로운 과장된 기술은 과대 광고 곡선을 통과하게되고 결국에는 시간과 경험을 통해 특정 목적을 찾게됩니다.

과대 광고 곡선

또한 측면 지향 프로그래밍과 같은 극단적 인 개념은 비용이 암시되어 있기 때문에 항상 그런 것은 아니라는 것을 의미하는 경우 유용합니다.

그러나 이미 OOProgramming, 일반 프로그래밍, 기능 프로그래밍, 절차 프로그래밍 등과 같은 위치에 있습니다.

실생활에서 널리 사용되고 널리 사용되는 언어가 "순수하지 않은"언어라는 것을 알고 계셨습니까? 여러 패러다임을 허용하면 시간이 지남에 따라 컨텍스트를 더 유연하게 변경하고 더 많은 사용 틈새를 채울 수 있기 때문입니다.

— 클라 임
소스

1

'순수하지 않음'에 +1 순수한 OOP 언어를 제외하고, 특히 죽은 매우 틈새 사용 / 학자.

— jv42

순수한 OO 언어는 무엇입니까? 잡담?

— Zhehao Mao 2016 년

20

AOP로 인해 OOP가 종료되지 않습니다. AOP는 가치를 더하지만 OOP와 완벽하게 공존합니다. 함수형 프로그래밍이 OOP를 죽일 것이라고 생각하지 않습니다. OOP는 많은 종류의 문제 영역에 적합하기 때문에 기능 패러다임으로 대체하는 것은 의미가 없습니다.

— 사용자 281377
소스

1

그것은 매우 주관적입니다. OOP가 특정 문제 영역에 적합하지 않다고 생각합니다. 특정 개발자가 솔루션을 만드는 방법에 적합합니다. 개발자가 패러다임 스위치를 만들 수 없기 때문에 OOP는 죽지 않을 것입니다.

— Raynos 2016 년

6

OOP가 가장 적합한 전형적인 예는 GUI입니다. 언어가 아니더라도 OO가 아닌 GUI 툴킷에 대한 API를 상상하기는 어렵습니다. (문제 도메인이라는 용어가 일반적으로 사용되는 방식은 아닙니다.) OOP가 적합한 실제 문제 도메인의 예를 제공하려면 : 창고 자동화. 저장 및 검색 차량과 그 활동을 모델링하면 OOP가 자연스럽게 느껴집니다.

— user281377 2018 년

2

@ ammoQ, OO로 표현하면 GUI가 끔찍합니다. 이것이 모든 API가 DSL (WPF 등)을 향해 표류하는 이유입니다. Tk-OOP의 단일 흔적은 없지만 상상하기 어렵지 않지만 여전히 프로그래밍이 훌륭하고 모양과 느낌이 아니라 Java OO 툴킷보다 훨씬 좋습니다. OOP는 나열된 에이전트와 같은 모든 에이전트 기반 시뮬레이션에 잘 맞지만 기존 문제의 작은 부분입니다.

— SK-logic

6

내가 찾을 수있는 tk의 첫 번째 예를 보면 어떻게 OO가 아닌가? 튜토리얼에서 : "위젯은 객체, 버튼, 프레임 등을 나타내는 클래스의 인스턴스입니다." tkdocs.com/tutorial/concepts.html 더욱이 DSL 자체는 OO 프로그래밍에 매우 의존적입니다. 그래서 나는 당신이 말하려는 것을 정말로 이해하지 못하고 있습니까?

— 잉카

3

@ Sk-logic, @ammoQ, @Raynos, @jkocking, 나는 그것을 독자적인 질문으로 홍보했습니다 : programmers.stackexchange.com/questions/88385/… 이것에 대해 더 많은 설명을하고 싶습니다. 배우고 싶습니다.

— 잉카

12

패러다임이왔다 갔다하지만 레거시 코드는 영원합니다. 항상 C ++ 코드를 유지 관리해야하므로 OOP가 완전히 종료되지는 않습니다.

— 존 보데
소스

6

진정으로 훌륭한 문구 : +1 : "패러다임이왔다 갔다하지만 레거시 코드는 영원히"

— NoChance

8

짧은 대답 : 아니요, 그렇게 생각하지 않습니다.

더 긴 대답 : AOP에 대해 이해하는 것 자체는 프로그래밍 패러다임이 아니며 (OOP를 대체하지는 않음) 더 짧은 방법, 더 간단한 단일 책임 클래스를 작성하는 데 도움이되는 툴킷입니다. 등. 그러나 OOP를 대체하지는 않습니다.

(적어도 부분적으로) 수행하는 것은 교체하거나 추가 OOP에 실제로 프로그래밍 기능이다 있다 (이 예를 들면, OOP와 혼합 될 수 있지만, 다른 프로그래밍 패러다임 스칼라 프로그래밍 언어 ). 불변의 데이터 구조와 특히 동시성에 관해서는 OOP 개발자를 좌절시키는 경향이있는 모든 종류의 멋진 기능을 선호합니다.

— 크 툴후
소스

기능적 <-> 명령은 라인입니다. OOP는 이것과 유사합니다. 절차가 OOP의 다른쪽에 있다고 생각하지만 확실하지 않습니다. 물론 기능적 패러다임이 OOP 패러다임보다 오래되었다는 것이 재미있다. :)

— Raynos

2

@Raynos, 직선이 없습니다. OOP는 거대한 (무한한) 가능한 추상 언어 세트 안에있는 하나의 작은 금속 화 추상화입니다. 물론 그들 중 한 명에게 자신을 제한하는 것은 매우 어리 석습니다.

— SK-logic

6

OOP는 많은 상황에서 사실상의 접근 방식으로 가정 된 이래로 덜 알려졌습니다. AOP는 어떤 종류의 대중 운동으로도 결코 벗어나지 않았습니다.

5

OOPSLA '97 Tutorial에서 처음으로 Aspect 지향 프로그래밍에 대해 들었던 것을 기억합니다. 그들은 그때 OO를 죽일 것이라고 말했습니다. 그 이후로 OO는 가장 기대 이상으로 성장했습니다. AOP는 여전히 컴퓨팅 산업에 영향을 미치지 않는 것으로 거의 알려져 있지 않습니다. 나는 AOP가 OO 킬러가 아니라는 대답이 분명하다고 생각합니다.

— 덩크
소스

1

기존 AOP 시스템을 살펴보십시오. 예를 들어 Spring AOP는 클래스에 메소드를 정의한 것에 의존합니다. Castle Windsor는 객체 지향 언어 인 C #에서 지원합니다.

이론적으로 OOP에서 구조적 프로그래밍으로 전환하고 AOP를 유지할 수는 있지만 실제로는 어려울 것입니다. 하위 클래스를 쉽게 작성하고 관련 메소드를 재정 의하여 적절한 사전 / 이후 필터를 호출 한 다음 종속성 주입 프로세스에서 전달합니다.

정적 메소드 호출을 다시 작성하여 사용자 정의 필터를 호출하도록 설계된 트램펄린 메소드로 라우팅하는 것은 비교하기가 어렵습니다.

따라서 일반적인 구현 관점에서 AOP에는 OOP가 필요합니다.

— 다 세난
소스

0

OOP는 확실히 은색 총알이 아니지만 AOP에 대해서도 마찬가지입니다. 구성 요소 기반 디자인을 지원하지만 더 큰 구성표에서 구성 요소는 새로운 객체이고 구성 요소 인터페이스는 기본적으로 트랜잭션 메서드 목록이며, OOP가 아닙니다.

더 많은 AOP 및 구성 요소 기반 설계는 Anemic Data Model을 지원합니다.

http://martinfowler.com/bliki/AnemicDomainModel.html

(위의 기사는 오래되었지만 놀랍게도 관련이 있음을 알고 있습니다)

결론은 AOP 시스템이 여기에 있지만 완벽하지는 않다는 것입니다. 완벽한 시스템은 없습니다.

— maple_shaft
소스