앞으로 디자인패턴에 대해 설명하기 앞서, SOLID 원칙을 먼저 살펴볼게요! (디자인패턴의 장점, 필요성 등을 설명할 때 꼭 필요한 원칙이라고 생각합니다)시간이 지나도 유지보수와 확장이 쉬운 소프트웨어를 만드는데 사용되는 원칙a.k.a. 객체지향 5대 원칙SOLID는
>
이미 구현된 무언가를 사용해야하는데 현재 개발 요구사항과 인터페이스가 맞지 않는다.혹은, 여러 video player가 있다. 모든 플레이어들은 play, pause, playback 등 유사항 기능을 제공하지만 완전 동일한 인터페이스를 제공하진 않는다.모든 타입의 v
인스턴스가 절재적으로 한 개만 존재하는 것을 보증해야 하는 경우매번 새로운 객체를 생성하는 것이 객체 로딩 시간으로 인해 성능이 안 좋아지는 경우고정된 메모리 영역을 얻어 한 번의 new로 인스턴스를 사용하자!싱글톤 패턴이란,어떤 클래스가 최초 한 번만 메모리를 할당하
https://www.geeksforgeeks.org/builder-pattern-in-java/
https://refactoring.guru/design-patterns/decorator
https://refactoring.guru/design-patterns/command
지도앱을 구현하고 있다. 처음엔 출발지부터 도착지까지의 경로를 "걸어서"가는 요구사항만 있었다. 그 후에 "대중교통", "자동차" 이런 선택지가 추가되었다. 처음부터 switch case문을 이용해 Navigator 클래스에 모든 알고리즘을 구현했다면 어떻게 될까?한
디자인패턴은 아니지만 이 시리즈가 가장 적합한 거 같아서 여기에 넣었습니다! 상속 Inheritance, 기존 클래스의 속성을 물려 받는 것 is-a 관계 위임 Delegation, 책임을 다른 객체에 전달하는 것 has-a 관계 re-exporting method 상속의 대체방안이 될 수 있음 다른 클래스의 instance를 가져 그 instance에 m...
전체-부분 구조를 갖는 경우, 트리로 이를 표현할 수 있다.리프 노드와 브랜치를 구분해 개발을 진행하는 경우, if (leaf) else 이런식으로 구현하게 되면 복잡성이 높아지고 에러가 발생하기 쉬워진다!이런 케이스는 어떻게 구현하는 게 좋을까?Common Inter
이것도 디자인패턴은 아니지만..! 패턴 다이어그램에 자주 쓰이니까 이 시리즈에 넣었습니다!둘 다 part-whole을 나타내는 Association 관계를 특수하게 나타낸 것unidirectional associationplayer(part) -> team(whole)