JAVA 객체지향 관련 [Optional, if문, Getter/Setter]

10/10 화요일 

 

1. 객체지향 관련 이론 및 문법

Optional

자바에서 null 처리를 쉽게 처리하기 위해 부가적으로 나온 자료형

public Optional<자료형> 메서드명() {

		return Optional.ofNullable(자료);
}

 

예외처리 코드를 간소화하게 사용할 수 있다.  ->  .orElseThrow(( ) -> new 예외클래스( ))

 

Optional 객체를 만드는 정적 팩토리 패턴 메서드 명령어

Optional.of(자료);  // 생성 시점에서 null이면 예외 발생
Optional.ofNullable(자료); // 생성 시점에서는 null여부 상관없지만 처리가 쉬움
Optional.empty(); // 빈 옵셔널 만들고 싶은 경우(거의 쓸 일 없음)

JPA와 같이 Optional로 된 자료를 기본으로 리턴하는 경우 orElseThrow 같은 메서드로 예외를 처리하면 된다.

 

만약 일반 객체만 리턴하는 경우라면 Optional.ofNullable(자료)를 이용해 생성한 다음 orElseThrow를 적용하면 된다.

 

 

2.  실질적인 객체지향 코드 작성하기

if문을 최대한 억제하기

많은 if문은 개발자의 인지능력을 흩뜨려놓는다.

 

해결 방안

•  early return : 빠르게 리턴
•  미리 유효성 검증 후 연산
•  enum 안으로 연산을 집어넣기
•  등등

그러나 근본적으로 코드 실행 중에 유효성을 검사하는 것은 if문을 계속 양산한다. 따라서 생성 시점에 아예 유효성을 검사하는 것이 더 좋다.

 

 

Getter, Setter

- getter가 작성되었을 때의 문제점

• 클라이언트 코드에서 커맨드 코드 내부를 쉽게 추론하도록 만들어주는 문제가 있다. 따라서 getter 대신 특정 비즈니스 로직을 getter 대신 바로 집어넣는 방법이 더 좋다.
• 캡슐화는 이런 방향으로 어떤 작업을 할 수 있는지 알려주지만, 그 작업이 어떤 방식으로 진행되는지는 숨기는 방향으로 간다.
• 이를 결합도와 응집도라는 단어로 설명할 수 있다.
  • 결합도 : 두 클래스 간에 영향을 주는 것이 많아서 하나의 변경이 다른 클래스에도 영향을 주는 경우
  • 응집도 : 하나의 도메인에서 활용하는 로직을 최대한 하나의 클래스 내부에 모아두는 경우

=> 객체 지향에서는 결합도는 낮추고 응집도는 높아야 좋다.

 

 - 생성자 주입이 좋고 setter를 되도록이면 쓰지 말아야 하는 이유

• 기본 생성자 setter를 이용해서 추가적인 데이터 수정을 허용한다면 모든 필드를 초기화하지 않고 넘어가는 경우가 발생할 수 있다.
• 모든 필드를 초기화하지 않고 넘어가는 경우가 발생할 수 있다.
• 따라서 모든 필드를 초기화하도록 생성자 주입을 강요하는 것이 더 좋다
• 불완전한 인스턴스의 생성을 억제할 수 있다는 것이 바로 생성자 주입의 좋은 점이다.
• 그래서 외부와의 접점이 있는 클래스를 DTO로 먼저 사용하고 내부적으로는 따로 사용하는 Entity 클래스를 이용하는 것이 좋은 이유이다.

 

마무리 쓸없 Tip. (쓸모없는 or 쓸모없지 않은...)

enum

- 일급  객체 _ Bifunction

 

객체지향

- 응집도는 높이고, 결합도는 낮춰라

 

cmd(Ctrl) + n : Generate

- Getter, Setter

- Override 등