728x90
728x90
URI 란 인터넷에서 특정 자원을 나타내는 주소 값으로 해당 값은 유일하다. ex) 요청(req) : https://www.naver.com/resource/sample/1 응답(res) : na.test.pdf, na.test.docx URL 과 URI 를 헷갈리지 말자, URL 은 URI 의 하위 개념으로 인터넷 상에서의 자원, 특정 파일이 어디에 위치하는지 식별 하는 주소이며 요청(req) : https://www.naver.com/na.test.pdf 이런식으로 발행된다. URI 설계 원칙 1. 슬래시 구분자(/) 는 계층 관계를 나타내는 데 사용한다. https://naver.com/na/ja/cur/tes 2. URI 마지막 문자로 (/) 는 포함하지 않는다. https://naver.com/..
DIP 상위 모듈은 하위 모듈의 구현에 의존해서는 안되며, 하위의 모듈이 상위 모듈에 정의한 추상 타입에 의존 해야 한다. 카드 결제 시스템을 구축 현재 지원하는 카드는 신한 카드 추후에 우리 카드가 추가되어 결제를 구현 지속해서 카드가 추가 상위 모듈이란? 상위 모듈이란 상위 정책을 의미한다. 위의 요구사항에서는 카드 졀제라는 것이 상위 정책을 뜻한다. 하위 모듈이란? 하위 모듈이란 상위 정책에 따른 하위 정책을 말한다. 위의 요구사항에서 카드 결제라는 상위 정책이 있으면 신한 카드 결제라는 하위(세부) 정책이 있다. 추상 타입이란? 추상 타입은 인터페이스, 추상화 클래스를 의미한다. 상위 정책이 하위 정책에 의존하지 않고 추상 타입에 의존하라는 것은 카드 결제라는 상위 정책이 신한 카드 결제라는 하위..
LSP 서브 타입은 언제나 자신의 기반(상위) 타입으로 교체할 수 있어야 한다. LSP 는 OCP 를 받쳐주는 다형성에 관한 원칙을 제공한다. 상위 타입의 객체를 하위 타입의 객체로 치환해도 상위 타입을 사용하는 프로그램은 정상적으로 동작해야 한다. 리스코프 치환 원칙을 지키지 않으면 기능을 확장하기 어렵게 된다. 예를 들어 현대 자동차라는 클래스가 존재하고 현대 자동차를 상속받는 소나타와 그랜저, 아반떼 클래스가 존재한다. 소나타와 그랜저는 현대 자동차 클래스를 상속받기 때문에 현대 자동차가 기본으로 가지는 메서드와 속성값을 기본으로 가지기 때문에 LSP 를 만족한다. 하지만, 아반떼라는 클래스가 소나타와 그랜저에 대해 LSP 를 만족하냐에 대해선 위반한다고 말할 수 있다. 즉, LSP 는 다형성에 관..
개방 폐쇄 원칙(OCP) 개방 폐쇄 원칙은 자신의 확장에는 열려 있고, 주변의 변경에 대해서는 닫혀 있어야 한다는 뜻이다. 상위 클래스 또는 인터페이스를 중간에 둠으로써 자신은 변화에 대해서는 폐쇄적이지만, 인터페이스는 외부의 변화에 대해서 확장을 개방해 줄 수 있다. JDBC 와 Mybatis, Hibernate 등 JAVA 에서는 Stream(Input, Out) 에서 확인할 수 있다. 확장이란? 새로운 타입을 추가함으로써 새로운 기능을 추가할 수 있다. 즉, 확장이란 새로운 타입을 추가함으로써 새로운 기능을 구현한다. 확장에는 열려 있다는 것은 새로운 타입(클래스) 을 추가함으로써 기능을 확장하는 것이다. 변경이란? 확장이 발생했을 때 상위 레벨이 영향을 받지 않아야 한다. 확장(새로운 클래스) 이..
SOLID 란 프로그래머가 시간이 지나도 유지 보수와 확장이 쉬운 시스템을 만들고자 할 때 이 원칙들을 함께 적용할 수 있다. SOLID 원칙들은 소프트웨어 작업에서 프로그래머가 소스 코드가 읽기 쉽고 확장하기 쉽게 될 때 까지 소프트웨어 소스 코드를 리팩터링하여 코드 냄새를 제거하기 위해 적용할 수 있는 지침이다. 단일 책임의 원칙(SRP): Single Responsibillity Principle 단일 책임의 원칙의 키워드는 다음과 같다. 클래스는 단 한 개의 책임을 가져야 한다. 클래스의 변경하는 이유는 단 한개여야 한다. 누가 해당 메소드의 변경을 유발하는 사용자인가? 단일 책임의 원칙이라는 것은 이해하기 난해하다. 명확한 책임을 도출하기까지 시간이 걸리기 때문에 처음부터 단일 책임을 지켜서 설..
디자인 패턴이란 자주 사용하는 설계 패턴을 정형화하여 이를 유형별로 가장 최적의 방법으로 개발을 할 수 있도록 정해둔 설계 알고리즘과 유사하지만, 명확하게 정답이 있는 형태는 아니며, 프로젝트의 상황에 맞추어 적용이 가능하다. GOF 디자인 패턴 소프트웨어를 설계할 때는 기존 경험이 매우 중요하지만 모든 사람들이 다양한 경험을 가지고 있을 수는 없다. 이러한 지식을 공유하기 위해 나온 것이 GOF(Gang of Four) 의 디자인 패턴이며 객체지향 개념에 따른 설계 중 재사용할 경우 유용한 설계를 디자인 패턴으로 정리 해놓은 것이다. 총 23 가지의 디자인 패턴이 존재하며, 이를 잘 이해하고 활용한다면, 경험이 부족하더라도 좋은 소프트웨어 설계가 가능하다! 디자인 패턴의 장점 1. 개발자(설계자) 간의..