사실 메소드를 통해 할 수 있는 일이 많습니다. 특히 OO 아이디어와 결합하면 더욱 그렇습니다. 유형은 중요한 정보입니다.
또한 이것이 표준입니다. Java Bean이 바로 많은 프레임워크와 타사 라이브러리(가장 유명한 것은 Spring)에 의존하는 것입니다. 이것 . '자바 제국의 자바빈' 관련 기사를 검색해 보실 수 있습니다.
Setter writing logic과 같은 답변에 강력히 반대하세요. 이러한 코드는 "bean" 레이어(일반적으로 모델 레이어에 해당)에 로직을 작성할 수 없지만 최소한 서비스 레이어(일반적인 3레이어 아키텍처에 따름)에는 작성할 수 있다는 것을 경험이 풍부한 사람들은 매우 오해의 소지가 있습니다. 따라서 이 경우 Setter는 그다지 중요하지 않습니다. 요약하자면 Setter의 논리 작성에 대한 답변은 모두 올바르지 않습니다.
마지막으로 존재는 합리적이다라고 말씀하신 분에 대해 말씀드리겠습니다. '존재는 합리적이다'가 무엇인지 정확히 이해해주셨으면 좋겠습니다.
저를 비난하신 분들께 정식으로 답변드리고 싶습니다——세터에서 논리를 이야기하는 분들도 계시고 에 의지하는 분들도 계십니다. > "잘못된 이론" 다른 사람을 설득하러 오는 사람.
1년 전 처음 커뮤니티에 왔을 때의 이야기를 들려주세요. 비교적 높은 점수를 받은 명인이 쓴 간판을 본 적이 있습니다 쓰레기 SF! 그의 평판 기록을 보니(당시 평판 기록은 GitHub의 커밋 기록과 다소 비슷했지만 1년도 되지 않았습니다), 거의 모든 이슈가 비추천되었습니다 당연합니다 ——악성입니다.
1년 넘게 커뮤니티에 있으면서 가끔 이런 상황을 접했습니다. 하지만 방법은 그다지 나쁘지 않습니다. 마찬가지로 저는 여전히 매우 능숙하다는 것을 인정합니다. 어떤 문제에 대해 확신이 없으면 다른 사람을 오해할 수도 있습니다.
이제 이 상황은 나에게 참을 수 없습니다. 내가 틀렸다면 나도 틀렸고, 아직도 다른 사람을 오해해야 합니다. 다른 분들이 면접에서 이런 기본적인 질문을 하지 못해서 탈락한다면 안타깝겠죠!
마지막으로 모든 분들께 말씀드리고 싶습니다.
악의적인 비방을 받았더라도 단지 제가 싫어졌다는 이유만으로 커뮤니티를 탈퇴하지는 않겠습니다. 더 많은 초보자들이 "끔찍한 초보자"에게 오해를 받지 않도록 더 많은 질문에 대답해야 하기 때문입니다. 마찬가지로 커뮤니티의 질을 유지하기 위해 극도로 오해를 불러일으키는 답변은 절대 놓지 않겠습니다.
믿어지지 않으시면 면접 때 면접관에게 Java Bean의 Setter에서 로직을 자주 작성한다고 말씀해주세요!
지금은 모든 답변을 주의 깊게 살펴봤습니다. 다행히 여기 @kevinz와 같은 사용자가 있어 "끔찍한 초보자"가 그를 밀어내는 것을 방지하기 위해 그에게 투표했습니다.
답변 시 +1점, 추세 추종 시 1점만 부여됩니다. 밟히면 2점. 그리고 이런 답변이 점점 많아지면 커뮤니티의 질은 점점 더 나빠질 것입니다. 1W라는 평판을 얻었다고 해도 채팅이나 소통할 때 자랑스럽게 말하면 다른 사람들은 그냥 비웃을 것입니다. 🎜> 커뮤니티의 질이 높지 않고, 모두 트렌드를 따르고 있다는 것입니다.
언어마다 철학이 다릅니다. Java는 완전한 객체 지향적이며 코딩 시 코드의 높은 유연성과 확장성을 촉진합니다. Go 같은 언어는 코드의 궁극적인 단순성을 옹호하므로 struct을 다음과 같이 정의하면 됩니다.
으아아아
그러나 Java에서는 사양을 준수하고 javabean에 대한 get/set 메서드를 정의해야 합니다. 예를 들어 액세스할 때 사양이 제공하는 이점을 누리려면 사양을 준수해야 하기 때문입니다. 타사 라이브러리, reflect을 사용하여 javabean을 동작시킬 때 대부분 get/set 방식을 사용합니다. 현재 javabean에 get/set 메서드가 없으면 분명히 이 라이브러리를 사용할 수 없습니다.
개인 경험에 따르면 코드의 유연성과 확장성보다 코드의 단순성이 더 중요합니다. 따라서 java과 같은 툴킷이 lombok에도 나타나므로 코드를 매우 단순화할 수 있습니다.
위 분들이 너무 많이 말씀하셨는데 한 가지를 놓치셨네요. 메서드는 다형성이지만 속성은 다형성이 아닙니다 이것을 어떻게 이해하시나요? 예를 들어 Person은 상위 클래스이고 Man은 하위 클래스이며 상위 클래스와 하위 클래스 모두 Name 속성을 가지며(매우 드물기는 하지만) 상위 클래스와 하위 클래스의 이름은 모두 공개입니다. 다음 코드를 참조하세요:
좋은 질문이네요! 번거로운 setter와 getter를 사용하는 대신 이 비공개 필드를 공개로 만드는 것은 어떨까요? 여러 가지 이유가 있습니다:
고객의 의견을 절대 믿지 마세요
이 클래스를 가정해 보겠습니다.
으아악
다음으로 바꾸면 더 좋겠죠?
으아악
수정이 용이함
이제 속도가 0~40 사이여야 한다고 가정해 보겠습니다. getter 및 setter가 없으면 모든 코드를 다시 작성해야 하며 한 시간 이내에 완료하는 것은 불가능합니다. 이 setter를 사용하면 간단합니다. 1분 내에 완료되지 않으면 프로그래머가 setter의 논리를 변경하면 됩니다.
장단점은 상대적인 것으로 이해됩니다. "작은 프로그램"의 경우 단점이 없습니다. 왜냐하면 현재로서는 귀하와 다른 관리자가 매개변수 값의 변경 사항을 명확하게 보고 제어할 수 있기 때문입니다. public 프로그램의 모든 구석구석을 제어하고 심지어 "단점보다 장점이 더 많습니다". setter&getter이 없으면 코드 양이 많이 줄어들기 때문입니다. 하지만 프로그램이 특정 규모로 "큰" 경우 프로그램의 유지 관리 가능성을 고려해야 합니까? 예를 들어 a.money 및 a.getMoney()가 어느 날 갑자기 a.action에 影响money 요소를 추가하면 어떻게 해야 합니까? money의 모든 호출자가 直接a.money就不那么可靠 요소 영향 규칙을 알 수 있는지 확인하세요. 프로그램 작성의 관점에서 볼 때 메소드를 더 작성해야 한다는 점을 대학교 컴퓨터 프로그래밍 선생님께서 가르쳐 주셨습니다. 객체지향 관점에서 객체는 객체를 조작하기 위한 메소드를 제공해야 하므로 여전히 메소드이고 setter和getter는 이러한 아이디어를 구현합니다. Java 기능 측면에서 setter和getter는 캡슐화 기능 아이디어를 구현한 것입니다. 위의 예에서 다른 머니 사용자가 money을 호출해야 할 때 호출자는 거기에 액션 팩터가 있다는 것을 알 필요가 없습니다. getMoney()올바른 money만 얻으면 됩니다. 변수는 비공개이며 변수 운영을 위한 공개 메소드를 제공합니다. 이때는 장점이 단점보다 더 큽니다. 재능도 없고 지식도 없는 이들은 한 집안에서 말하고, 부적절한 것을 이해하면 비판과 시정을 받아들인다.
추가로, setter&getter의 논리 문제에 관해서는 "할 수 있는가"라는 질문보다는 "해야 하는가"에 대한 질문인 것 같아요. 전자의 경우 장단점을 잘 따져봐야 합니다. 프로그램 논리와 위험 제어가 양호하면 작성하는 것이 편리할 것입니다! 이런 훌륭한 프레임워크는 이런 방식으로 작성되지 않으며, 장단점(확장 등)을 기반으로 논리 처리 계층에 넣는 것이 정상입니다.
하지만 실제로는 읽기 전용 필드 등 getter setter를 사용해야 하는 필드(필드, 속성)가 있으므로 1⃣️ 전체 코드의 일관성을 위해 모든 getter 및 setter를 사용하는 것이 좋습니다. . 2⃣️, ide의 도움을 사용하면 실제로 완료하는 데 많은 노력이 필요하지 않습니다. 3⃣️ 이것은 기본적으로 규범적인 것이므로 꼭 해야 하는지 생각할 필요는 없습니다. 4⃣️, 어떤 경우에는 getter와 setter가 실제로 필요하지 않습니다. 여기에 있는 데이터가 매우 간단하다고 확신한다면 직접 공개하세요.
다른 질문에 대해
비공개 필드가 getter 및 setter를 제공하는 경우 공개로 간주되므로 일관성이 없으므로 공개
를 사용해야 합니다.
목적이 무엇인가요
우선 비공개 필드에는 getter와 setter만 있을 수 있으며 이는 당연히 공개로 간주되지 않습니다. 세터와 게터가 모두 있다면 생각보다 간단하지 않습니다. 직접 작성한 getter setter에는 처리 로직이 없기 때문에 이것을 고려
으아아아
이 예와 동일한 요구 사항이 있는 경우 이름을 저장할 때 추가 공백을 제거해야 합니다. (그런데 위 코드의 구문이 정확하다고는 보장할 수 없습니다. 저는 Java를 오랫동안 작성하지 않았습니다.
오픈 필드 호출이 더 편하냐는 질문에, 사실 말씀하신 파이썬의 오픈 필드는 오픈 필드가 아니죠? 실제 저장 필드는 _name이고, getter와 setter는 name입니다. 이는 Java와 구문만 다를 뿐 본질은 동일합니다.
여기에는 캡슐화 및 제어 문제가 있습니다. goodDog.size 속성에 직접 액세스한다고 가정해 보겠습니다. 어느 날 갑자기 각 크기 또는 특정 크기에 대해 필터링해야 할 경우 어떻게 해야 합니까? 그런 다음 goodDog.size가 나타나는 모든 곳에 필터링 메커니즘을 추가해야 합니다. getSize() 메소드를 사용하는 경우 이 메소드에서 필터링하면 괜찮을 것입니다. 사실, 전반적인 아이디어는 객체지향 관점에서 일을 하는 것입니다. 원하는 것이 있으면 저에게 말씀해 주시면 제가 집에 가서 가져다 드리지만 직접 집에 가서 가져갈 수는 없습니다. 만약 당신이 우리 집에 대해 잘 알지 못한다면, 우리 가족이 엉망이 된다면 어떻게 해야 할까요?
goodDog .size=12를 직접 설정하면 안전하지 않은데, size 값이 10보다 작으면 어떻게 되나요? 이런 일이 발생하지 않도록 하려면 모든 속성을 확인해야 하나요? set 메소드 중에 값을 균일하게 변경하고 범위를 제어하므로 나중에 요구 사항이 변경될 때 goodDog .size를 사용하기 위해 전 세계 곳곳을 찾을 필요가 없습니다
매개변수가 있는 메소드와 매개변수가 없는 메소드는 메소드의 구체적인 목적에 따라 다릅니다. set 메소드와 get 메소드는 객체지향 프로그래밍의 캡슐화 아이디어를 반영하기 위한 것이며, 멤버 변수는 비공개로 설정되며 수정만 가능합니다. .
프로그램의 보안을 보장하기 위해 특정한 방법을 통해 접근합니다.
Java Bean이나 Hibernate와 같은 위의 대답도 있습니다. 속성을 제거할 때 정의한 속성 크기를 사용하지 않고 getSize를 사용하고 get 메소드의 소문자 S를 제거하여 크기를 가져옵니다.
그래도 이해가 안 된다면 다음을 기억하세요. 존재는 합당하다. 어느 날 특정 코드를 작성하다 보면 갑자기 깨닫게 될 것이다.
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
사실 메소드를 통해 할 수 있는 일이 많습니다. 특히 OO 아이디어와 결합하면 더욱 그렇습니다. 유형은 중요한 정보입니다.
또한 이것이 표준입니다. Java Bean이 바로 많은 프레임워크와 타사 라이브러리(가장 유명한 것은 Spring)에 의존하는 것입니다. 이것 . '자바 제국의 자바빈' 관련 기사를 검색해 보실 수 있습니다.
Setter writing logic과 같은 답변에 강력히 반대하세요. 이러한 코드는
"bean"레이어(일반적으로 모델 레이어에 해당)에 로직을 작성할 수 없지만 최소한 서비스 레이어(일반적인 3레이어 아키텍처에 따름)에는 작성할 수 있다는 것을 경험이 풍부한 사람들은 매우 오해의 소지가 있습니다. 따라서 이 경우 Setter는 그다지 중요하지 않습니다. 요약하자면 Setter의 논리 작성에 대한 답변은 모두 올바르지 않습니다.마지막으로 존재는 합리적이다라고 말씀하신 분에 대해 말씀드리겠습니다. '존재는 합리적이다'가 무엇인지 정확히 이해해주셨으면 좋겠습니다.
저를 비난하신 분들께 정식으로 답변드리고 싶습니다——세터에서 논리를 이야기하는 분들도 계시고 에 의지하는 분들도 계십니다. > "잘못된 이론" 다른 사람을 설득하러 오는 사람.
1년 전 처음 커뮤니티에 왔을 때의 이야기를 들려주세요. 비교적 높은 점수를 받은 명인이 쓴 간판을 본 적이 있습니다 쓰레기 SF! 그의 평판 기록을 보니(당시 평판 기록은 GitHub의 커밋 기록과 다소 비슷했지만 1년도 되지 않았습니다), 거의 모든 이슈가 비추천되었습니다 당연합니다 ——악성입니다.
1년 넘게 커뮤니티에 있으면서 가끔 이런 상황을 접했습니다. 하지만 방법은 그다지 나쁘지 않습니다. 마찬가지로 저는 여전히 매우 능숙하다는 것을 인정합니다. 어떤 문제에 대해 확신이 없으면 다른 사람을 오해할 수도 있습니다.
이제 이 상황은 나에게 참을 수 없습니다. 내가 틀렸다면 나도 틀렸고, 아직도 다른 사람을 오해해야 합니다. 다른 분들이 면접에서 이런 기본적인 질문을 하지 못해서 탈락한다면 안타깝겠죠!
마지막으로 모든 분들께 말씀드리고 싶습니다.
악의적인 비방을 받았더라도 단지 제가 싫어졌다는 이유만으로 커뮤니티를 탈퇴하지는 않겠습니다. 더 많은 초보자들이 "끔찍한 초보자"에게 오해를 받지 않도록 더 많은 질문에 대답해야 하기 때문입니다. 마찬가지로 커뮤니티의 질을 유지하기 위해 극도로 오해를 불러일으키는 답변은 절대 놓지 않겠습니다.
믿어지지 않으시면 면접 때 면접관에게 Java Bean의 Setter에서 로직을 자주 작성한다고 말씀해주세요!
지금은 모든 답변을 주의 깊게 살펴봤습니다. 다행히 여기 @kevinz와 같은 사용자가 있어 "끔찍한 초보자"가 그를 밀어내는 것을 방지하기 위해 그에게 투표했습니다.
답변 시 +1점, 추세 추종 시 1점만 부여됩니다. 밟히면 2점. 그리고 이런 답변이 점점 많아지면 커뮤니티의 질은 점점 더 나빠질 것입니다. 1W라는 평판을 얻었다고 해도 채팅이나 소통할 때 자랑스럽게 말하면 다른 사람들은 그냥 비웃을 것입니다. 🎜> 커뮤니티의 질이 높지 않고, 모두 트렌드를 따르고 있다는 것입니다.
언어마다 철학이 다릅니다. Java는 완전한 객체 지향적이며 코딩 시 코드의 높은 유연성과 확장성을 촉진합니다.
으아아아Go같은 언어는 코드의 궁극적인 단순성을 옹호하므로struct을 다음과 같이 정의하면 됩니다.그러나
Java에서는 사양을 준수하고javabean에 대한get/set메서드를 정의해야 합니다. 예를 들어 액세스할 때 사양이 제공하는 이점을 누리려면 사양을 준수해야 하기 때문입니다. 타사 라이브러리,reflect을 사용하여javabean을 동작시킬 때 대부분get/set방식을 사용합니다. 현재javabean에get/set메서드가 없으면 분명히 이 라이브러리를 사용할 수 없습니다.개인 경험에 따르면 코드의 유연성과 확장성보다 코드의 단순성이 더 중요합니다. 따라서
java과 같은 툴킷이lombok에도 나타나므로 코드를 매우 단순화할 수 있습니다.위 분들이 너무 많이 말씀하셨는데 한 가지를 놓치셨네요. 메서드는 다형성이지만 속성은 다형성이 아닙니다 이것을 어떻게 이해하시나요? 예를 들어 Person은 상위 클래스이고 Man은 하위 클래스이며 상위 클래스와 하위 클래스 모두 Name 속성을 가지며(매우 드물기는 하지만) 상위 클래스와 하위 클래스의 이름은 모두 공개입니다. 다음 코드를 참조하세요:
으아아아답변은
을 출력합니다.person
null
좋은 질문이네요! 번거로운 setter와 getter를 사용하는 대신 이 비공개 필드를 공개로 만드는 것은 어떨까요? 여러 가지 이유가 있습니다:
고객의 의견을 절대 믿지 마세요
이 클래스를 가정해 보겠습니다.
으아악다음으로 바꾸면 더 좋겠죠?
으아악수정이 용이함
이제 속도가 0~40 사이여야 한다고 가정해 보겠습니다. getter 및 setter가 없으면 모든 코드를 다시 작성해야 하며 한 시간 이내에 완료하는 것은 불가능합니다. 이 setter를 사용하면 간단합니다. 1분 내에 완료되지 않으면 프로그래머가 setter의 논리를 변경하면 됩니다.
으아악장단점은 상대적인 것으로 이해됩니다. "작은 프로그램"의 경우 단점이 없습니다. 왜냐하면 현재로서는 귀하와 다른 관리자가 매개변수 값의 변경 사항을 명확하게 보고 제어할 수 있기 때문입니다.
public프로그램의 모든 구석구석을 제어하고 심지어 "단점보다 장점이 더 많습니다".setter&getter이 없으면 코드 양이 많이 줄어들기 때문입니다. 하지만 프로그램이 특정 규모로 "큰" 경우 프로그램의 유지 관리 가능성을 고려해야 합니까? 예를 들어a.money및a.getMoney()가 어느 날 갑자기a.action에影响money요소를 추가하면 어떻게 해야 합니까?money의 모든 호출자가直接a.money就不那么可靠요소 영향 규칙을 알 수 있는지 확인하세요. 프로그램 작성의 관점에서 볼 때 메소드를 더 작성해야 한다는 점을 대학교 컴퓨터 프로그래밍 선생님께서 가르쳐 주셨습니다. 객체지향 관점에서 객체는 객체를 조작하기 위한 메소드를 제공해야 하므로 여전히 메소드이고setter和getter는 이러한 아이디어를 구현합니다. Java 기능 측면에서setter和getter는 캡슐화 기능 아이디어를 구현한 것입니다. 위의 예에서 다른 머니 사용자가money을 호출해야 할 때 호출자는 거기에 액션 팩터가 있다는 것을 알 필요가 없습니다.getMoney()올바른money만 얻으면 됩니다. 변수는 비공개이며 변수 운영을 위한 공개 메소드를 제공합니다. 이때는 장점이 단점보다 더 큽니다. 재능도 없고 지식도 없는 이들은 한 집안에서 말하고, 부적절한 것을 이해하면 비판과 시정을 받아들인다.추가로, setter&getter의 논리 문제에 관해서는 "할 수 있는가"라는 질문보다는 "해야 하는가"에 대한 질문인 것 같아요. 전자의 경우 장단점을 잘 따져봐야 합니다. 프로그램 논리와 위험 제어가 양호하면 작성하는 것이 편리할 것입니다! 이런 훌륭한 프레임워크는 이런 방식으로 작성되지 않으며, 장단점(확장 등)을 기반으로 논리 처리 계층에 넣는 것이 정상입니다.
우선 방법의 번역은 방법입니다.
그럼 혼란을 이해하도록 하겠습니다
사실 이걸 안 하는 가장 큰 이유는 너무 번거롭기 때문이에요.
하지만 실제로는 읽기 전용 필드 등 getter setter를 사용해야 하는 필드(필드, 속성)가 있으므로 1⃣️ 전체 코드의 일관성을 위해 모든 getter 및 setter를 사용하는 것이 좋습니다. .
2⃣️, ide의 도움을 사용하면 실제로 완료하는 데 많은 노력이 필요하지 않습니다.
3⃣️ 이것은 기본적으로 규범적인 것이므로 꼭 해야 하는지 생각할 필요는 없습니다.
4⃣️, 어떤 경우에는 getter와 setter가 실제로 필요하지 않습니다. 여기에 있는 데이터가 매우 간단하다고 확신한다면 직접 공개하세요.
다른 질문에 대해
우선 비공개 필드에는 getter와 setter만 있을 수 있으며 이는 당연히 공개로 간주되지 않습니다. 세터와 게터가 모두 있다면 생각보다 간단하지 않습니다. 직접 작성한 getter setter에는 처리 로직이 없기 때문에 이것을 고려
으아아아이 예와 동일한 요구 사항이 있는 경우 이름을 저장할 때 추가 공백을 제거해야 합니다. (그런데 위 코드의 구문이 정확하다고는 보장할 수 없습니다. 저는 Java를 오랫동안 작성하지 않았습니다.
오픈 필드 호출이 더 편하냐는 질문에, 사실 말씀하신 파이썬의 오픈 필드는 오픈 필드가 아니죠? 실제 저장 필드는 _name이고, getter와 setter는 name입니다. 이는 Java와 구문만 다를 뿐 본질은 동일합니다.
게터와 세터의 이점을 보여주기 위해 두 개의 코드를 더 추가하겠습니다.
으아아아또 다른 예
으아아아으아아아
여기에는 캡슐화 및 제어 문제가 있습니다. goodDog.size 속성에 직접 액세스한다고 가정해 보겠습니다. 어느 날 갑자기 각 크기 또는 특정 크기에 대해 필터링해야 할 경우 어떻게 해야 합니까? 그런 다음 goodDog.size가 나타나는 모든 곳에 필터링 메커니즘을 추가해야 합니다. getSize() 메소드를 사용하는 경우 이 메소드에서 필터링하면 괜찮을 것입니다. 사실, 전반적인 아이디어는 객체지향 관점에서 일을 하는 것입니다. 원하는 것이 있으면 저에게 말씀해 주시면 제가 집에 가서 가져다 드리지만 직접 집에 가서 가져갈 수는 없습니다. 만약 당신이 우리 집에 대해 잘 알지 못한다면, 우리 가족이 엉망이 된다면 어떻게 해야 할까요?
goodDog .size=12를 직접 설정하면 안전하지 않은데, size 값이 10보다 작으면 어떻게 되나요?
이런 일이 발생하지 않도록 하려면 모든 속성을 확인해야 하나요? set 메소드 중에 값을 균일하게 변경하고 범위를 제어하므로 나중에 요구 사항이 변경될 때 goodDog .size를 사용하기 위해 전 세계 곳곳을 찾을 필요가 없습니다
매개변수가 있는 메소드와 매개변수가 없는 메소드는 메소드의 구체적인 목적에 따라 다릅니다. set 메소드와 get 메소드는 객체지향 프로그래밍의 캡슐화 아이디어를 반영하기 위한 것이며, 멤버 변수는 비공개로 설정되며 수정만 가능합니다. .
프로그램의 보안을 보장하기 위해 특정한 방법을 통해 접근합니다.Java Bean이나 Hibernate와 같은 위의 대답도 있습니다. 속성을 제거할 때 정의한 속성 크기를 사용하지 않고 getSize를 사용하고 get 메소드의 소문자 S를 제거하여 크기를 가져옵니다.
그래도 이해가 안 된다면 다음을 기억하세요. 존재는 합당하다. 어느 날 특정 코드를 작성하다 보면 갑자기 깨닫게 될 것이다.
퍼블릭은 간단한 시나리오에서 사용할 수 있습니다. 세터와 게터는 주로 외부 세계와 폐쇄되어 있습니다. 세터와 게터에 일부 통합 처리를 추가할 수 있으며 이는 재구성에도 편리합니다.
가시성을 숨기기 위해 추가하고 싶은 점은
setter및getter메서드가 반드시 값에 직접 액세스할 필요는 없으며 일부 처리 논리도 추가할 수 있다는 것입니다.