객체 지향 심화

배운점

객체지향 4원칙

• 추상화
  • 사물의 성질, 공통성을 추출하여 파악하는 것
  • 클래스의 공통적인 요소들을 봅아서 상위 클래스를 만들어 내는 것
  • 인터페이스, 추상 클래스가 있다.
  • 인터페이스는 추상 메소드를 묶어 놓은 것, 추상 클래스는 필드, 메소드를 모두 가지면서 추상 클래스를 가진다
  • 추상 클래스는 하위 클래스에서 인스턴스화 할 수 있다
  • Animal animal = new Cat();
    추상클래스 Animal 참조변수는 하위 클래스인 Cat의 인스턴스를 가리킨다
  • Shopping shopping = new OnLineShopping();
    인터페이스 Shpping 참조변수는 인터페이스를 구현한 OnLineShopping 인스턴스를 가리킨다
• 상속
  • 기존에 있는 클래스를 재활용하여 새로운 클래스를 작성하는 방법
  • ~은 ~이다 관계가 성립해야 한다
• 다형성
  • 하나의 객체가 여러 가지 형태를 가질 수 있는 성질
  • 인터페이스나 추상 클래스를 이용하여 한 타입의 참조 변수에 여러 타입의 객체를 넣을 수 있도록 한다
• 캡슐화
  • 특정 객체의 정보를 외부(다른 객체)로 부터 은닉한다
  • 접근 지정자를 이용해 캡슐화를 할 수 있다
  • 객체는 다른 객체가 무엇을 실행하는지 알지만 어떻게 수행하는지에 대해 알 수 없어야 한다

SOLID 원칙

단일 책임 원칙(SRP, Single Responsibility Principle)

• 하나의 클래스는 하나의 책임만 가져야 한다.
• 주문 클래스는 주문만, 메뉴 클래스는 메뉴에 관련된 책임만 가져야한다.
• 개발자라는 클래스에 백엔드, 프론트에 관한 행위를 구현한다 -> 백엔드 클래스, 프론트 클래스로 분리한다

개방-폐쇄 원칙(OCP, Open/Closed Principle)

• 소프트웨어 요소(클래스, 모듈, 함수 등)는 확장에 대해서는 개방되어 있어야 하지만 변경에 대해서는 폐쇄적이어야 한다는 원칙
• 추상화, 상속, 인터페이스를 사용하여 확장, 새로운 요소에 유연하게 대응할 수 있다

public abstract class Animal {
    public abstract void makeSound();
}

public class Dog extends Animal {
    public void makeSound() {
        System.out.println("멍멍");
    }
}

public class Cat extends Animal {
    public void makeSound() {
        System.out.println("야옹");
    }
}

public class AnimalSoundPlayer {
    public void playSound(Animal animal) {
        animal.makeSound();
    }
}

makeSound()를 추상 메소드로 선언함으로 AnimalSoundPlayer는 새로운 animal 클래스가 추가되더라도 수정 할 필요가 없다

리스코프 치환 원칙(LSP, Liskov Subsitution Principle)

• 프로그램 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 한다는 원칙
• 상위 클래스의 참조변수에 하위 클래스를 할당하더라도 상위 클래스의 인스턴스 역할을 하는데 문제가 없다
• Daughter daughter = new Father() -> 딸의 클래스는 아버지 클래스를 상속 할 수 없다
• Daughter daughter = new Mother() -> 딸의 클래스는 어머니 클래스를 상속 할 수 있다

인터페이스 분리 원칙(ISP, Interface Segregation Principle)

• 특정 클라이언트를 위한 인터페이스 여러개가 범용 인터페이스 하나보다 낫다는 원칙
• 인터페이스를 분리하면 결합도를 낮출 수 있다
• 인터페이스의 기능이 명확해지고, 대체 가능성이 높아진다

의존관계 역전 원칙(DIP, Dependency Inversion Principle)

• 추상화에 의존해야지 구체화에 의존하면 안된다는 원칙
• 특정 객체가 어떤 객체를 사용할지 결정하면 안된다
• 자동차와 타이어의 관계에서 자동차에 특정 타이어를 구현 하는 것 보다 타이어 인터페이스에 의존하고
  타이어 인터페이스를 구현한 여러 타이어 클래스를 생성하는 것이 좋다
• 구현체에 의존하지 않고, 추상클래스, 인터페이스에 의존해야한다
• DI(Dependency Injection)를 이용해 객체간의 의존관계를 설정한다(생성자를 통해 주입받는다)

느낀점

---

정처기 준비하면서 이론으로만 알던 내용들을 실습으로 학습하니까
객체 지향 원칙을 지키면서 코딩하는 것이 쉽지 않다는 것을 느꼈다.

그동안 자바를 사용하면서 이런 것도 지키지 않고 사용했다는 것이 부끄러워졌다.

그동안 내가 생각하고 있던 규칙이 흔들렸고, 3일동안 계속 객체 지향에 대해 고민했다.

아직 완전히 객체 지향을 받아드린 것은 아니지만, 매우 효율적이고 재밌다는 생각이 들었다.

기능을 구현하는 것도 중요하지만 객체 지향에 맞게 리팩토링하는 작업도 중요하다는 생각도 들었다.

객체 지향을 본격적으로 이해하기 시작했으니까 앞으로는 더 좋은 개발자가 될 수 있겠다는 생각이 들었고
내가 이 분야를 어느 정도 정복 했을 때 내가 어떻게 변화되어 있을까 궁금해졌다!

앞으로 더 열심히 해서 좋은 개발자가 되도록 노력하자!! 꾸준히 한다면 시간은 나의 편이다.