Component 단위의 설계 원칙배포 가능한 가장 작은 단위를 컴포넌트라고 정의하면 컴포넌트를 구성하기 위해서 SOLID 원칙을 잘 활용하여 설계 하는것이 중요하다.이후 배포 과정에서 여러 컴포넌트 또한 상호작용을 하며 하나의 어플리케이션을 구성하게 된다면 컴포넌트가 지향해야 하는 원칙또한 존재한다. REP : 재사용/릴리스 등가 원칙 Reuse/Release Equivalence Principle컴포넌트의 재사용 단위는 릴리스 단위와 같다.새로운 릴리스가 나온다는 소식을 통해서 개발자는 새로운 변경 사항을 살펴보고 기존 버전을 계속 사용할 것인지에 대한 여부를 결정하기 때문에 릴리스 절차에 적절한 공지와 함께 릴리스 문서 작성도 포함되어야 한다. 재사용을 쉽게 하기 위해서 하나의 컴포넌트로 묶인 클래..
배포 단위 : Component자바의 경우 JAR 파일, 이러한 배포 단위를 서로 링크하여 실행 가능한 단일 파일로 생성할 수 있으며 배포의 단위를 컴포넌트 라고 정의한다.그럼 "링크한다" 는 것은 배포 가능한 파일들을 단일 파일로 패키징하는 과정을 의미하고 이 과정을 통해서 프로그램의 배포 및 실행을 더욱 편리하게 만들 수 있다. 우리는 이 과정을 빌드도구 ex) Gradel, Maven 혹은 플러그인을 사용하여 수행한다.하지만 이 과정을 도와주는 위와 같은 툴은 링킹을 도와주는 도구 일 뿐 실제로 링커의 역할을 하지는 않는다. 링커 : Linker링커는 하나이상의 목적파일을 가져와서 이를 단일 실행 프로그램으로 병합하는 프로그램이다.주 기억장치에 메모리 확보 후 할당, 연결(Linking), 재배치(..
소스코드 레벨의 설계 원칙좋은 소프트웨어를 설계하기 위해서 실천해야 하는 원칙들을 SOLID 원칙이라고 한다.좋은 벽돌로 좋은 아키텍처를 정의하는 것으로 비유하곤 한다. 변경에 유연하고 이해하기 쉬우며 많은 소프트웨어 시스템에 사용될 수 있는 컴포넌트의 기반이 되는 많이 원칙들이 존재했고 시간이 지나면서 원칙들이 교체되거나 변경되었다.2000년대 초반에 오면서 안정화된 최종 버전이 나타났고 각 원칙의 첫 번째 글자들로 SOLID 라는 단어를 만들어 SOLID 원칙이 탄생했다. SRP : 단일 책임 원칙 Single Responsibility Principle단일 책임 원칙은 프로그램의 작은 수행단위를 모듈이라 하면 모듈은 단 하나의 일만 해야 한다는 의미다. 하지만 위와 같은 설명은 단일 책임 원칙의 핵..
Redis cache 상태를 저장하기 위해서 서버 자체에서 cache 를 구성해서 사용하는 경우도 있지만 오픈소스인 redis 를 이용해서 cache 환경을 구성하는 경우도 많다. 흔히 말해 redis를 사용하면서 얻을 수 있는 장점으로 여러가지 것들을 얘기하지만, 예를 들어 다양한 데이터 구조 혹은 캐싱기능(빠른 계산 결과를 위한) 메세지 브로커 기능 등 사실 이것들을 꼭 redis를 사용해서 구현해야 이득이라고 생각하지는 않는다. 실제로 다양한 데이터 구조는 커스터마이징하게 cache를 구현하는것이 좀더 이득인 경우도 있고 메세지 브로커또한 redis 를 사용할 필요는 없다. 심지어 캐싱기능을 위해서 redis를 사용한다는 것은 말도 안되는 이야기라고 생각한다. 내가 생각하는 redis 의 주 사용..
2장. 객체 생성과 파괴올바른 객체 생성 방법과 불필요한 생성을 피하는 방법, 객체의 소멸을 보장하고 소멸 전 수행해야 할 정리 작업을 관리하는 요령을 확인.아이템1. 생성자 대신 정적 팩터리 메서드를 고려하라클래스 생성자와는 별도로 정적 팩터리 메서드를 제공할 수 있는데 정적 팩터리 메서드를 통해 그 클래스의 인스턴스를 반환.정적 팩터리 메서드를 통한 장점은 다음과 같다특정 이름을 통하여 인스턴스를 반환 받을 수 있다.호출될 때마다 인스턴스를 새로 생성하지 않도록 할 수 있다.반환 타입의 하위 타입 객체를 반환할 수 있다.입력 매개변수에 따라서 다른 객체를 반환할 수 있다.정적 팩터리 메서드를 작성하는 시점에는 반환할 객체의 클래스가 존재하지 않아도 된다.하지만 정적 팩터리 메서드를 사용함에 있어서 단..
File과 MultipartFile의 변환 public File multipartFileToFile(MultipartFile multipartFile) throws IOException { File file = new File(multipartFile.getOriginalFilename()); multipartFile.transferTo(file); return file; } public MultipartFile fileToMultipartFile(File file) throws IOException{ String fieldName = "file"; FileItem fileItem = new DiskFileItem( fieldName, Files.probeContentType(file.toPath()),..
멀티코어 프로세서가 발전하면서 애플리케이션의 속도는 멀티 코어 프로세서를 얼마나 잘 활용할 수 있도록 소프트웨어를 개발하는가에 따라 달라질 수 있다. 여러가시 서비스를 동시에 제공하는 마이크로서비스 아키텍처의 선택이 지난 몇 년간 증가한것을 통해 이러한 추세를 확인할 수 있다. 위와 같은 서비스를 제공함에 있어서 동시간 여러 서비스의 응답을 기다리는 동안 연산이 블록되거나 귀중한 CPU 클록 사이클 자원을 낭비하고 싶지 않다면 동시성을 필요로 하는 상황 즉 조금씩 연관된 작업을 같은 CPU에서 동작하는 것 또는 애플리케이션의 생산성을 극대화 할 수 있도록 코어를 바쁘게 유지하는 것이 목표라면 원격 서비스나 데이터베이스 결과를 기다리는 스레드를 블록함으로 연산 자원을 낭비하는 일 등을 피해야만 한다. 위와..
객체지향을 조금이라도 자세히 공부했다면 상속은 객체지향의 가장 중요한 특징중 하나인 캡슐화를 방해하는 요소라는 것을 알 수 있을 것이다. 그럼에도 불구하고 상속또한 객체지향의 대표적인 특징으로써 존재하고 있다. 상속을 이용하여 코드를 재사용함으로써 중복코드를 없애는 방향으로 개발을 하고 있지만 상속의 본질적 목표는 중복코드를 제거하는 것이 아니다. 서브클래싱 과 서브타이핑 상속을 사용하는 목적을 크게 두 가지로 구분해서 확인 할 수 있다. 첫 번째는 위에서 설명한 것 처럼 중복코드를 줄임으로써 코드의 재사용 성을 높이기 위함이다. 이것이 서브클래싱의 개념이다. 하지만 첫 번째보다 더 중요한 두 번째 목적은 타입 계층을 구현하여 서브클래스가 수퍼클래스를 대체하기 위함이다. 이것이 서브타이핑의 개념이다. 부..
함수형 프로그래밍은 명령형 프로그래밍의 패러다임에서 벗어나 선언형 프로그래밍의 패러다임에 발을 딛는것을 의미한다. 구체적으로 어떤 방식으로 할 것인지 how 가 아닌 무엇을 할 것인지 what 에 집중하는 프로그래밍 설계 패러다임을 의미하는 것이다. 프로그래밍은 항상 유지보수의 가능성을 열어두고 설계를 진행해야 한다. 노련한 개발자들 사이에서는 synchronized 라는 키워드의 사용 여부에 따라서 해당 시스템이 함수형 프로그래밍의 패러다임을 적절히 사용했는지를 판단한다는 말이 있을 정도로 함수형 프로그래밍에 대한 필요성이 중요시 된다. 함수형 프로그래밍을 사용 한다는 것은 시스템의 각 부분이 상호 의존성을 가르키는 결합성과 시스템의 다양한 부분이 서로 어떤 관계를 갖는지 가르키는 응집성이라는 소프트웨..
자바로 프로그램을 개발하면서 NullPointerException 을 한번쯤은 무조건 겪는다. 모든 상황에서 null 이라는 표현을 사용하면서 치뤄야 할 당연한 대가이면서 어떻게 해결 할 수 없는 것이라고 생각 할 수도 있다. 하지만 명령형 프로그래밍을 통해서 null을 처리하고 싶다면 관점을 조금 다르게 접근하는 방법이 필요하다. 값 이 없다. 기존의 프로그래밍은 값이 없는 상태를 null 로 표현해서 처리 했다. 하지만 null 처리는 NullPointExceptions을 모든상황에서 완벽하게 대응할 수 있는 방법이 아니다. 개발자가 실수로 null 처리를 하지 않았고 개발을 진행하는 과정에서 운이 좋게 NullPointException 이 터지지 않았다고 해서 실제 서비스를 제공 할 때도 NullP..
