리셋 되지 말자

템플릿 메서드 패턴:템플릿 메서드와 훅(hook) 메서드가 존재하는 패턴 템플릿 메서드 상위 클래스에 공통 로직을 수행하는 메서드 훅(hook) 메서드 선택적으로 오버라이딩할 수 있는 메서드 예시 코드 Animal.java package templeteMethodPattern; public abstract class Animal { // 템플릿 메서드 public void playWithOwner() { System.out.println("이리온"); play(); runSomething(); System.out.println("잘했어"); } // 추상 메서드 abstract void play(); // hook 메서드 void runSomething() { System.out.println("꼬리 흔..

싱글톤 패턴 싱글톤 패턴은 인스턴스를 하나만 만들어 사용하기 위한 패턴이다. 오직 하나의 인스터스만을 만들고 그것을 계속 재사용한다. 싱클톤 패턴을 적용할 경우 의미상 두 개 이상의 객체를 가질 수 없으므로 아래의 세 가지가 필요하다. new를 실행할 수 없도록 생성자에 private 접근 제어자를 지정 유일한 단일 객체를 반활할 수 있는 정적 메서드가 필요 유일한 단일 객체를 참조할 정ㅈ거 참조 변수가 필요 예제 코드 Singleton.java package singletonPattern; public class Singleton { static Singleton singletonObject; //정적 참조 변수 private Singleton() {}; //private 생성자 // 객체 반환 정적 ..

프록시 패턴 vs 데코레이터 패턴 프록시 패턴은 실제 서비스 메서드의 결과값에 영향을 주지 않지만, 데코레이터 패턴은 클라이언트가 받는 반환값에 장식을 더한다. 프록시 패턴 제어의 흐름을 변경하거나 별도의 로직 처리를 목적으로 한다. 클라이언트가 받는 반환값을 특별한 경우가 아니면 변경하지 않는다. 데코레이터 패턴 클라이언트가 받는 반환값에 장식을 더한다. 예시 코드 IService.java package decoratorPattern; public interface IService { public abstract String runSomething(); } Service.java package decoratorPattern; public class Service implements IService{ p..

프록시란 프록시는 대리자, 대변인이라는 뜻을 가진다. 다른 누군가를 대신해 그 역할을 수행한다고 할 수 있다. 프록시가 없는 예제-runSomething() 메서드르 직접 호출 Service.java package proxyPattern; public class Service { public String runSomething() { return "Service!!"; } } ClientWithNoProxy.java package proxyPattern; public class ClientWithNoProxy { public static void main(String args[]) { Service service = new Service(); System.out.println(service.runSome..

어댑터를 번역하면 변환기(converter)라고 할 수 있다. 변환기의 역할은 서로 다른 두 인터페이스 사이에 통신이 가능하게 하는 것이다.(ex 플러그 전원과 핸드폰을 연결해주는 충전기-충전기가 변환기의 역할을 수행) ODBC/JDBC가 어댑터 패턴을 이용해 다양한 데이터베이스 시스템을 단일한 인터페이스로 조작할 수 있게 한다. JRE 또한 어댑터 패턴이다. 결국 어댑터 패턴은 개방 폐쇄 원칙(OCP)를 활용한 설계 패턴이라고 할 수 있다. 어댑터 패턴이 적용되지 않은 코드 ServiceA.java package adapterPattern; public class ServiceA { void runServiceA() { System.out.println("ServiceA"); } } ServiceB.j..

출처 : https://gmlwjd9405.github.io/2018/07/06/design-pattern.html

너무 잘 정리를 해주신 글이 있어서 링크 적음...!! https://defacto-standard.tistory.com/113 "고차원 모듈은 저차원 모듈에 의존하면 안된다. 이 두 모듈 모두 다른 추상화된 것에 의존해야 한다." - Pass "추상화된 것은 구체적인 것에 의존하면 안된다. 구체적인 것이 추상화된 것에 의존해야 한다." "자주 변경되는 구체 클래스에 의존하지 마라." 무슨소린지 1도 모르겠었지만(물론 지금도 모름) 자주 변하는 것보다는 자주 변하지 않는 것에 의존하도록 하라는 것 같다. 자주 변하는 것 vs 자주 변하지 않는 것(거의 변화가 없는 것) 자주 변하는 것 : 구체적인 것 자주 변하지 않는 것 : 개념이나 전략 등의 추상적인 것 예시1 : 자동차와 타이어 자동차 객체와 타이어..

단일 책임 원칙(SRP)와 인터페이스 분할 원칙(ISP) - 클래스를 나누느냐 인터페이스를 나누느냐 SRP와 ISP는 같은 문제에 대한 두 가지 다른 해결책이라고 볼 수 있다.프로젝트 요구사항과 설계자의 취향에 따라 선택될 수 있다. 하지만 특별한 경우가 아니라면 단일 책임 원칙을 적용하는 것이 더 좋은 해결책이라고 할 수 있다. 인터페이스 최소주의 원칙 인터페이스를 통해 메서드를 외부에 제공할 때 최소한의 메서드만 제공하라는 것이다. 상위 클래스는 풍성하게, 인터페이스는 작게 앞의 게시물 '상속과 인터페이스'에서 상위 클래스는 풍성할수록 좋고, 인터페이스는 작을수록 좋다고 언급했다. 이는 리스코프 치환 원칙(LSP)로 예를 들 수가 있다. LSP에 따라 하위 객체는 상위 객체인 척 할 수..