TIL 22.11.21 / 객체지향 프로그래밍

쓰옹·2022년 11월 21일

개발자를 향해~~TIL✍

목록 보기

19/87

TODAY

오늘은 집중이 잘 안됐다.
객체지향 강의 들을 때도 이해가 안되니까 내용이 잘 안들어오고
자바 복습할 때도 집중이 잘 안되는 그런 날이였다.
괜시리 축축 처지고..
이러면 안돼!
계속 자바 복습할 때도 객체지향에 관련해서 공부하고 있는 중인데
코드를 손으로 따라 쳐봐도
이해가 잘 안되다.
이론은 이해가 되는데 내가 나중에 코드를 작성해야 할 생각을 하니
못할 것 같은 생각이 자꾸 든다...
힝구
그래도 기초를 탄탄히 계속 공부하면
내가 스스로 코드를 짤 수 있겠지.

연희튜터님이 저번주에 숙제로 내주신
계산기 문제를 풀어보려고 하는데
한 개 밖에 못하겠다.. 그래도 그건 결과값이 잘 나오긴 하는데
다른건 손도 못 댈 것 같다ㅠㅠ
수요일부터 프로젝트 시작인데 큰일이다증말

자바 복습은 따로 자바 시리즈에 포스팅했다.

객체지향 프로그래밍_SOLID원칙

SRP(단일 책임 원칙), OCP(개방-폐쇄 원칙),
LSP(리스코프 치환 원칙), DIP(의존 역전 원칙), ISP(인터페이스 분리 원칙)

변경에 유연하게 대처하기 위한 원칙
의사소통에 대한 비용을 줄여줌
객체지향적으로 코드를 짤 때 이해가 필요함

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

한 클래스는 하나의 책임만
책임의 기준은 변화되는 부분
- 변경 발생 시 변경해야 할 부분이 많으면 단일 책임 원칙에 위배된 것
- 변경해야 할 부분이 적어야 한다.
- 한 클래스에서 변경이 발생 시 다른 부분에도 영향이 끼치면 안됨
클래스를 변경해야하는 이유가 오직 하나여야 한다.

 class Galaxy {
  private String serialNumber;  //고유정보 -> not 변화요소
  private String cpu;           //특성정보 -> 변경 발생 가능성
  private String memory;        //특성정보 -> 변경 발생 가능성
  private int battery;          //특성정보 -> 변경 발생 가능성
  private double weight;        //특성정보 -> 변경 발생 가능성
}

-------------------------

특성 정보에 변화가 발생하면,
Galaxy 을 변화 시켜야 되는 부담이 발생함.

-------------------------

// 클래스 분리. 스펙만 관리.  
class GalaxySpec {
  private String cpu;
  private String memory;
  private int battery;
  private double weight;
}

class Galaxy {
   	private String serialNumber;
	private GalaxySpec spec;
   	public Galaxy(String serialNumber, GalaxySpec spec) {
      this.serialNumber = serialNumber;
      this.spec = spec;
   }
}

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

확장에는 열려있고 변경에는 닫혀있어야한다.
== 변경을 위한 비용은 줄이고, 확장을 위한 비용은 극대화한다
공통화

예제

위의 코드에서 핸드폰의 종류가 계속 늘어난다면(아이폰, 샤오미 등등)

공통화 하기

class Phone {
	private String serialNumber;
  	private PhoneSpec spec;
 	public Phone(String serialNumber, PhoneSpec spec) {
  		this.serialNumber = serialNumber;
    	this.spec = spec;
 	}
}

class PhoneSpec {
	private String cpu;
	private String memory;
  	private int battery;
	private double weight;
}

class Galaxy extends Phone

class IPhone extends Phone

class 샤오미 extends Phone

class Sony extends Phone

템플릿 메소드

OCP원칙의 좋은 예
메소드 실행 순서와 시나리오 정의
바뀔 수 없음 == 상속받은 하위 클래스에서 재정의 불가
final 예약어 사용해 선언
로직 흐름이 이미 정해져 있는 프레임워크에서 많이 사용하는 기본 구현 방법

LSP(Liskov Substitution Principle) - 리스코프 치환 원칙

자식 타입은 언제나 자신의 부모타입 으로 교체할 수 있어야 한다.
정확성을 깨뜨리면 안된다.
부모 클래스에서 선언된 기능이 자식 클래스에서 바뀌면 안된다.
스피커 기능 중 볼륨업은 소리를 키우는 기능인데
마샬스피커의 볼륨업이 소리를 줄이는 기능이 되면 안된다.

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

클라이언트가 사용하기 편하게. 클라이언트 관점
범용 인터페이스 클라이언트보단 특정 클라이언트를 위한 여러 개의 인터페이스 분리가 더 좋다
자신이 사용하지 않는 메소드에 의존하면 안됨
필요한 메소드에만 의존하게 하자

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

구현체가 아니라 인터페이스에 의존해야한다
객체들 간 의존관계가 형성될 때 어떻게 변화에 용이하게 대응할 수 있을 것인가
변하기 쉬운 것과 어려운 것을 구분해야함
- 변하기 쉬운 것 - 구체적인 행동
  - 스마트폰으로 전화를 건다 --┐
                                          | -->
  - 공중전화로 전화를 건다 ----┘
  - 이메일을 발송한다--------------┐
                                              | -->
  - 카카오톡 메세지를 전달한다----┘
- 변하기 어려운 것 - 흐름이나 개념과 같이 추상적인 것
  - 전화를 건다
  - 메세지를 전달한다