2012-04-20 6 views
7

변수 캡슐화, 설정/가져 오기 방법은 모범 사례이지만 어쨌든 변수를 사용할 예정이 아니라면 변수 공개를 선언 할 수있는 이유는 무엇입니까? 변수를 항상 공개적으로 공개 할 기회가 없으면 변수가 항상 비공개 였다면 읽는 튜토리얼의 모든 것이 set/get 메서드로 캡슐화되어야하므로 말하면 좋을까요? PHP OOP에서 공용 변수에 대한 유효한 유스 케이스가 있습니까?PHP OOP에서 공용 변수를 사용하는 데 유효한 유스 케이스가 있습니까?

+0

클래스의 보호 된 변수 (예 : 상속/덮어 쓰기)에 대한 사용 사례가 있지만 공용 변수에 대해서는 알지 못합니다.PHP 5 var에서 public으로 해석되는 클래스에서 PHP 4 var $ var 선언으로 인한 것일 수도 있습니다. – Hajo

+2

간단한 답 : getters와 setter를 사용하지 않는 ** (원하지 않는) 다양한 완벽하게 유효한 이유가 있으므로 단순히 공용 변수에 액세스 할 수 있습니다. – CodeCaster

+0

대부분의 경우 동적 인 oop의 @CodeCaster는 나쁜 디자인을 보여줍니다. – Hajo

답변

8

실제로는 다른 방법 일뿐입니다. 이론적으로 getters/setters는 입니다.입니다. 속성은 메서드가 동작을 정의하는 개체의 상태를 정의합니다. Getters/Setters는 속성에 대한 읽기 및 쓰기 액세스를 가로 채기 만하지만 의미 의미를 완전히 깨뜨립니다. 이제 개체의 상태를 읽는 것은 개체의 동작입니다. 속성은 속성처럼 보이도록하려면

다시 길 : https://wiki.php.net/rfc/propertygetsetsyntax

1

설정에 RFC가/가져 오기 방법은 모범 사례가 있지만 우리가 변수 공개를 선언 할 수있는 기회를 가질 않는 이유가 있다면 어쨌든 사용하지 않아도 되나요?

모범 사례는 동일하지 않습니다. 언어는 다양한 유스 케이스에 대해 서로 다른 도구를 제공해야하며 일관성을 가져야합니다.

PHP 개체는 항상 공개 멤버를 지원하며 차별화 된 공개가 도입되었을 때 이전 버전과의 호환성을 위해 공개 멤버는 매우 유용합니다. 변수는 내가 읽은 모든 튜토리얼들이/방법을 얻을 세트로 캡슐화되어야한다 말합니다 때문에 그들이 공공 만드는 어떤 기회 기본적으로 항상 개인 인 경우

그것은 더 좋았을까요?

그 질문에 구체적으로 대답 할 수 없기 때문에 너무 주관적이며 다른 답변을 초래할 수있는 유스 케이스가 너무 많습니다.

적어도 PHP OOP에서 공용 변수에 대한 유효한 유스 케이스가 있습니까?

역 호환성으로 시작하십시오. 코드를 리팩토링 할 수 없지만 항상 코드를 완전히 다시 작성해야하는 경우 이는 매우 비쌉니다.

-1

여기가 .. 이것은 실제 이메일 API 클래스 인 CakePHP EmailComponent입니다. 당신은 단지에 필요한이 클래스를 사용하는 몇 가지 속성을 "설정"그럼 그냥 send()이이 클래스 내부의 개인 특성과 기능이 많이이지만 개인의 사실

$this->Email->to = '[email protected]'; 
$this->Email->from = '[email protected]'; 
$this->Email->title = 'xxx'; 
$this->Email->msg = 'blabla..'; 
$this->Email->send(); 

.

클래스은 (단독) 무언가를해야합니다. 캡슐화은 사람들이 그 일을하기 위해 사용하는 것만을 게시하고 내부에는 기술/인프라를 개인으로 유지하는 것입니다.

관련 문제