객체지향5 인터페이스 분리 원칙(ISP) 제대로 이해하기 인터페이스 분리 원칙(Interface Segregation Principle)은 처음 내가 SOLID 원칙을 공부했을 때 가장 납득하기 힘들었던 원칙이었다. 대부분의 교과서와 강의가 SOLID 원칙을 변경의 용이성 관점에서만 설명하기 때문에, 객체지향이 지향하는 관점과 사고방식에 대해 몰랐던 당시의 나로선 ISP를 100% 납득할 수 없었다. "클래스가 있는데 그대로 쓰지, 왜 굳이 인터페이스를 또 만들어야 하는거지? 굳이 나누는 것이 의미가 있나?" 라고 생각했다. 물론 인터페이스를 나누는 것이 유용해 보이기는 했지만, 딱 그 뿐이었다. 유용성 이상으로 ISP를 지켜야 하는 이유를 몰랐다. "의존하지 않는 메소드가 있으면 그냥 안 쓰면 그만 아닌가?" 라고 생각했었다. 유용하다는 것은 달리 말하면 그.. 2023. 12. 11. 객체지향 언어로 절차적 프로그래밍을 하는 문제 일반적으로 절차적 프로그래밍은 데이터와 그 데이터를 처리하는 함수를 분리시킨다. 따라서 데이터가 변경되는 경우 필연적으로 함수도 변경해야 한다. 그리고 함수를 변경하면 다시 그 함수를 사용하는 모듈도 변경되어야 한다.. 이렇게 데이터의 수정으로 인해 변경이 위로 파급된다. 자바와 같은 객체지향 언어를 사용한다는 이유로 객체지향 설계가 완성되는 것은 아니다. 어쩌면 절차적 프로그래밍 언어보다 더 이상한 코드가 만들어질 수도 있다. 특히 데이터의 구현을 중심으로 놓고 보는 관점은 아무리 OOP 언어를 사용한다고 해도 잘못된 설계를 낳을 수 있다. 클래스를 만들어 데이터와 메소드를 private 접근 제어자로 숨긴다고 해도 getter, setter, 간단한 데이터 조작 연산의 남발은 이를 무색하게 만든다. .. 2023. 12. 7. 데이터 중심 설계는 캡슐화, 결합도, 응집도를 해친다 (오브젝트 4장) 1. 좋은 객체의 특성 개념 정리 1-1. 캡슐화 내가 처음 자바를 배웠을 때, 캡슐화란 "데이터와 프로세스를 한데 묶어 편의성을 제공해준다"는 식으로 배웠던 기억이 있다. 그때 나는 막 C언어의 절차적 프로그래밍 스타일만 알고 있었기 때문에 캡슐화를 정말 말 그대로 알약과 같은 것이라고 생각했다. 데이터와 프로세스를 한데 묶는 기법 정도로 여겼다. 그러나 캡슐화는 편의성 개념과는 거리가 멀다. 캡슐화는 정보 은닉의 일종으로서, 객체의 내부 구현을 외부로부터 숨기기 위한 전략 중 하나다. 여기서 중요한 요점은 객체의 내부 구현을 왜 숨겨야 하는가다. 이 질문에 답하기 위해서는 객체란 무엇인지 아는 것으로부터 출발해야 한다. 객체지향 소프트웨어에서 객체란 특정 기능을 수행해주는 작은 프로그램과 같다. 절차.. 2023. 12. 7. 책임과 역할에 대한 상세한 이야기 (오브젝트 3장) 1. 역할, 책임, 협력 조영호님의 에서는 객체지향의 핵심 원칙을 역할, 책임, 협력의 구조로 소개한다. 간단히 말해 소프트웨어를 각자의 '책임'을 수행하며 서로 '협력'하는 '역할'들로 명세를 짜는 것이다. 역할과 책임에 대한 구체적인 실천은 런타임에 '객체(object)'가 수행한다. 이미 위 포스팅 링크에서 많은 내용을 정리했다. 따라서 여기서는 같은 저자의 챕터 3장에 나오는 설명 중 새롭게 알게 된 사실만 따로 정리하려 한다. 2. 책임 할당: 정보 전문가 패턴(Information Expert) 좋은 객체지향 설계의 핵심은 책임을 적절한 객체에게 할당하는 것이다. 크레이그 라만(Graig Larman)은 객체의 책임을 크게 하는 것(doing)과 아는 것(knowing)의 두 가지 범주로 나누.. 2023. 12. 7. 이전 1 2 다음
