본문 바로가기

분류 전체보기

(84)
오브젝트 9장 - 유연한 설계 8장에서는 다양한 의존성 관리 기법들을 소개했음. 9장에서는 원칙이라는 관점에서 정리 개방-폐쇄 원칙 컴파일타임 의존성을 고정시키고 런타임 의존성을 변경하라 컴파일 타임 의존성 = 인터페이스나 추상 함수에 의존 런타임 의존성 = OCP로 가능성을 확장하고 수정할 수 있는 구조 추상화가 핵심이다 추상화에 의존하는 것 변경에 의한 파급효과를 최대한 피하기 위해서는 변하는 것과 변하지 않는 것이 무엇인지를 이해하고 이를 추상화의 목적으로 삼아야만 한다. 생성 사용 분리 객체에 대한 생성과 사용을 분리해야 한다. FACTORY 추가하기 객체 생성과 관련된 지식이 client에게 까지 새어나가기를 원하지 않는다. 객체 생성과 관련된 책임만 전담하는 별도의 객체 = FACTORY Client는 오직 사용과 관련된 ..
오브젝트 8장 - 의존성 관리하기 객체지향 설계의 핵심은 협력을 위해 필요한 의존성은 유지하면서도 변경을 방해하는 의존성은 제거하는 데 있다. 의존성 이해하기 변경과 의존성 의존성은 실행 시점과 구현 시점에 서로 다른 의미를 가진다. 구현 시점 → 인터페이스에 의존해야함 실행 시점 → 각각의 구현체에 의존해야함 (서로 다른게 유연하게 작성된 애플리케이션) 두 요소 사이의 의존성은 의존되는 요소가 변경될 때 의존하는 요소도 함께 변경될 수 있다는 것을 의미한다. 의존성 전이 의존성 - 의존하고 있는 대상의 변경에 영향을 받을 수 있는 가능성 직접 의존 - 직접 의존하는 것 간접 의존 - 한 단계 거치는 것, 해당 코드를 수정했을 때, 그것을 사용하는 코드들이 영향 받을 가능성이 있음 런타임 의존성과 컴파일타임 의존성 컴파일에는 인터페이스에..
오브젝트 7장 - 객체 분해 문제 해결에 필요한 요소의 수가 단기 기억의 용량을 초과하는 순간 문제 해결 능력은 급격하게 떨어지고 만다. → 인지 과부하 큰 문제를 작은 문제로 나누는 것 ⇒ 분해 추상화를 더 큰 규모의 추상화로 압축시킴으로써 단기 기억의 한계를 초월할 수 있다. 프로시저의 추상화와 데이터 추상화 시스템을 분해하는 방법으로 둘 중 하나를 선택해야함 프로시저 추상화 → 기능 분해의 길, 알고리즘 분해 데이터 추상화 → 타입 추상화(추상 데이터 타입), 데이터를 중심으로 프로시저를 추상화(객체지향) 객체지향이 전통적인 기능 분해 방법에 비해 효과적이라고 하는 이유는 무엇일까? (전통적인 기능 분해 방법) → 객체지향 분해 방법에 이르는 좌절과 극복의 역사 프로시저 추상화와 기능분해 전통적인 기능 분해 방법은 하향식 접근..
reverse proxy 서비스 운영에 있어서 필수적인 proxy server 프록시 종류가 여러가지가 있을 것 입니다. 스프링의 프록시나, 디자인 패턴중에 프록시 패턴도 있을 것이고, reverse proxy는 네트워크 프록시 입니다. 서버측에 가까이 있는 프록시를 리버스 프록시라고 합니다. 클라이언트로 부터 서버의 정보를 숨겨주고, 요청을 어느 서버로 보내줄지에 대하여 로드밸런싱 작업을 해줍니다. 마지막으로, 전형적인 프록시 서버와 같이 캐싱을 해줍니다. reverser proxy에 반대되는 개념인 forward proxy는 보통, 글로벌 서비스에서 다른 국가들에게 빠른 서비스를 제공하기 위해 사용됩니다. 캐싱을 제공하며, 서버로 부터 클라이언트의 정보를 가려줍니다.
transaction isolation level transaction isolation level에는 read uncommitted, read committed, non-repeatable read, serializable이 있습니다. read uncommitted는 트랜잭션이 두개가 동시에 실행중이라고 가정했을 때, 한 곳에서 수정한 entitiy를 커밋하기도 전에 다른 트랜잭션에서 값을 읽어올 때, 수정된 값을 받아올 수 있습니다. 이런 문제를 dirty read라고 합니다. read committed는 commit 된 entitiy만 읽어오므로, dirty read의 문제는 해결하였습니다. 하지만, 트랜잭션을 동시에 실행중이고 A트랜잭션에서 select, B트랜잭션에서 update, A트랜잭션에서 select를 했다고 했을때, 동일한 A 트랜잭션..
스프링에서 다른 서버와 비동기로 통신하는 방법 기존에 다른 서버와 통신하는 방법은, 만약 rest api였다면 restTemplate을 사용하면 됐습니다. 비동기적으로 통신하려면 asyncRestTemplate을 사용하면 됩니다. 그러나, 기본적으로 blocking io를 사용하고 있기 때문에, non-blocking io를 사용해야 진정으로 성능이 나올 수 있습니다. 그렇게 asyncRestTemplate을 사용하면, listenableFuture가 결과로 나오게 되는데, 그것에 callback으로 어떤 처리를 할지 작성할 수 있습니다. 아니면 그것을 completable future로 감싸서 사용을 하면 됩니다. asyncRestTemplate 뿐만 아니라, completableFuture를 사용하는 경우는 모두 비동기적으로 통신할 수 있습니다...
layered architecture 레이어드 아키텍처는 애플리케이션 개발에 있어서 프레젠테이션 레이어, 서비스 레이어, 레포지토리 레이어, 그리고 DB레이어로 나누어 개발하는 것입니다. 이런 것에 장점은, 가독성과 유지보수에 좋고, OCP 원칙을 지키기 쉽게 됩니다. 예를 들어 orcale에서 mysql로 DB를 변경한다고 하면, datasource를 oracle로 변경하고, 레포지토리를 oracle용으로 만들어서 repository bean을 교체해주면 됩니다. 기존 코드의 변경없이 쉽게 확장할 수 있습니다. 그리고 프레젠테이션 레이어는 자바의 캡슐화 역할을 해줍니다. 그래서 api역할을 해줍니다. 오직 어떤 요청이 들어왔을 때, 어떤 응답을 돌려준다는 정의만 해놓으면 됩니다. 내부 구현, implementation은 서비스로직에서 담당..
[git] merge vs rebase merge: 브랜치를 합치는데 사용됩니다. 여기서 rebase를 사용하면 로그가 깔끔해집니다. 다시말하면, 일반적으로 develop 브랜치에서 기능을 개발할때, feature 브랜치를 만들고, 개발이 완료된 후 브랜치를 merge 합니다. 그러나 develop 브랜치에도 그사이에 개발이 될 수 있습니다. 그런 경우, feature에서 develop으로 merge를 하면, feature에서 commit 한 log 뿐만 아니라, 둘 사이에 문제를 없애기 위한 merge commit log가 추가됩니다. 그러나, rebase를 하고 merge를 하는 경우, merge에 관한 commit log가 필요없어집니다. rebase를 하면 feature의 base 가 develop의 최신 브랜치로 바뀌게 되어, 자동으..
offset과 consumer group kafka의 offset이란? partition에 붙어있는 레코드 번호. 레코드 번호는 0번 부터 시작하여 레코드가 쌓일 때마다 하나씩 증가한다. consumer offset: 컨슈머가 읽은 offset번호. consumer offset이 10번이면 이제 11번 레코드부터 가져가면 된다. committed offset: 컨슈머가 커밋한 offset번호. consumer가 읽는 도중에 commit할 수 있고, 만약 consumer가 장애시, 재부팅하여 해당 파티션을 다시 읽기 시작할때, committed offset 이후의 값들을 읽는다. consumer group: 컨슈머들의 그룹. 하나의 토픽을 컨슘할때, 모든 파티션을 컨슈머 그룹에 있는 컨슈머들끼리 나누어 소비하도록 한다. 컨슈머 그룹에 있는 컨슈머..
http 0.9~ 3 0.9 메서드 종류와 url 1.0 헤더 추가 1.1 여러개를 보낼 수 있는 파이프라이닝 일정시간 동안 connection을 유지함 2.0 항상 같은 헤더를 보내면 문제가 되니까 두번째 보내는 같은 헤더를 압축 스트림을 사용하여 결과값을 한번만 받아도 되도록 수정 (요청과 응답의 다중화) (리소스간 우선 순위 설정) (Server push) 3.0 udp기반의 quic을 사용하여, (지연 불가피)를 극복하고 Tcp 수준의 신뢰성을 확보 기존에는 하나가 잘못되면 처음부터 다시보내야했는데, 이제는 잘못된 부분 하나만 다시 보내게 하게 수정 uuid를 사용하여 server에서 저장할 필요없이 기존의 문제인 파이프라이닝 문제가 여러개를 보냈을 때, 오래걸리면 나머지가 오래걸리는 문제를 해결 TLS 기본 적용 (..