퍼사드 패턴퍼사드 패턴은 그 원리와 구현이 매우 간단할 뿐만 아니라 사용 대상이 비교적 명확하기 때문에 주로 인터페이스 설계에 사용된다.퍼사드 패턴은 서브 시스템에 대한 통합 인터페이스 세트를 제공하고, 하위 시스템을 더 쉽게 만들기 위한 상위 통합 인터페이스를 제공한다.생각해보기어댑터 패턴은 호환되지 않는 인터페이스를 연결하는 설계 이념인 반면, 퍼사드 패턴은 결합도를 낮추기 위해 로직들을 결합해 진입점을 단순하게 하고, 결합한 로직들을 캡슐화를 한다는 설계 이념으로 차이가 있다.복합체 패턴복합체패턴은 객체지향 설계의 합성과는 전혀 관계가 없다. 주로 트리 구조의 데이터를 처리하는 데 사용된다.복합체 패턴은 일종의 부분-전체 계층구조로 인식하는 트리 구조로 구성된 객체 컬렉션이며, 복합체 패턴을 통해 ..

프록시 패턴종류인터페이스 기반의 프록시 패턴상속 기반의 프록시 패턴리플렉션 기반의 프록시 패턴 → 회사에서 썼던 사용 사례 다시 찾아보기실제로 Spring AOP의 기본 구현 원칙은 동적 프록시를 기반으로 한다. 사용자는 프록시 클래스를 생성할 클래스를 구성하고 원본 클래스의 주요 비즈니스 코드가 실행되기 전과 후에 수행할 추가 기능을 정의한다. Spring은 이러한 클래스에 대해 동적 프록시 클래스를 생성해주고 원본 클래스의 객체를 JVM의 동적 프록시 클래스 객체로 대체한다. 코드에서 원본 클래스를 실행해야 하는 메서드는 프록시 클래스를 실행하는 메서드로 대체된다. -p.318https://docs.spring.io/spring-framework/docs/4.3.14.RELEASE/spring-fra..

싱글턴 패턴어떤 클래스의 객체 또는 인스턴스를 단 하나만 생성할 수 있다면, 해당 클래스는 싱글턴 클래스이며, 이 디자인 패턴을 싱글턴 패턴이라고 한다.비즈니스 개념의 관점에서 클래스에 시스템에 한 번만 저장되어야 하는 데이터가 포함된 경우 해당 클래스는 싱글턴 클래스로 설계해야 한다.싱글턴 패턴의 구현싱글턴 패턴을 구현할 때 중점적인 4가지 조건생성자는 new 예약어를 통한 인스턴스 생성을 피하기 위해 private 접근 권한을 가지고 있어야 한다.객체가 생성될 때 스레드 안전성을 보장하는지 확인해야 한다.지연 로딩을 지원하는지 여부를 확인해야 한다.getInstance() 함수의 성능이 충분해야 한다.스레드 전용 싱글턴 패턴스레드에서 유일한 것과 프로세스 내에서 유일한 것의 차이점프로세스에서 유일하다..

명명과 주석전역 변수와 같이 범위가 큰 변수의 경우 긴 이름을 사용하는 것이 좋다. - p180전역 변수일수록 오히려 더 의미 있는 내용을 사용해야 하기 때문에, 길어지더라도 꼭 의미를 다 담는 것이 좋다고 생각한다.어떤 사람들은 주석이 보충 정보만 제공하면 된다고 생각하기도 한다. 하지만 다음 세 가지 이유를 들어 이러한 견해에 동의하지 않는다. - p182주석에는 이름보다 훨씬 더 많은 정보를 담을 수 있다.주석은 설명과 시연의 역할을 한다.요약 주석은 코드의 논리를 더 명확하게 할 수 있다.가끔 가다 보면 주석이 없으면, 다음날에도 나의 코드를 까먹는 나 자신을 발견할 수도 있을 것이다. 논리가 간단한 코드라면 너무나 간단하게도 파악을 하겠지만, 논리가 간단하지 않다면 나조차도 까먹을 수 있으니 주..

단일 책임 원칙단일 책임 원칙(SRP)이란 클래스와 모듈은 하나의 책임 또는 기능만을 가지고 있어야 한다는 설계 원칙단일 책임 원칙이 설명하는 대상에는 클래스와 모듈이라는 두 가지 종류가 있다.모듈을 클래스보다 더 추상적인 개념으로 간주하고 클래스를 일종의 모듈로 간주하는 것모듈을 좀 더 포괄적인 범위의 대상으로 놓고, 여러 클래스가 하나의 모듈을 구성한다고 간주하는 것단일 책임 여부를 결정하기 위해 사용되는 몇 가지 결정 원칙클래스에 코드, 함수 또는 속성이 너무 많아 코드의 가독성과 유지 보수성에 영향을 미치는 경우 클래스 분할을 고려해야 한다.클래스가 너무 과하게 다른 클래스에 의존한다면, 높은 응집도와 낮은 결합도의 코드 설계 사상에 부합하지 않으므로 클래스 분할을 고려해야 한다.클래스에 priv..

내용 정리전역 변수와 전역 메서드의 남용모든 상수를 Constant 클래스로 통합할 경우 생기는 문제점코드의 유지 보수성에 영향을 미친다. 상수를 추가할수록 점점 코드의 몸집은 불어나고, 수정을 하며 충돌을 일으킬 것이다.코드 컴파일의 시간을 증가 시킨다. Constant 클래스를 수정할 때마다 Constant 클래스에 종속된 다른 클래스가 매번 다시 컴파일되어 불필요한 컴파일 시간을 낭비한다. 대규모 프로젝트는 컴파일 하는데 몇 분 또는 수십 분이 소요될 수도 있고, 개발 과정에서 단위 테스트가 실행 될 때마다 컴파일이 실행되기 때문에 긴 컴파일 시간은 개발 효율성에도 큰 영향을 미친다.코드의 재사용 가능성에도 영향을 미친다. 이 프로젝트에서 개발한 클래스를 다른 프로젝트에서 재사용 하려고 할 때, 이..