Skip to main content

김주엽

1. 📌 핵심 개념 정리

✅ 요약하기

  1. 클래스는 작아야 한다!
  • 클래스를 만들 때 가장 중요한 것은 클래스가 맡은 책임을 작게 만드는 것이다.

  • 클래스의 이름은 해당 클래스의 책임을 기술해야 한다.

    • 클래스의 설명은 if, and, or, but을 사용하지 않고 25단어 내외로 가능해야 한다.
  • 메서드의 수가 적어도 좋은 클래스인가?

    public class SuperDashboard extends JFrame implements MetaDataUser {
      public Component getLastFocusedComponent()
      public void setLastFocused(Component lastFocused)
      public int getMajorVersionNumber()
      public int getMinorVersionNumber()
      public int getBuildNumber() 
    }
    

    위의 SuperDashboard 클래스는 컴퓨턴트에 접근하는 방법을 제공하며
    버전과 빌드 번호를 추적하는 기능을 제공하는데 이는 책임이 많다고 볼 수 있다.


  1. 단일 책임 원칙(Single Responsibility Principle)

    단일 책임 원칙이란 클래스나 모듈을 변경할 이유가 오직 하나뿐이어야 한다는 원칙이다.
    큰 클래스 몇 개보다 작은 클래스 여럿으로 이뤄진 시스템이 더 바람직하다.

  • 개선 전

    public class SuperDashboard extends JFrame implements MetaDataUser {
      public Component getLastFocusedComponent()
      public void setLastFocused(Component lastFocused)
      public int getMajorVersionNumber()
      public int getMinorVersionNumber()
      public int getBuildNumber() 
    }
    

    SuperDashboard 클래스는 버전 정보를 추적하고 자바 GUI 컴포넌트를 관리하는 둘 이상의 책임을 가지고 있다.

  • 개선 후

    public class SuperDashboard extends JFrame {
        public Component getLastFocusedComponent()
        public void setLastFocused(Component lastFocused)
    }
    
    public class Version {
        public int getMajorVersionNumber();
        public int getMinorVersionNumber();
        public int getBuildNumber();
    }
    

    버전을 관리하는 클래스를 추가해서 책임을 분리했다.


  1. 응집도
  • 응집도가 높다는 뜻은 클래스에 속한 메서드와 변수가 서로 의존하며 논리적인 단위로 묶인다는 것을 의미한다.
  • 클래스는 인스턴스 변수 수가 작아야 한다.
  • 일반적으로 메서드가 변수를 더 많이 사용할수록 메서드와 클래스는 응집도가 더 높다.
  • 모든 인스턴스 변수를 메서드마다 사용한다면 클래스의 응집도는 매우 높아진다.

  1. 응집도를 유지하면 작은 클래스 여럿이 나온다
  • 변수가 아주 많은 큰 함수 하나를 작은 함수로 쪼개면 인스턴스 변수가 늘어날 수 있다.
  • 인스턴스 변수가 늘어나면서 응집도는 낮아질 수 있는데 이 경우에 메서드를 독자적인 클래스로 분리해야 한다.

  1. 변경으로부터 격리
  • 구체적인(Concrete) 클래스에서 상세한 구현 코드에 의존하는 클래스는 구현 코드가 바뀌면 위험에 빠진다.
  • 인터페이스와 추상 클래스를 사용해 구현이 미치는 영향을 분리한다.
  • 상세한 구현에 의존하는 코드는 테스트가 어렵다.
  • 테스트가 가능할 정도로 시스템의 결합도를 낮춰 유연성과 재사용성을 높여야 한다.
  • 결합도를 최소로 줄이면 자연스럽게 DIP 원칙을 따르게 된다.
    • 클래스는 구현이 아닌 추상화에 의존해야 한다는 원칙

2. 🤔 이해가 어려운 부분

🔍 질문하기

책을 읽으며 이해하기 어려웠던 개념이나 명확하지 않았던 내용을 정리합니다.

  1. 변경으로부터 격리
    • 어려웠던 부분
      책에서 말하는 구체적인 클래스에서 상세한 구현에 의존하는 클래스가 어떤 클래스를 말하는 건지 이해하기 어려웠다.
    • 이해한 점
      인터페이스나 추상 클래스없이 작성한 클래스를 구체적인(Concrete) 클래스라고 말한다.
      • 예시
        public class Driver {
            private Car car = new Car();
        }
        
        이 경우 Car의 동작이 바뀌면 Driver에도 영향을 미친다.
        따라서 다음과 같이 코드를 개선한다.
        public class Car implements Vehicle {
            @Override
            public void drive() {
                System.out.println("자동차를 운전한다.");
            }
        }
        
        public class Driver {
            private Vehicle vehicle;
        
            public Driver(Vehicle vehicle) {
                this.vehicle = vehicle;
            }
        }
        

3. 📚 참고 사항

📢 논의하기

관련된 자료가 있다면 공유하고, 더 깊이 논의하고 싶은 아이디어나 의견을 정리합니다.

  1. 관련 자료 공유