PHP는 객체 지향적 방법은 무엇입니까? [닫은]


13

동료들과 재미있는 대화를 나눌 기회가있었습니다. 대부분은 플래시 액션 스크립트 또는 Java 개발자입니다.

우리는 PHP가 OOP를 얼마나 잘 처리하는지에 대해 이야기했습니다. PHP는 PHP 5.2 또는 5.3에서 거의 모든 OOP를 처리 할 수 ​​있다고 말했다. 내가 잘못? 예 / 아니오로 답을 구하려고하지는 않지만 개발자로부터 더 많은 의견을 듣고 싶습니다.


나는 그 대답했습니다 여기
마틴 Wickman에게

12
언어는 나쁘지 않습니다, 프로그래머는

@Jarrod Roberson : 언어는 선천적입니다. 그렇다면이 주장을지지하는 연구를 참조하십시오.
blunders

4
@Jarrod, 특히 초기 버전에있을 때 합법적으로 나쁜 언어가 있습니다. 초기 버전의 Actionscript, Javascript, Java 및 PHP가 떠 오릅니다.
Jordan

2
@JarrodRoberson, 그래서 PHP를 설계 한 프로그래머들은 ...
dan_waterworth

답변:


34

PHP 5.3은 실제로 OOP를 상당히 지원합니다.

OOP와 관련하여 PHP의 문제는 OOP가 실제로 언어에 볼트로 연결되어 있지만 Java 및 ActionScript와 같은 언어에서는 핵심 개념의 일부이지만 객체 의미가 좋지 않기 때문에 나쁜 OOP 언어를 모두 고려한다는 것입니다.

요즘에는 PHP가 OOP에 적합하지만 문제는 다음과 같습니다.

  1. PHP 5.3에서는 대부분의 코드 기반 (라이브러리, 프레임 워크, 커스텀 코드)이 작성되지 않았습니다.
  2. API의 대부분은 절차 적입니다. array여전히 가장 중요하고 가장 많이 사용되는 유형이며 개체가 아닙니다.
  3. 대부분의 PHP 프로그래머는 가까운 시일 내에 절차 적 스타일을 고수 할 것입니다. 예를 들어, Objective-C와 달리 PHP는 OOP를 홍보 하지 않습니다 . Objective-C는 C를 완전한 서브 세트로 가지고 있으므로 가장 순수한 형태 중 하나의 절차 적 프로그래밍 을 허용 하지만 OOP의 사용을 분명히 선호합니다.

PHP는 단순히 모든 레거시를 제거 할 수 없습니다. PHP 6이 릴리스 된 경우 대부분을 사용하지 않을 수 있습니다. 그것은 목적을 무너 뜨릴 것입니다.
그리고 PHP는 점진적으로 더 이상 사용되지 않는 충분한 속도를 얻지 못했습니다. 따라서 좋은 언어에 필요한 명확성과 일관성을 얻을 때까지 시간이 걸릴 것입니다.

개인적으로, 나는 수하물, API 및 모든 것 때문에 PHP를 정말로 싫어합니다.
그러나 Flow3, Symfony, CakePHP 및 Codeigniter와 같은 프레임 워크는 OOP 및 기타 강력한 패러다임을위한 견고한 기반을 제공합니다. ActionScript와 Java의 제한으로 인해 충분한 노력 (PHP 결함 상단의 추상화 계층)으로 인해 PHP가 필적 할 수도 있고 필적 할 수도 있습니다.

요약하면 : PHP의 OOP 기능에는 특별한 문제가 없습니다. 따라서 나쁜 OO 언어 가 아니라고 말할 수 있습니다. 그러나 OOP 기능이 실제로 통합 되지 않고 단순히 포함되어 있기 때문에 PHP에는 특히 잘못된 점이 많이 있습니다 . 따라서 잘못된 OO 언어 라고 주장 할 수 있습니다.


4
호기심으로, 왜 Java가 나쁜 OOP라고 생각하는지 설명 할 수 있습니까?
dkuntz2

2
Ahem .. Actionscript 3에 맞게 답변을 업데이트 할 수 있습니다 . 그 이전에 Actionscript는 OO (ECMA 기반)로 설계되지 않았으며 Actionscript 2조차도 단순히 AS1의 랩퍼였습니다.
데미안 브레히트

1
또한 왜 Java가 나쁜 OOP 언어라고 생각하는지 궁금합니다.
starcorn

2
: @Demian 브레히트는 : 더글러스 크록 포드는 상대적으로 확신 자바 스크립트를 보인다 (모든함으로써 ECMA 스크립트)는 OO이다 javascript.crockford.com/javascript.html
back2dos

2
잘 요약하는 구별 : PHP는 객체 지향이 아닌 객체 가능 합니다.
vartec

11

" handle handle "은 " supports " 와 동일하지 않습니다 . 즉, 코드를 올바르게 구성하면 C "조차도 "OOP를 처리 할 수 ​​있습니다 . 문제는 언어가 단순히 넘어 여부입니다 수 있도록 OOP 프로그램에 가장 자연적인 방법을하여 격려로 OOP를.

내 (필수적으로 제한적인) 경험에서 PHP 5.n 방언은 이것을하지 않습니다. OOP에서 빠져 나와 매우 순전히 절차적인 코드로 들어가기가 너무 쉽습니다. ( 이 이유로 인해 PHP가 나쁜 언어 라고 생각하지 않습니다. PHP가 나쁜 언어 라고 생각하는 데는 여러 가지 이유가 있지만 OOP 지원은 그중 하나가 아닙니다.;))


12
남자, 나는 그것에 대해 몇 년 동안 갈 수 있습니다. 다음은 실패하는 코드 스 니펫입니다 $e = function_that_returns_an_array()[0];.. 문제를 해결하려면 다음을 수행하십시오 $a = function_that_returns_an_array(); $e = $a[0];.. 구문을 통해 함수 호출의 결과를 직접 사용할 수없는 언어가 표시됩니다. 또한 다음 숫자가 10 진수인지 알려주십시오 0246875. (힌트 : 그 어휘 분석기를 구현하는 멍청한 방법을 찾을 수는 없습니다!) PHP는 이런 종류의 어리 석음으로 가득합니다.
저의 올바른 의견

6
@Moon 여기 당신을 위해 약간의 독서가 있습니다 : softwarebashing.org/blog/2009/09/php-the-ultimate-suck and tommorris.org/wiki/PHP%20Sucks 심각한 문제가 있지만 많은 것은 단지 nit입니다 선발. 내가 PHP에 대해 정말로 싫어하는 것은 문화입니다. 그것은 루비와 파이썬과 같은 대안이나 전문적이지 않습니다. 대안은 더 좋으며 최고의 프로그래머를 끌어들입니다. 예를 들어 루비와 파이썬은 모두 대화식 쉘, 괜찮은 기능적 특징, 깔끔한 구문을 가지고 있습니다. 그들은 사용하기 훨씬 더 재미있다. 공유 웹 호스팅 시장 점유율 외에 왜 PHP를 사용 하는가?
Keyo

8
"두 종류의 언어가있다 : 사람들이 불평하는 언어와 아무도 사용하지 않는 언어" Bjarne Stroustrup. 꾀하다.
Sylverdrag


5
Stroustrup은 C ++이 사람들이 나쁜 언어 중 하나라고 화를 내고 있습니다.
저의 정확한 의견 그냥

8

언어의 객체 지향성에 대한 두 가지 정의가 있습니다. 객체 지향이 자체 구문 및 표준 라이브러리에 내장되어있는 방식과 소프트웨어 프로그래머가 작성하는 영향은 무엇입니까?

첫 번째 정의에 따르면 PHP는 목록의 맨 아래에있는 것 같습니다. 사람들은 종종 이것의 증거로 객체가 아닌 문자열과 배열을 인용합니다. 제 생각에는이 정의는 중요하지 않습니다. 정말로 필요한 경우 항상 객체로 포장 할 수 있지만 사람들은 그렇지 않기 때문에 그렇지 않습니다. 일반적으로 코드와의 차이점은로 변경 function(var)됩니다 var.function(). 구문만으로는 비 OOP에서 OOP로 변경되지 않습니다.

두 번째 정의에 관해서는 사람들은 그러한 구조를 강하게 적용하는 언어로도 객체 지향 코드가 열악하게 작성 될 수 있으며, 좋은 객체 지향 코드를 작성하는 사람들은 구문상의 문제에 성가신 것을 제외하고는 언어의 영향을 거의받지 않습니다. 다시 말해서, 내 경험상 나쁜 객체 지향 언어가없고 단지 나쁜 객체 지향 프로그래머가 있습니다. PHP는 다른 언어와 마찬가지로 훌륭합니다.

어쩌면 일부 언어는 객체 지향 프로그래밍 을 배우기에 더 적합 하지만 개발자마다 다를 것이라고 생각합니다. 저에게는 Perl이 OOP를 어떻게 수행했는지에 대한 Larry Wall의 낙타 책을 읽을 때까지 클릭하지 않았습니다. 클래스에 속한 것으로 명시 적으로 참조를 축복 해야하는 것은 실제로 객체의 인스턴스가 클래스에 대한 것이 무엇인지에 대한 요점을 나에게 몰아 넣었습니다. 어떤 사람들은 학습을위한 Java의 모든 객체-항상 접근 방식을 선호합니다. OOP는 구조적 문제이기 때문에 기본 변수, 표현식, 시퀀스, 선택 및 반복을 알고 나면 배우기가 더 쉬워 지므로 OOP를 즉시 방해하지 않는 언어는 교육적으로 유리합니다.

제 아내가 자바로 프로그래밍 클래스를 소개했을 때, 그녀는 끊임없이 좌절 public static void main하고 클래스에 모든 것을 넣었습니다.이 클래스는 아직 이해할 수있는 배경이 없었지만 선생님이 필요하다고 믿기 만했습니다. 나는 그것을 설명하려고 노력했지만 변수에 대해 거의 배우지 않은 사람에게 코드의 다른 부분이 접근하지 못하게하는 이유와 그것을 어떻게 나누는 지 결정하는 방법을 설명하는 것은 매우 어렵습니다. 절차 적 프로그래밍을 배우는 것은 먼저 나쁜 습관을 유발한다고 주장 할 수 있지만, 이해하지 못하는 코드를 복사하여 붙여 넣는 습관은 어떻습니까?


"객체", "언어", "지향 된"및 "프로그래밍"이라는 용어는 동의되지 않았으며 모호하고 상대적이므로 흑백 답변이 불가능합니다. 그러나 "검정"과 "백색"은 다시 합의되지 않으며 그 의미 등은 이해하기 어렵습니다.
Tulains Córdova

5

PHP는 객체 지향 프로그래밍에 나쁘지 않습니다 . 그러나 PHP의 특성상 적절한 객체 지향 소프트웨어 개발에 비해 빠른 해킹 및 수정이 권장 되며, 많은 서적 및 자습서에서는 OOP 개념을 완전히 무시합니다. 그것은 OOP 개념을 잘 지원할 수 있지만, 그것을 적용하는 것은 개발자의 책임입니다. Java 또는 C #과 같은 "진정한"OOP 언어로 할 수있는 대부분의 작업을 PHP에서 수행 할 수 있지만, 해당 언어는 PHP보다 OOP 기술을 더 많이 적용하므로 원하는 경우 절차 스타일을 사용할 수 있습니다.

정확한 인용문을 기억할 수는 없지만 원시 PHP를 새로운 Ruby on Rails를 사용하는 것과 비교 한 누군가의 것이 었습니다. Rails는 좋은 코드를 쉽게 작성하고 나쁜 코드를 작성하는 것을 어렵게 만듭니다. PHP는 잘못된 코드 작성을 쉽게하고 좋은 코드 작성을 어렵게합니다. PHP에 관한 내용은 OOP에 요약되어 있습니다. 좋은 OO 언어가 될 수는 있지만 조금 더 어려워집니다.


4

PHP는 분류

PHP는 BASH 나 Perl과 같은 접착제 언어 일뿐입니다. 그것은 잘하지만 다른 것은 잘하지 않습니다. 심각한 일을 남겨 두십시오. 언어가 설계되지 않았습니다. 다양한 코드를 함께 우연히 (코드 앤 픽스) 방식으로 해킹하여 발전한 것입니다.

컴파일 된 언어

PHP와 달리 Java는 올바르게 엔지니어링 된 컴파일 된 언어입니다. 언어를 정의하는 JSR, EJB, JMS, ESB, Spring, Struts, Hibernate 등과 같은 많은 엔터프라이즈 급 프레임 워크 및 개념이 있습니다.

엔터프라이즈 소프트웨어

엔터프라이즈 시스템 측면에서 Java EE는 목적에 맞는 솔루션 (엔터프라이즈 판) 인 반면, PHP는 적은 자격으로 저렴한 노동력을 고용하여 비용을 절감하려는 회사에서 사용됩니다.

다양한 프레임 워크를 사용하여 PHP를 엔터프라이즈 세그먼트로 끌어 오려는 상당한 노력이있었습니다. 가장 두드러진 것은 Zend Framework 2 입니다. 여기서 근본적인 문제는 PHP의 객체 지향이 아니라 디자인 부족, 강력한 타이핑, 표준 문제에 대한 비표준 솔루션 (모든 것에 대한 해킹 종류) 및 규정 된 아키텍처의 완전한 부족입니다.

소프트웨어 디자인 (건축 토론)

PHP를 사용하면 소프트웨어 설계의 부담은 여전히 ​​매우 열악한 작업을 수행 한 개발자, 즉 임의의 코드를 작성하고 수정하는 아키텍처가 전혀없는 개발자에게 전적으로 달려 있습니다. 보안 및 트랜잭션이 누락되어 개발자가 관심을 가져야합니다. Java에서 하나의 솔루션은 주석이 달린 EJB입니다. 또한 PHP에서 예외 포착을 생략하거나 다양한 오류를 생성하면 아무 일도 일어나지 않는다는 사실을 고려하십시오. 런타임까지입니다. Java를 사용하면 디자인 타임에 직접 경고 및 오류가 발생합니다. 이를 견고성이라고하지만 PHP를 사용하면 계속 꿈을 꿀 수 있습니다.

멀티 스레딩

PHP는 멀티 스레딩을 지원하지 않습니다. 코드는 항상 단일 스레드입니다. 이로 인해 무거운 부하에서 사소한 문제에 대한 성능이 저하됩니다. Java EE를 사용하면 예를 들어 Runnable 인터페이스를 통해 멀티 스레딩이 완벽하게 지원됩니다.

지원 및 표준

또한 배포, 웹 서비스 및 기타 표준을 고려하십시오. Java에는 Oracle, IBM, RedHat, Apache 등의 대기업이 있지만 PHP에는 Zend 만 있습니다.

결론

결론적으로 PHP는 매우 나쁜 객체 지향 언어입니다. 엄밀히 말하면 객체 지향적 인 것이 아니라 OOP가 절차 적 프로그래밍과 혼합되어 버전 5보다 나쁜 하이브리드입니다. BASH와 같은 접착제로 PHP 만 권장하지만 심각한 작업에는 Java EE를 사용합니다.

관련 생각

최신 Zend Framework 2의 주된 거래는 Java EE와 비슷하지만 최소한 원격으로 사용 가능한 패키지, 기능, 도구, 자동화, 오류 검사, 아키텍처, 디자인 및 모두.

내 경험상 Java보다 복잡한 프로젝트에 PHP를 사용하는 것이 더 비쌉니다.

PHP가 Pretty Horrible Programming을 의미 한다는 소문도 있습니다 . 이것들을 확인할 수 있습니다.


3

언어는 OOP를 얼마나 잘 처리합니까? 차라리 OO 방식으로 프로그램을 얼마나 잘 작성할 수 있는지 묻고 싶습니다. 모든 것을 정적 으로 만들면 Java가 취한 모든 종류의 자세에서 코를 thumb 수 있습니다 .
PHP는 OOP를 지원합니다; OO 방식으로 만 쓰도록 강요하지는 않습니다. 얼마나 잘 처리하는지는 객체 지향 방식으로 프로그램을 얼마나 잘 이해하고 작성하는지에 달려 있습니다.


2

PHP는 특성을 지원합니다 ! (5.4에서 시작) . 기본적으로 수평 재사용을 처리 할 수있는 모든 언어는 제 책에서 충분한 OO 언어입니다.


1

우리는 언어를보다 효율적으로 만드는 이유와 그와 같은 이유가 무엇인지 생각해야합니다.

JavaScript는 ECMAScript의 구현으로 브라우저 환경에서 해석 언어 로 실행 됩니다 . 통역 언어로 생각된다는 사실은 그것의 구문 / 행동 디자인에 매우 큰 영향을 미쳤다.

예를 들어 OOP를 따르지 않습니다. 그러나 OO prgrammer는 함수 호이 스팅 과 같은 동작이 매우 혼란 스러울 수 있습니다.

다시 말하지만 C ++, Java, C #과 같은 OO 언어에는 강력한 타이핑 처럼 컴파일러를 효율적으로 만드는 많은 것들이 있습니다 . 그러나 JS는 해석 환경에서 실행되기 때문에 강력한 타이핑을 따르지 않고 느슨한 유형의 언어입니다.

위의 동작상의 차이 외에도, JS에는 Object Literal 표기법 과 같이 C # 프로그래머를 매우 혼란스럽게 할 수 있는 많은 구문상의 차이 가 있습니다. 그러나 C #에는 컴파일 된 언어이지만 일반적으로 OO 코드 스타일이 아니기 때문에 거의 사용되지 않지만 구문과 같은 객체 리터럴도 있습니다.

이제 언어가 좋은지 여부를 결정하는 또 하나의 요점이 있습니다. C ++에서 진화 했습니까? Java, C #은 C ++에서 발전하여 유사한 동작 및 구문을 따르므로 , 큰 커뮤니티는 이러한 동작 및 구문을 유일한 OO 로 인식하고 이러한 유사성을 방해하지 않는 언어는 단순히 OO가 아니라고 생각합니다.

그러나 OO는 매우 추상적 인 개념이라는 것을 잊지 말고 구문 스타일과 관련이 없으며 특정 행동 특성과도 관련이 없습니다.

그리고 PHP는 매우 우수합니다. Java, C ++, C #과 같은 모양과 느낌은 단순히 OO 언어를 저하시키지 않습니다. C ++을 배우고 Java를 배우고 C #을 배웠습니다.

그래서 지금까지 내 머리는 아주 잘되었습니다. 그런 다음 아주 좋은 책인 "Wrox Pro"에서 JS를 배웠습니다. 방금 JS의 동작과 구문 적 구별을 즐겼습니다. 그런 다음 구문과 같은 Object 리터럴이 C #에 있음을 알고 있습니다. 그리고 지금 PHP를 배우면서 두 세계에서 많은 것을 가져 오는 것처럼 느껴집니다.

우리가 실제로해야 할 일은 언어가 OO를 구현하는 동안 구문과 동작 미묘함을 배우는 것입니다. 일단 우리가 그것들을 마스터하면 이것이 더 나은 OO 구현이라고 생각할 수 있습니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.