위와 같은 클래스를 보면 클래스의 메서드가 모두 public 제어자로 되어있음
이말인 즉슨, 외부에서 클래스의 객체를 사용하는 코드는 저 3개의 메서드에 의존하게 된다는 소리고
만약 Process 클래스를 수정이라도 한다면, 의존관계 때문에 방대한 코드 수정이 필요하게 된다는 뜻
하지만 이렇게 메서드를 private 제어자로 은닉하고
public 공개 메서드로 감싸면, 은닉 메서드의 수정이 이루어져도 방대한 코드베이스 수정이 필요없고
어떤 메서드를 우선 살펴야 하는지 알수있으며
개별 메서드간의 호출순서를 관리할 수 있다
이것이 바로 캡슐화
이렇게 객체간 의존성은 오직 캡슐화를 통한 공개 메서드를 통해 이루어지는데
이때 인터페이스와 연동시키면 업캐스팅으로 인한 멤버 제한 요소도 사라지면서
실질적 클래스 간의 의존관계도 해소가 가능하다
맞나?
코드는 Inpa Dev 블로그 펌
맞는듯? 이런거 챗지피티한테 물어보면 아아주 잘 설명해줌
아 나도 원래 지피티랑 주거니받거니 하면서 배웠는데 Inpa Dev 블로그보니까 진짜 개찰떡으로 이해잘가는 예제가 올라와있길래 이 예제보니까 내가 캡슐화를 좀 다르게 이해한거같더라고ㅋㅋ 여튼 맞으니 다행
캡슐화가 뭐 거창한게 아니라 그냥 외부에서 클래스 멤버에 직접적인 접근을 막는거임
ㅇㅇ 맞는 것 같음. 난 솔직히 이론은 잘 모르겠는데, 경험상 외부에서 호출할 수 있는 public 메서드가 적어질수록, 그러면서도 메서드의 역할이 확실히 나눠져 있을수록 유지보수성이 좋아지더라. 저 예시가 딱 거기에 부합함.
원래 public 남발하는 성향이었는데 커스텀에디터 만들다가 한번 데여서 코드 쓰레기통에 버리게 된 이후로 SOLID 찾아보게된듯 ㅜㅜ 왜 안전수칙은 피로 쓰여진다는 말을 이해할수있을거같음
저도 같이 일하던 괴수분이 퍼블릭 혐오자라 무적권 [시리얼라이즈필드] 프라이빗 + 게터 쓰라고 배움..
근데 데이터와 코드를 하나로 묶는 것도 중요하다고 하네
https://ko.wikipedia.org/wiki/%EC%BA%A1%EC%8A%90%ED%99%94
흠.. 난 인터페이스가 아직도 아리송함 1인 개발이라 그런지 메서드 래핑, 추상클래스만으로도 해결이 되서 쓸곳이 마땅치 않음.. 상속을 거의 안 해서 더 그런걸 수도
난 반대로 추상클래스 쓰다가 인터페이스로 넘어간 케이스인데, 너무 편하더라. 추상클래스보다 더 추상적으로 쓸 수 있어서 범용성이 훨씬 높은 느낌.
나도 인터페이스 굳이 써야하나? 싶은 주의인데 여기서 본 예시인데 '적 오브젝트'랑 '벽 오브젝트' 둘다 폭발에 휘말리면 부서진다 같은거 구현할때 쓰기 괜찮을듯 '적'이랑 '벽'같은 이질적인 집합을 같은 상위 클래스 아래에 두긴 뭐한데, 둘다 폭발당하면 Bomb()메서드가 호출되게 후딱 구현할려면 인터페이스로 하는게 간편하긴 하겠더라
ㅇㅇ.. 맞음 저도 딱 그런 상황에서만 쓰고 있슴 서로 아예 다른 카테고리, 다른 타입이지만 공통 메서드를 써야할 때
여러개 상속할 수 있어서 개꿀임