본문 바로가기

분류 전체보기333

설계원칙 - SOLID(DIP) - 이 글은 로버트 C.마틴의 Clean Architecture를 기반으로 작성되었습니다. (가능하면 책을 읽어보는것을 추천한다.) - 추상팩토리 패턴:https://ko.wikipedia.org/wiki/%EC%B6%94%EC%83%81_%ED%8C%A9%ED%86%A0%EB%A6%AC_%ED%8C%A8%ED%84%B4 - 개요 DIP는 의존성 역전 원칙이다. 유연성이 극대화된 시스템이란 소스코드 의존성이 추상에 의존하며 구체에는 의존하지 않는 시스템이다. 단어가 어렵더라도 천천히 살펴보자. 우리가 좋아하는 스프링 웹 소스를 떠올려 보자. Controller에서 Service를 호출할 때, Service에 대한 인터페이스를 참조해야지 해당 인터페이스(추상클래스)를 구현한 구체 클래스를 참조해서는 안된다.. 2021. 2. 10.
설계원칙 - SOLID(ISP) - 이 글은 로버트 C.마틴의 Clean Architecture를 기반으로 작성되었습니다. (가능하면 책을 읽어보는것을 추천한다.) - 로버튼 C.마틴, ISP vs SRP: https://twitter.com/unclebobmartin/status/996739060348653568 - 개요 위와 같은 다이어그램에서 Employee는 searchByEmployee()를 통해서 제품검색을 하며, Customer는 searchByCustomer()를 그리고 CEO는 report를 보기 위해 generateReport() 함수를 사용한다. Employee, Customer, CEO는 1개의 메소드씩만 사용하지만 ProductService에 함수를 다 정의해놓고 의존하다보니 자신이 사용하지 않는 다른 두 메소드.. 2021. 2. 10.
설계원칙 - SOLID(LSP) - 이 글은 로버트 C.마틴의 Clean Architecture를 기반으로 작성되었습니다. (가능하면 책을 읽어보는것을 추천한다.) - https://ko.wikipedia.org/wiki/%EC%A7%81%EC%82%AC%EA%B0%81%ED%98%95 - 개요 바바라 리스코프가 하위 타입에 대해 정의한 원칙이다. S 타입의 객체 o1, T 타입의 객체 o2가 있고, T 타입을 이용해서 정의한 프로그램 P에서 o2 대신 o1을 치환해도 P의 행위가 변하지 않는다면, S는 T의 하위타입이다. - LSP 예제 모델들을 관리하는 어플리케이션을 살펴보자. Model 클래스가 있다. 실세계에서는 상당히 많은 메소드가 있겠지만 이 예제에서는 모델 코드를 반환하는 getModelCode() 메소드만 있다고 가정한다.. 2021. 2. 10.
설계원칙 - SOLID(OCP) - 이 글은 로버트 C.마틴의 Clean Architecture를 기반으로 작성되었습니다. (가능하면 책을 읽어보는것을 추천한다.) - https://en.wikipedia.org/wiki/Open%E2%80%93closed_principle - 개요 소프트웨어 개체(클래스, 모듈, 함수)는 확장에는 열려있어야 하며, 변경에는 닫혀 있어야 한다. 즉, 개체의 행위는 확장할 수 있어야 하지만 이때 개체를 변경해서는 안된다. 만약 요구사항 확장하는데 기존 소프트웨어를 많이 수정해야 한다면 안된다는것이다. - 예제 특정 데이터를 가공하여 웹 페이지에 보여주는 시스템이 있다고 하자. 이때 갑자기 이해관계자가 PDF나 Excel 로 보여줄 수 있게 기능을 추가해달라고 한다. 이때 소스코드를 얼마나 변경해야 할까?.. 2021. 2. 10.
설계원칙 - SOLID(SRP) - 이 글은 로버트 C.마틴의 Clean Architecture를 기반으로 작성되었습니다. (가능하면 책을 읽어보는것을 추천한다.) - 개요 단일 책임 원칙은 가장 많은 오해를 사고 있는 원칙이다. 이름만 보면 마치 하나의 모듈은 하나의 일만 해야하는 것처럼 느껴진다. 하지만 이는 오해이다. 하나의 모듈은 하나의 액터(사용자 및 이해관계자)에 대해서만 책임져야 한다. 모듈이란 보통의 경우엔 소스파일이다. SRP를 위반하는 원칙들을 살펴보면서 SRP를 이해해보자. - 징후: 우발적 증복 급여 어플리케이션에서 Employee 클래스가 있고, 해당 클래스에서 calculatePay(), reportHours(), save() 메소드를 제공한다고 해보자. 이 클래스는 SRP를 위반한다고 할 수 있는데, diag.. 2021. 2. 10.
프로그래밍 패러다임 - 함수형 프로그래밍 - 이 글은 로버트 C.마틴의 Clean Architecture를 기반으로 작성되었습니다. (가능하면 책을 읽어보는것을 추천한다.) - 예제 함수형 프로그래밍은 예제를 살펴보는것이 이해하기가 수월하다. 0~24 까지 제곱을 출력하는 프로그램을 작성해보자. Java 1.8 이전까지는 아래처럼 코드를 작성하였다. public static void main(String[] args){ for(int i = 0; i < 25; i += 1) { System.out.println(i*i); } } 하지만 Java 1.8 부터는 람다(익명함수)를 지원하면서 아래와 같이 코드를 작성할수도 있다. public static void main(String[] args){ IntStream.range(0, 25) .map(.. 2021. 2. 10.
프로그래밍 패러다임 - 객체지향 프로그래밍 - 이 글은 로버트 C.마틴의 Clean Architecture를 기반으로 작성되었습니다. (가능하면 책을 읽어보는것을 추천한다.) - 객체지향이란? 객체지향 (Object Oriented)은 프로그래머라면 당연히 들어봤을법한 너무도 유명한 개념이다. 객체지향이란 무엇인가? 어떤 사람들은 데이터와 함수의 조합이라고 정의한다. 하지만 이렇게 정의하기엔 너무 단순하고 객체지향 이전에도 데이터 구조를 함수와 조합해서 사용해왔다. 또는 실제 세계를 모델링하는 방법이라고 정의한다. 이 정의는 앞의 정의보다 더 심오하긴 하지만 너무나 모호하다. 보통 OO의 정의를 설명하기 위해 캡슐화, 상속, 다형성을 언급하기도 하는데 이는 하나씩 자세히 살펴볼 필요가 있다. - 캡슐화 OO정의에서 캡슐화를 언급하는 이유는 OO .. 2021. 2. 10.
프로그래밍 패러다임 - 구조적 프로그래밍 - 이 글은 로버트 C.마틴의 Clean Architecture를 기반으로 작성되었습니다. (가능하면 책을 읽어보는것을 추천한다.) - 문제인식 및 아이디어 데이크스트라는 아무리 간단한 프로그램이라도 컴퓨터에게 명령을 하려면 디테일한 세부사항까지 지시를 해야하기 때문에 프로그램이 의도한대로 동작하는것이 힘들다는 문제 인식을 하였다. 데이크스트라는 수학자가 유클리드 계층구조를 사용하는 방식을 프로그래머도 사용할 수 있다고 믿었다. 이 연구를 진행하면서 모듈을 재귀적으로 분해하는 과정에서 goto 문장이 방해가 된다는 사실을 발견하였다. 모듈을 재귀적으로 분해할 수 없다면, 알고리즘 풀이방법중 하나인 분할정복을 사용할 수 없게 된다. 반면 문제가 되지 않는 goto문의 사용방식이 있었는데, 이는 분기(if/.. 2021. 2. 10.
프로그래밍 패러다임 - 개요 - 이 글은 로버트 C.마틴의 Clean Architecture를 기반으로 작성되었습니다. (가능하면 책을 읽어보는것을 추천한다.) - https://ko.wikipedia.org/wiki/%EA%B5%AC%EC%A1%B0%EC%A0%81_%ED%94%84%EB%A1%9C%EA%B7%B8%EB%9E%98%EB%B0%8D - 패러다임의 개요 프로그래밍의 대표적인 패러다임에는 구조적 프로그래밍, 객체지향 프로그래밍, 함수형 프로그래밍이 있다. 이번 절에서는 3가지 패러다임에 대한 간략한 개요를 알아보도록 한다. - 구조적 프로그래밍 최초로 적용된 패러다임이다.(최초로 만들어진 패러다임은 아니다.) 데이크스트라는 무분별한 goto 문이 프로그램 구조에 해롭다는 사실을 제시하였다.(https://ko.wikip.. 2021. 2. 10.
UML - 유스 케이스 - 개요와 내용 - 이 글은 UML Distilled (마틴 파울러)책을 기반으로 작성하였습니다. - 유스 케이스 유스 케이스는 시스템의 기능적인 요구사항을 잡아내는 기술이다. 유스케이스는 시스템과 사용자간의 교류를 기술한다. 유스 케이스를 곧바로 판별해내는것은 사실 어려운일이다. 보통은 시나리오를 생각해본 뒤 유스케이스를 식별한다. 시나리오는 사용자와 시스템간의 교류를 단계적으로 나타낸것이다. 예를 들어 온라인 쇼핑몰에서 물건을 산다면 시나리오는 아래와 같다. 고객은 상품 목록을 보고 원하는것을 선택하여 장바구니에 담는다. 물건을 구매하기 위해 배송지 및 신용카드 정보를 기술한다. 시스템은 신용카드 승인을 확인하고 물건 구매 확정을 한다. 그리고 그 결과를 이메일로 발송한다. 위의 시나리오는 개발자가 구현하기 좋은 전.. 2021. 2. 10.

티스토리툴바