Service Locator Pattern, 서비스 로케이터 패턴

이 글은 서비스 로케이터 패턴에 대해서 다루는 글입니다. 이 글에서 다루고자 하는 내용은 세 가지로 첫 번째는 서비스 로케이터에 대한 소개와 예제코드를 이용한 설명이고, 두 번째는 의존성 주입을 예제 코드를 통해서 설명한 후 서비스 로케이터와 비교하는 것이고, 세 번째는 제가 서비스 로케이터를 사용하는 방법을 소개하는 것입니다. 서비스 로케이터 패턴(Service Locator Pattern)이란? Service Locator 패턴은 마틴 파울러가 블로그 글에서 제시한 패턴입니다. 이 패턴의 목표는 모듈화 수준을 높이는 것입니다. 클라이언트와 인터페이스사이의 의존성을 제거하는 방식으로 모듈화 수준을 높이는데요. 우리는 유연한 코드를 짜기 위해서 인터페이스를 자주 사용합니다. 그렇지만 인터페이스를 사용하다..

Computer Science 2021.08.23 0

플러터에서 위치정보 사용하는 법, How to use location in flutter

이 글은 로케이션, Location 패키지를 통해서 사용자의 위치정보를 사용하는 법을 다룬 글입니다. 많은 어플리케이션의 기획에서는 위치정보를 필요합니다. 예를 들어, 근처에 있는 ATM기의 위치나, 음식점의 정보를 알기 위해서는 내 위치를 알아야하죠. 사용자가 본인의 위치정보를 사용할 수 있게 하려면 어떻게 해야할까요? Location 사용자가 본인의 좌표를 얻기 위해서 사용하는 패키지가 바로 로케이션, location입니다. pubspec.yaml에서 디펜던시를 추가한 다음 설치를 진행합니다. dependencies: location: ^4.2.0 권한 요청 먼저 디바이스의 위치 정보를 얻기 위해서는 권한, Permission을 받아야합니다. Android project_dir/android/app/..

Flutter 2021.08.25 2

코틀린 스프링을 사용하는 이유

코틀린 스프링을 백엔드 개발할때 쓰는 이유를 적은 글을 쓰며 백엔드 개발을 시작할때 최근에 가장 많이 논의되는 언어가 코틀린과 타입스크립트라고 생각을 하고 있는데, 개인적으로는 서로의 장단점이 다르다고 느껴져서 이런 글을 적어두고 싶었다.특히 Nest.js에 익숙하신 분들에게 도움이 되길 바라며 글을 쓴다. 글의 접근 방식 이 글은 코틀린과 다른 언어를 많이 비교하면서 진행될 예정이다. 자바랑 비교하게 되는 내용도 있고, 개인적인 경험을 빗대기 위해서 Dart같은 약간 생소할 수 있는 언어도 사용했다. 글의 내용 코틀린에 대한 소개 코틀린의 강점이라고 느껴지는 부분 백엔드 개발에서 코틀린을 쓰는 이유 코틀린이란? 코틀린. 모던 랭귀지의 대표적인 주자중 하나이다. 대표적인 삼대장을 뽑아보라고 하면 Rust..

Kotlin 2023.11.20 0

ElasticSearch 인덱스 필드 길이 제한 늘리기

안녕하세요. 정우현입니다. 오늘은 위의 에러를 해결하는 방법을 적은 글을 씁니다. 원인 로그스태시를 통해서 서버 로그를 엘라스틱서치에 꾸준히 넣는데, 로그의 길이가 긴 경우의 로그가 정상적으로 저장이 안되고 있는 듯해서 문제를 찾아봤더니 필드의 길이제한을 넘어가는 경우 저장을 할 수 없었습니다. 해법 그래서 이 문제를 해결하기 위해서 방법을 찾아봤습니다. 첫 번째 방법은 인덱스 하나에 대하여 설정을 변경하여 하나의 인덱스에만 필드의 길이제한을 변경하는 것이고, 두 번째 방법은 템플릿을 적용하여 특정 조건의 인덱스에 대해서 필드의 길이제한을 변경하는 방법입니다. 첫 번째 방법은 PUT /_settings { "index.mapping.total_fields.limit": 2000 } 이라는 명령을 키바나의..

ELK 2020.02.28 0

테스트 하기 좋은 코드, 좋은 테스트 코드

이 글을 쓰는 이유 좋은 테스트 코드, 테스트하기 좋은 코드에 대해서 고민하다가 든 생각을 공유해보고자 적습니다. 테스트 하기 좋은 코드 1. 블랙박스 테스트할때 비즈니스 로직의 결과를 단언할 수 있는 코드가 테스트 하기 편하다. 비즈니스로직과 persist 작업이 한번에 이뤄지고 "OK"나 Unit 과 같은 결과물만 내놓으면 stubbing으로 내용이 잘 돌아갔음을 증명해야하고, 이렇게 되면 레포지토리 레이어까지 내려가서 테스트해야한다. "버그 없음"은 테스트 코드를 통해서 증명할 수 있는게 없기 때문에, return을 받아서 결과를 볼 수 있도록 되어있는게 편한 것 같다. 파라미터로 넣은 객체를 확인하는 방법도 있지만, 객체는 Immutable하게 유지해주는 편이 좋기 때문에 비즈니스 로직은 묶어서 ..

Kotlin 2024.01.15 0