NHN Academy - 2024.10.25(Fri)

동일성 : 두 객체가 메모리 상에서 동일한 객체인지 여부를 판단하는 것  /  두 참조가 같은 메모리 주소를 가리키고 있는지를 비교

동등성 : 두 객체의 내용이 같은지를 비교하는 것  /  객체의 상태나 속성이 동일한지를 판단

 

분류 : 객체의 세부사항을 숨기고 인스턴스간 공유하는 공통 특성을 기반으로 범주를 형성하는 과정

유일성 : 분류의 역은 범주로부터 객체를 생성하는 인스턴스화 과정

 

클래스의 인스턴스 ➡ 객체

유스케이스의 인스턴스 ➡ 시나리오

DB 테이블의 인스턴스 ➡ Row

매개변수의 인스턴스 ➡ 전달인자

 

집합와 분해 == 전체와 부분

(집합 = 세부사항을 숨기고 전체를 형성 / 분해 = 기존 큰 전체를 작은 단위로 분리)

 

Association  >  Aggregation  >  Composition

 

클린 코드?

• 간결하고 읽기 쉬운 코드
• 변경 및 유지보수가 용이한 코드
• 다른 개발자가 쉽게 이해하고 수정할 수 있도록 만들어진 코드
• 버그 수정 및 새 기능 추가 용이
• 협업 시 코드 리뷰 및 이해가 쉬움
• 가독성 / 간결성 / 중복 최소화 / 의미 있는 이름 / 작고 집중된 함수 / 일관성 / 오류 처리 / 테스트 용이성 / 확장성(interface) / 리팩토링과 테스트

 

APT. 를 1000번 출력하는 프로그램을 급하게 만들어야 한다. for문 같은 루프 문이 존재하지 않을 때, 해결책을 10초 안에 대답하라. 정답 = 재귀 함수를 이용해서 출력한다.

 

new O = 간결성 O

ex. Database db = new Datebase();

 

Composite Pattern

 

불변 객체 사용 권장

 

 

클린코드 SOLID

1. SRP(단일 책임 원칙)

: 단일 책임 원칙은 소프트웨어 모듈은 변경의 이유가 오직 하나뿐(오직 하나의 액터actor에 의해서만 요청되어야 함)이어야 한다는 원칙

: 즉, 2개 이상의 액터들이 의존하는 모듈은 분리할 것

 

2. OCP(개방-폐쇄 원칙)

: 기존 코드를 수정하기보다 새로운 코드를 추가하는 방식으로 시스템의 행위, 기능을 변경할 수 있도록 설계해야 한다는 원칙

: 쉽게는 소프트웨어 개체(클래스, 모듈, 함수 등)은 확장에 대해서 열려 있어야 하고, 수정에 대해서는 닫혀 있어야 한다는 원칙

   EX> 어떤 함수의 변경 시, 그 함수를 의존하고 있는 다른 부분들의 동작이 기존처럼 동작할지 알 수 없다.

 

3. LSP(리스코프 치환 원칙)

: 상호 대체 가능한 구성요소를 이용해 소프트웨어 시스템을 만들 수 있으려면, 각 구성요소는 치환 가능해야 할 것

: LSP를 고려한다면 하위 클래스는 상위 클래스의 책임을 그대로 수행하면서 확장에만 열려있어야 한다.

: 이 원칙이 지켜지지 않는다면 클래스 계층 관계가 쉽게 오염될 수 있다.

      

4. ISP(인터페이스 분리 원칙)

: 소프트웨어 설계자(혹은 클라이언트)는 사용하지 않은 것(메소드 등)에 의존 X  ➡  작은 단위의 역할 인터페이스로 분리

: 클라이언트는 꼭 필요한 메소드만 이용할 수 있게 해야한다.

: 특히 서로 의존하는 모듈 관계에서 불필요한 기능이 서로에게 포함  ➡  에러 발생

 

5. DIP(의존 역전 원칙)

: 상위 모듈은 하위 모듈을 구현하는 코드에 의존하면 안되고, 세부사항이 정책에 의존해야 할 것

: 상위 모듈과 하위 모듈은 추상화에 의존해야하며 추상화는 세부사항에 의존하면 X

: 추상 클래스와 인터페이스를 잘 활용하여 하위 모듈의 변경이 상위 모듈의 변경으로 이어지면 X