답변:
나는 약 99.9999 %의 확신으로 WordPress가 향후 버전에서 완전히 OOP가되지 않을 것이라고 확신 할 수 있습니다. 그렇게
1990 년경부터 OOP를 프로그래밍하고 가르치는 것에 대한 개인적인 경험을 살펴보면 핵심 팀에 동의하고 완전한 OOP가 실수라고 생각합니다. 나는 한때 OOP 열광하고 OOP가 만병 통치약이라고 생각했지만 그 이후에는 일부 상황에서는 가치가 있지만 다른 상황에서는 가치가 있다고 생각하게되었습니다.
내가 OOP에서 찾은 가장 큰 문제 중 하나는 개발자가 구조가 무엇인지 이해하기 훨씬 전에 개발자가 구조를 구워야한다는 것인데, 이는 취약한 기본 클래스 문제 로 이어진다 .
물론 WordPress의 선택된 측면에 대해 OOP는 의미가 있으며 핵심 학습을하면 그러한 클래스를 찾을 수 있습니다. Widget, List_Tables (3.1) 등
이 시점에서 나는 대부분의 비 OOP 패러다임에서 WordPress와 함께 일하게되어 기쁘다. 순수한 OOP라면 WordPress는 다음과 같은 것을 얻지 못했을 것이라고 생각합니다. 왜? OOP는 워드 프레스 사용자 및 플러그인 개발자의 복잡성을 높였 기 때문에 핵심 팀이 과거에 사용자의 요구에 대해 더 많이 배우면서 진화하기에 충분히 유연하지 않은 응용 프로그램을 만들었을 것입니다. 6 년.
FWIW.
많은 WP 구성 요소가 모든 새로운 릴리스와 함께 OOP 코드로 다시 작성되며 새로운 구성 요소가이를 사용하는 경향이 있습니다 (예 : WP_Customizer사물). 그러나 WP가 아키텍처를 완전한 객체 지향 아키텍처로 변경할 것인지 묻는다면 현재는 그러한 것을 제안하는 정보가 없습니다.
나는 결코 그런 일이 일어나지 않을 것이라고 말하지는 않았지만 가까운 미래에 일어날 가능성은 낮으며 아마도 "기본 클래스"문제로 인한 것이 아닐 것입니다. :)
우선, WordPress와 같은 CMS 응용 프로그램에서 OOP보다 절차 코드를 사용하는 데는 단점이 있습니다. 단순히 그러한 응용 프로그램은 플러그인을 통해 확장되어야하기 때문입니다. 함수와 전역 변수를 혼합하여 사용하면 이것이 더 쉬워지지는 않습니다. WP가 작성된 당시에는 아무도 WP가 될 것인지 예측할 수 없었고 많은 잘못된 선택이 이루어졌습니다. 대부분의 플러그인과 테마가 제대로 작동하지 않기 때문에 따라 잡기가 매우 어렵습니다. 이를 방지하기 위해 거대한 호환성 레이어를 구현하면 WP 속도가 느려지고 개발자들 사이에 더 많은 혼란이 생길 수 있습니다. 또한 사용자의 비용으로 개발자의 삶을 편하게하는 목적을 생각하십니까?
도움이된다면 -wp-hackers에 대한 아주 오래된 토론 이지만 여전히이 주제와 관련이 있으며 커뮤니티 가 제안한 아이디어 는 이제 "플러그인 영역"으로 태그되었습니다. 최근에이 방향으로 다른 활동을 보지 못했습니다.