작디 작은 나만의 라이브러리/BridgeApi7 [신입 개발자의 '작디 작고 작디 작고 자그만' 첫 라이브러리 제작기] Fin. Bridge-Api의 실제 적용과 개선 효과 안녕하세요!드디어 Bridge-Api 시리즈의 마지막 글을 작성하게 되었습니다.이번 글에서는 Bridge-Api를 실제 프로젝트에 적용하면서 경험한 개선 효과들을 공유해보려고 합니다.1. 레거시 코드와의 비교1.1 클라이언트 측면레거시 코드:const FUNCTION_NAME = { //... 수십 개의 함수 이름 나열 processCardePayment: "processCardPayment", // ... 수십 개의 함수 이름 나열};const processCardPayment = async () => { return callAndroidFunction(interfaceName, FUNCTION_NAME.processCardePayment);};// ... 모든 함수에 대해 반복적인 래퍼 함수 .. 2025. 1. 5. [신입 개발자의 '작디 작고 작디 작고 자그만' 첫 라이브러리 제작기] 5. Bridge-Api 파라미터 바인딩 구현 안녕하세요!이번 글에서는 Bridge-Api 라이브러리의 또 다른 핵심 기능인 파라미터 바인딩 구현에 대해 다루어보려고 합니다.파라미터 바인딩은 HTTP 요청의 다양한 부분(경로 변수, 쿼리 파라미터, 요청 본문 등)을 컨트롤러 메서드의 파라미터에 자동으로 매핑해주는 기능입니다.1. 파라미터 바인딩의 필요성Spring과 같은 웹 프레임워크를 사용해보신 분들은 @PathVariable, @RequestParam, @RequestBody 등의 어노테이션이 익숙하실 것입니다. 이러한 어노테이션들은 HTTP 요청의 데이터를 쉽게 처리할 수 있게 해주죠.Bridge-Api에서도 이와 유사한 기능이 필요했습니다. 다음과 같은 목표를 가지고 구현을 시작했습니다.경로 변수를 쉽게 추출할 수 있어야 함쿼리 파라미터를 자.. 2025. 1. 5. [신입 개발자의 '작디 작고 작디 작고 자그만' 첫 라이브러리 제작기] 4. Bridge-Api 데코레이터 패턴을 활용한 인터셉터 구현 안녕하세요!오늘은 Bridge-Api 라이브러리의 인터셉터 구현에 대해 이야기해보려고 합니다.인터셉터는 HTTP 요청/응답을 가로채서 공통적인 처리를 수행할 수 있게 해주는 중요한 기능인데요, 이를 구현하기 위해 데코레이터 패턴을 활용했습니다.1. 데코레이터 패턴을 선택한 이유인터셉터를 구현하는 방법은 여러 가지가 있지만, 데코레이터 패턴을 선택한 이유는 다음과 같습니다:유연성: 새로운 기능을 동적으로 추가/제거할 수 있습니다.단일 책임 원칙: 각 인터셉터는 하나의 책임만을 가집니다.OCP 원칙: 기존 코드를 수정하지 않고도 새로운 기능을 추가할 수 있습니다.재사용성: 인터셉터를 독립적으로 재사용할 수 있습니다.2. 기본 구조 구현먼저, 서비스 인터페이스와 기본 데코레이터 클래스를 정의했습니다.// 기본.. 2025. 1. 5. [신입 개발자의 '작디 작고 작디 작고 자그만' 첫 라이브러리 제작기] 3. Bridge-Api 에러핸들러 구현 안녕하세요!회사에서 프로젝트가 산더미 처럼 떨어져서, 아주 오랜만에 글을 이어가려 합니다.오늘은 Bridge-Api 라이브러리의 에러핸들러 구현에 대해 이야기해보려고 하는데요!에러핸들러는 라이브러리의 중요한 부분으로, 일관성 있고 효율적인 에러 처리를 가능하게 합니다.1. 에러핸들러의 필요성에러핸들러를 만들게 된 주요 이유는 다음과 같습니다:일관성: 모든 에러를 일관된 방식으로 처리할 수 있습니다.중앙화: 최상위 레벨에서 에러를 처리함으로써 코드 중복을 줄이고 관리를 용이하게 합니다.유연성: 다양한 타입의 에러에 대해 각각 다른 처리 방식을 적용할 수 있습니다.디버깅 용이성: 모든 에러가 한 곳에서 처리되므로 디버깅이 쉬워집니다.2. 에러핸들러 인터페이스 설계먼저, 에러핸들러의 인터페이스를 설계했습니다... 2024. 10. 3. 이전 1 2 다음 more 728x90