스테이트 패턴

• 객체의 상태가 변경됨에 따라 다르게 행동할 수 있음 : 상태 자체를 객체화하는 것이라고 이해됨 - 상태를 추상화 시킴, 상태에 따라 할 수 있는 일이 많아지고 조건문이 엄청 세분화 되어질 때 분리시켜서 관리하도록 하는 것이 좋을 듯
  • 상태 별로 같은 행동(코드 중복 제거), 상태 별로 코드 관리(코드 관리에 편함)
  • 볼링 게임 구현할 때 사용했던 패턴이었음 : 상태 자체가 실질적으로 쓰러뜨린 핀(입력된 값)이 유효한 값인지 아닌지 해당 프레임의 상태값이 무엇인지 정할 수 있었음
• 예제로 되새겨보는 스테이트 패턴

public class Frame {

    private FrameStatus status;

    public Frame() {
        this.status = FrameStatus.startStatus();
    }    
}

class FrameStatus {

    public boolean isFinish();

    public FrameStatus bowl(int pins);
}


class Strike {

    private Pin pin;    

    public Strike(int pins) {
        pin = new Pin(pins);
    }

    @Override
    public boolean isFinish() {
        return true;
    }

    @Override
    public FrameStatus bowl(int pins) {
        throw new CannnotBowlException();
    }
}

class FirstBowl {

    private Pin pin;

    @Override
    public boolean isFinish() {
        return false;
    }  

    .
    .
    .    
}

class Miss {

    private Pin[] pins = new Pins[2];

    @Override
    public boolean isFinish() {
        return true;
    }    

    .
    .
    .    
}

DB 익숙해지기 - 데이터 모델링

• 필요한 데이터가 무엇인지 분석하고 DB에 저장할 수 있게 설계하는 것을 모델링이라 함
• 객체 추상화와 같은 개념 - 필요하지않은 데이터를 굳이 저장할 필요가 없음

설계 - 개발

1. 요구사항 분석
2. ERD(Entity Relationship Diagram) : 필요한 데이터 설계(개체 - 필요한 attr) 및 개체 관계 설정(1:N, M:N 등), 객체 추상화 과정과 같음(아직 실제로 만들지 않음, class - 커다란 카테고리)
3. 논리 설계 : ERD -> 테이블로 변환, 개념적으로 설계되어있던 것을 시스템에서 돌아갈 수 있도록 변환(스키마라고 함), 관계는 외래키 속성으로
4. 물리적으로 구현 : SQL(실제로 만들어짐)

• 개체(entity)와 객체(object) : 내가 느끼기로는 class와 object의 차이, 커다란 카테고리를 설계한 결과물이 Entity(데이터 저장 관점에서)라면 개별적인 존재(OOP 관점)가 object

앞으로 해야봐야할 것

• 요구사항을 가지고 모델링해보기

AWS 조금이라도 알기

Cloud Watch

• 사용하고 있는 어플리케이션(EC2, RDS 등등) / 리전(AWS 어플리케이션 지역) 상태 모니터링 서비스 : 모니터링 시스템을 대신해서 구축해서 웹 콘솔로 제어할 수 있음
• 모니터링 정보, 필요한 알람(조건 주고, 연락가도록) 생성할 수 있음 : 사용하고 있는 서비스 별로 지표를 대시보드에 생성할 수 있는데 여러가지 지표 중에 필요한 것을 선택하면 됨\
  • 경보 생성 시 특정 상태일 때 알람(이메일/모바일), AutoScaling 작업, 인스턴스에 대한 작업(재부팅, 종료, 복구 등)을 설정할 수 있음