이것은 정답이 아니라 한 블로그에 기술된 하나의 의견이다. 읽어보고 신선한 접근이라고 생각해서 정리해둔다. 링크 데이터베이스에서 boolean 값을 지정해서 저장해야하는 경우들이 있다. , , 등등을 기록해야하는 경우들이다. 이 경우에 boolean으로 저장하지 말고 timestamp로 저장하도록 해보자! 글쓴이의 말을 인용하자면 “단 한번도 후회한적이 없다”. Boolean 값으로 저장할만한 데이터는 언제 해당 데이터가 set 되었는지에 대한 timestamp를 제공함으로 잃는 것이 없다. 아무리 해당 시간 데이터가 필요하지 않더라도 말이다. 이렇게 구현을 하게 된다면 은 로 은 로 간주되어 처리하면 될 것이다. 따라서 자연스럽게 , , 등등으로 변환될 것이다. 의견 글쓴이의 말이 일리가 있다. 큰 구현의 차이나 처리의 차이 없이 동일한 연산을 수행할 수 있고, 더 많은 정보를 제공하는 이점이 있다. 하지만 해당 데이터가 로 지정이 되어 있는 시점이 있다는 것이 해당 …

아직 잘 모르는 분야라서 우선 두개의 차이점에 대해서만 기록해본다. 둘 중 어느 것을 어느 때에 사용해야 하는지에 대한 판단은 잘 모르겠지만 이 링크 를 확인해보면 singleton 사용을 지양하라고 했고, 또 정적 메소드도 객체지향에서는 지양하는 것이 좋다고 한다. 싱글톤 단 하나의 객체만을 생성할 수 있는 패턴이다. 객체를 생성하려고 할 때마다 이미 생성된 것을 반환하거나 없다면 해당 시간에 처음 생성하도록 한다. 정적 클래스와는 달리 싱클톤 클래스는 과 이 가능하다. 언제 생성하는지에 대한 시점을 조정할 수 있다. 객체이기 때문에 힙에 싱글톤 객체가 저장된다. 따라서 쓰레드간 공유가 가능하다. 싱글톤은 구현으로 단 하나만 생성되게 보장한 것이지만 그 자체로는 클래스 객체이기 때문에 직렬화가 가능하다. Static 클래스 Static 메소드를 가지는 클래스를 말한다. 어플리케이션이 메모리에 로드 될 때 정적 스택에 바로 초기화 된다. 표준 클래스라고 보기는 어렵고 라고 볼 …

전략 패턴(Strategy Pattern)이란? 객체가 할 수 있는 행위에 대한 생성하여 해당 행위들을 캡슐화(인터페이스화) 하여 사용하는 것이다. 즉, 행위를 각각의 전략 클래스로 생성하고 수정이 필요한 경우 전략을 바꾸는 것으로 행위를 수정하도록 한다. 왜 전략 패턴을 사용해야 할까? 예를 들어 움직이는 Bus, Train 이라는 객체가 있다고 하고 각각 move() 함수를 통해서 움직인다. 그런데, Bus는 도로로 Train은 선로로 움직인다. 만약 이때 버스가 더 이상 길이 아니라 선로로 움직인다고 가정할 때, 버스의 move() 메소드를 선로로 움직이는 로직으로 수정해야 한다. 이때 두 가지 문제가 발생한다. OCP (Open-Closed Principle)에 위배 : 수정에 닫혀있어야 하는데, 메소드를 직접 수정 확장이 될 경우 메서드 중복 문제 : 메소드를 가진 여러 객체가 있을 때 일일이 수정을 해아함 이 때 전략 패턴을 사용하면, 위 두 문제를 마주하지…

FSM 을 State Design Pattern 으로! FSM (Finite State Machine) : 유한 상태 기계 특징 유한한 개수의 상태를 가짐. 그 중 하나의 상태만 취함. 특정 조건이 되면 다른 상태로 변함. 가능한 상태 집합과 각 상태들의 전이 조건으로 정의됨. 왜 쓸까? 가능한 상태들을 명확히 규정할 수 있음. 상태 중복을 피하고 전이들읠 명확하게 규정할 수 있음. 기계의 동작이 명확히 규정됨. 이러한 FSM 을 구현하려면 각 상황에 대한 수많은 분기문들을 통해서 구현이 되어야 한다. 또한 기능이 하나 추가가 될 때 고려해야 할 상황과 추가해야할 코드들이 굉장히 많아진다. State Design Pattern 상태 디자인 패턴 언제 사용할까? 객체가 상태를 가져야 할 때 특정한 조건을 판단하여 해당하는 상태로 변환해야 하는 로직이 있을 때 각 상태마다 전이 조건이 있어 상황이 달라질 때 State Pattern 을 사용한다면? State Pattern 을 사용…

처음 MVC 패턴을 공부하게 되면서 잘 이해하지 못한 상태로 1단계 코드를 제출한 것 같다. 라는 부분을 간과하고 모든 도메인 모델에 대한 로직을 모두 Controller로 넘겼다. 하지만 MVC는 그렇게 분리되는 것이 아니었다. 이 부분에 대해 리뷰어에게 질문을 했더니 좋은 소스와 함께 정성스럽게 답해주셨다. 즉, 인데 Controller는 View로 부터 받은 입력을 기반으로 Model에 적절한 메세지를 보낸다. 그리고, Model은 해당 메시지에 따른 로직을 수행하고, 그에 따른 결과를 다시 Controller에 전달한다. 이렇게 왔다갔다 상호작용 하는 중간다리 역할이 Controller이다. 모든 서비스 로직을 Controller에다가만 구현하는 것이 아니다. 우테코에서 제공한 MVC 패턴에 대한 설명에도 핵심적인 설명이 있다. 리뷰어도 이것만 챙겨도 절반 이상이 MVC 패턴에 맞추어 진다고 한다. 공부하기에 좋은 자료로 추천한 위키피디아와, 모델-뷰-컨트롤러 …