✏️ 2022-11-22 Today I Learn

[객체지향] 객체지향 Study

1. 다운캐스팅

부모가 자식의 참조변수형을 이용하여 형변환을 하는 것.

• 사용사례

class Participant{

}

class MemberParticipant extends Participant{
    void A(){}
}

class NonMemberParticipant extends Participant{
    void B(){}
}

Participant p;
// p 가 A 메소드를 사용하길 원할 경우
(MemberParticipant) p;

2. 3-Tier Architecture

Presentation - Application - Data 의 3단계로 구분되는 아키텍쳐 View - Controller - Model 의 MVC모델과 비슷한 듯 하다.

• Presentation Tier

  • 데이터를 보여주는 것에 집중하는 계층

• Application Tier

  • Service 계층으로서, Data Tier와 API를 이용한 통신을 한다.
  • 가져온 데이터를 가공하여 클라이언트에 전달해주는 비즈니르 로직을 제공하기도 한다.

• Data Tier

  • Repository 라고도 표현하며, 데이터베이스 안에 있는 데이터를 Application Service의 요청으로 반환한다.

[회고] 221122 : 완전히 아는 상태에서 설계하기

오늘 튜터님께서 하신 강의를 토대로 리팩토링을 해보면서, 무릎을 탁치는 순간들이 있었다. 계속 똑같은 getMenuItem, getMenu 가 반복되어서 왜 계속 똑같은 코드를 치시는 거지 라고 의문을 가졌다. 또한, 내가 직접 처음부터 작성해보려고 했는데, 3 Tier의 정확한 이해가 없이 빌드업 해나가려고하니, 구조가 계속 꼬이고 역할 할당이 잘 되지 않아서 구조를 짜는게 잘 되지 않았다.

코드를 이해하고 보니, 결국엔 객체의 역할과 책임이 부여되고, getMenuItem, getMenu 은 각자의 역할에 따라 할당된 것들이었다. 같은 기능을 하는 것 처럼 보여도, Service(Application)에서의 getMenuItem 은 Data Tier에서 가져오는 데이터이고, Repository(Data) 에서의 getMenuItem은 직접적으로 데이터베이스에서 가져오는 것이다. main은 어쩔수없이 UI와 Service가 혼용되는 식으로 구성되어있는데, 너무 절차지향같지 않도록 잘 구현하는 것이 중요 할 것 같다.

확실한 것이 아니라면, 손을 멈추고 고민해보고 주변에 도움을 요청하던 리서치를 하던, 확실해진 상태에서 개발에 돌입하는것이 서비스 품질에도 좋은 영향을 끼칠 수 있겠다는 생각이 들었다. 만일, 내가 아무런 이해없이 내 설계대로 서비스를 계속 구현했다면, 객체지향의 원칙을 무시한 엉망진창 서비스가 탄생했을 것이다.

나는 잘하기 위해 왔지, 잘난척을 하러온 것이 아니다. 명심하자!