게터/세터. 사악한. 그리고 기간

Egor Bugaenko의 기사 2014년 9월 19일 | Posted in: Core Java 이 오래된 논쟁은 Allen Holub가 2003년에 쓴 유명한 기사인 왜 getter 및 setter 메소드가 악한가 - getter/setter는 안티 패턴이며 우리가 이를 피해야 하는가, 아니면 우리가 하는 것에서 시작되었습니다. 객체지향 프로그래밍에 꼭 필요한? 이 토론에 2센트를 추가하겠습니다. 아래 텍스트의 요점은 다음과 같습니다. getter와 setter는 나쁜 습관이므로 이를 사용하는 사람들에게는 변명의 여지가 없습니다. 그러나 오해를 피하기 위해 가능한 한 get/set의 사용을 피해야 한다고 제안하는 것은 아닙니다. 아니요. 나는 당신이 그들을 당신의 코드 근처에 두지 않았다는 것을 말하고 있습니다 . 이 진술에 대해 어떻게 생각하시나요? 주목할 가치가 있나요? 15년 동안 get/set 패턴을 사용해 오셨고 존경받는 Java 설계자이신가요? 그리고 당신은 낯선 사람의 말도 안되는 소리를 듣고 싶지도 않습니까? 글쎄요... 당신의 감정을 이해합니다. David West의 책 "Object Thinking"을 접하기 전까지 나도 같은 느낌을 받았습니다. 이 책은 내가 읽은 객체 지향 프로그래밍에 관한 최고의 책입니다. 그러니 제발. 진정하고 내가 설명하려는 내용을 이해하려고 노력하십시오. 논쟁의 주제 객체 지향 세계에서는 "접속자"(getter 및 setter의 또 다른 이름)에 대한 몇 가지 주장이 있습니다. 그리고 그것들은 모두 매우 정확한 주장입니다. 그것들을 간단히 살펴보겠습니다. 묻고, 말하지 말고 : Allen Holub은 "일을 수행하는 데 필요한 정보를 묻지 마십시오. 해당 정보를 가지고 있는 기관에 '물어보세요'라고 말합니다." 위반된 캡슐화 원리 : 객체는 setter를 통해 객체에 모든 데이터를 삽입할 수 있기 때문에 다른 객체에 의해 분리될 수 있습니다. 누구나 해당 상태를 변경할 수 있기 때문에 객체는 자신의 상태를 충분히 안전하게 캡슐화할 수 없습니다. 구현 세부 사항 공개 : 다른 객체에서 하나의 객체를 얻을 수 있다면 첫 번째 객체의 구현 세부 사항에 너무 많이 의존하고 있는 것입니다. 내일 변경되면(예: 결과 유형) 코드를 변경해야 합니다. 위의 모든 정당화는 확실히 의미가 있지만 가장 중요한 점을 놓치고 있습니다. 기본적인 오해 대부분의 프로그래머는 객체가 메소드가 있는 데이터 구조라고 믿습니다. Bozhidar Bozhanov의 기사를 인용합니다. 게터와 세터는 사악하지 않습니다.. 그러나 getter 및 setter가 생성되는 대부분의 개체에는 단순히 데이터가 포함되어 있습니다. 이 오해는 엄청난 오해의 결과입니다! 객체는 "단지 데이터를 저장"하는 것이 아닙니다. 객체는 메소드가 첨부된 데이터 구조가 아닙니다. 이러한 "데이터 저장" 개념은 객체 지향 프로그래밍 및 절차적 언어, 특히 C 및 COBOL에서 나왔습니다. 다시 반복하겠습니다. 객체는 단순히 데이터 요소와 이를 조작하는 함수의 모음이 아닙니다. 개체는 데이터 개체가 아닙니다. 그럼 어쩌지? 공과 개 진정한 객체 지향 프로그래밍에서 객체는 여러분과 저처럼 살아있는 존재입니다. 그들은 자신의 행동, 속성 및 수명주기를 가진 살아있는 유기체입니다. 살아있는 유기체가 세터를 가질 수 있습니까? 개에게 공을 부착(“세트”)할 수 있나요? 생각하지 마세요. 하지만 이것이 바로 아래 코드가 수행하는 작업입니다.

Dog dog = new Dog();
dog.setBall(new Ball());

그럼 어때요? 개에게서 공을 빼낼 수 있나요? 글쎄, 당신이 할 수 있다고 가정 해 봅시다. 만약에 그녀가 그것을 먹었고 당신이 그녀에게 수술을 했다면. 이 경우, 그렇습니다. 당신은 개에게서 공을 얻을(“얻을”) 수 있을 것입니다. 이것이 바로 제가 말하는 것입니다:

Dog dog = new Dog();
Ball ball = dog.getBall();

아니면 훨씬 더 우스꽝스러운 예도 있습니다.

Dog dog = new Dog();
dog.setWeight("23kg");

이것을 실생활에서 상상할 수 있습니까? 매일 글을 쓰는 것 같나요? 그렇다면 당신은 절차적 프로그래머입니다. 그냥 인정하세요. 다음은 David West가 자신의 책 30페이지에서 말한 내용입니다. 성공적인 절차적 개발자를 성공적인 객관적인 개발자로 변화시키는 첫 번째 단계는 뇌엽 절개술입니다. 뇌엽 절개술이 필요합니까? 꼭 필요했는데, 웨스트의 책 '객체사고'를 읽다가 얻었습니다. 객관적인 사고 객체처럼 생각하기 시작하면 즉시 이러한 방법의 이름을 바꿀 것입니다. 얻을 수 있는 혜택은 다음과 같습니다.

Dog dog = new Dog();
dog.take(new Ball());
Ball ball = dog.give();

이제 우리는 개를 우리에게서 공을 가져갈 수 있고 요청하면 돌려줄 수 있는 실제 동물로 대합니다. 혹시라도 개가 NULL을 반환할 수 없다는 점에 유의하세요. 개들은 NULL이 무엇인지 모릅니다! 객관적인 사고(생각)는 코드에서 NULL 참조를 즉시 제거합니다. 완다라고 불리는 물고기(1988) - 찰스 크라이튼 또한 객관적인 사고는 우리 예의 "개 무게"와 같은 객체의 불변성을 초래합니다. 다음과 같이 코드를 다시 작성합니다.

Dog dog = new Dog("23kg");
int weight = dog.weight();

개는 외부인이 자신의 몸무게, 크기, 이름 등을 바꾸는 것을 허용하지 않는 불변의 살아있는 유기체입니다. 그녀는 요청 시 체중이나 이름을 "말"할 수 있습니다. 객체의 특정 "내부" 속성에 대한 쿼리를 노출하는 공개 메서드에는 아무런 문제가 없습니다. 그러나 이러한 메서드는 "getter"가 아니며 "get" 접두사를 받아서는 안 됩니다. 우리는 개에게서 "나오지" 않습니다. 우리는 그녀의 이름을 모릅니다. 우리는 그녀에게 그녀의 이름을 말해달라고 요청합니다. 차이점이 보이나요? 우리는 여기서 의미론에 대해서도 이야기하지 않습니다. 우리는 프로그래밍에 대한 절차적 접근 방식을 객체 지향 접근 방식과 차별화합니다. 절차적 프로그래밍에서는 데이터로 작업하고, 조작하고, 가져오고 설정하고 필요한 경우 삭제합니다. 우리가 책임을 지며, 데이터는 단지 수동적인 구성요소일 뿐입니다. 개는 우리에게 아무 것도 아닙니다. 개는 단순히 "데이터를 포함하고 있습니다." 그녀에게는 자신의 삶이 없습니다. 우리는 필요한 모든 것을 자유롭게 가져오고(가져오고) 여기에 데이터를 넣을(설정) 수 있습니다. 이것이 C, COBOL, Pascal 및 기타 절차적 언어가 작동하는 방식입니다. 그리고 객체 지향 세계에서는 상황이 완전히 반대입니다. 여기서 우리는 원하는 경우 사물을 생년월일과 사망 순간, 개성과 습관을 지닌 살아있는 유기체로 취급합니다. 우리는 개에게 데이터(예: 체중)를 요청하면 그 정보를 우리에게 반환할 수 있습니다. 그러나 개가 활동적인 구성 요소라는 것을 항상 기억하십시오. 그녀는 요청 후에 어떤 일이 일어날지 결정합니다. 이것이 바로 객체의 메소드가 set 또는 get으로 시작하는 것이 절대적으로 잘못된 이유입니다. 그리고 이것은 많은 사람들이 생각하는 것처럼 캡슐화 위반에 관한 것도 아닙니다. 이는 객체처럼 생각하거나 여전히 Java 구문을 사용하여 COBOL을 작성하고 있다는 사실에 관한 것입니다. 추신 . 그리고 그렇습니다. "JavaBeans, JPA, JAXB 및 get/set에 의존하는 기타 많은 Java API는 어떻습니까?"라고 물을 수도 있습니다. 접근자를 더 쉽게 생성할 수 있게 해주는 Ruby의 내장 함수는 어떻습니까? 글쎄요, 제가 뭐라고 말해야 할까요... 당신은 운이 좋지 않습니다. 실제 객체의 놀라운 세계를 이해하고 포용하는 것보다 절차적 COBOL의 원시 세계에 머무르는 것이 훨씬 쉽습니다. 추신 _ 예, setter를 통해 종속성을 삽입하는 것도 끔찍한 안티 패턴입니다. 하지만 이에 대한 자세한 내용은 다음 게시물에서 다루겠습니다! 원본 기사