💻 Dev 야옹

Feed
Explore
Ranking

/

💻 Dev

7

개발 전반에 대한 내용을 다룹니다.

·

고양이 앉혀놓고 코딩

태그

최근 댓글

Hysteresis Buffer 문제 상황iOS 앱에서 UI 인터랙션을 구현하다 보면, 값이 경계 근처에서 계속 튀는 현상을 자주 마주하게 된다.예를 들어 스크롤 방향에 따라 View를 제어하는 다음과 같은 로직을 생각해 보자.위로 스크롤 → View 숨김아래로 스크롤 → View 표시이 로직 자체는 단순하지만, 실제 사용 환경에서는 문제가 발생한다. 손가락의 위치가 경계값 근처

0

0

3 months ago

5 min read

여러 Mutation을 순차적으로 방출할 때의 위험성 - 원자적 상태 업데이트의 중요성 문제 상황: 하나의 액션, 여러 개의 상태 변경상태를 관리하다 보면, 한 번쯤은 하나의 사용자 액션이 여러 개의 State 프로퍼티를 동시에 변경해야 하는 상황에 마주치게 된다.예를 들어, 아이템 상태 보기 화면에서 '새로고침' 버튼을 누르면 아래의 세 가지 상태를 모두 갱신해야 한다고 가정해보자.struct State { var mainItem:

0

0

9 months ago

6 min read

싱글톤의 함정? 의존성 주입을 통한 더 나은 아키텍처 설계 소프트웨어 아키텍처에는 의존성을 명확히 관리하는 것은 유지보수성과 확장성을 위해 필수적이다.콘솔 기반의 숫자 야구 프로젝트를 진행하면서 클린 아키텍처의 Repository를 싱글톤으로 구현 후 직접 참조했는데, 생각해보니 이 방식은 클린 아키텍처의 의존성 분리 원칙을 위반하고 있었다. 조사를 해보니, 클린 아키텍처에서는 Repository를 싱글톤이 아닌

0

2

a year ago

9 min read

단일 책임 원칙 (SRP: Single Responsibility Principle) - 유지보수성을 높이는 설계 원칙 단일 책임 원칙(SRP)이란?클래스나 모듈은 단 하나의 변경 이유만 가져야 한다.SRP는 하나의 클래스 또는 모듈이 어려 개의 역할을 담당하면 안 되며, 변경해야 하는 이유가 하나여야 한다는 의미를 가진다. 즉, 클래스는 하나의 명확한 목적을 가져야 하며, 하나의 책임만 수행해야 한다.쉽게 말해, 하나의 클래스는 하나의 역할만 수행해야 한다. 여러 개의 기

0

0

a year ago

6 min read

비동기 프로그래밍의 이해 비동기 프로그래밍이란?동기(Synchronous) vs 비동기(Asynchronous) 프로그래밍동기(Synchronous) 프로그래밍하나의 작업이 끝날 때까지 다음 작업을 실행하지 않음작업이 완료될 때까지 앱이 멈춘 것처럼 보일 수 있음print("작업 시작") sleep(3) // 3초 동안 멈춤 print("작업 완료")문제점sleep(3) 동안 다른

0

0

a year ago

5 min read

아키텍처와 디자인 패턴 아키텍처아키텍처(Architecture)란?소프트웨어 아키텍처는 앱의 전체적인 구조를 설계하는 방법이다.코드가 정리되지 않고 모든 로직이 ViewController에 집중되면 유지보수가 어려움아키텍처를 적용하면 코드가 모듈화되고 확장성이 좋아짐아키텍처를 적용하면 좋은 점코드가 가독성이 높아지고 유지보수가 쉬워짐앱이 커져도 각 컴포넌트를 쉽게 분리 및 확장

0

0

a year ago

6 min read

URL의 구성 요소 및 REST API URL의 기본 구조https://www.example.com:443/path?query=1#fragmentScheme: 프로토콜 (https, http 등)Host: 서버 주소 (www.example.com)Port: 통신 포트 (443, 80 등)Path: 리소스 경로 (/path)Query: 쿼리 파라미터 (?query=1)Fragment: 해시값 (#

0

0

a year ago

2 min read

iosSwiftSRP단일 책임 원칙Clean ArchitectureSingletonDependency InjectionDependency Inversion PrincipleReactorKitState ManagementArchitectureHysteresis Buffer

좋은 의견 감사합니다! 말씀해주신 것처럼, 싱글톤 자체가 의존성 분리 원칙의 정반대 개념은 아니고, 의존성 주입과 함께 사용할 수도 있습니다. 사실 제가 글에서 말하고 싶었던 부분은 '싱글톤을 직접 참조하는 방식이 의존성 분리 원칙을 위반할 수 있다`는 점이었는데요. 댓글을 보고 글을 다시 한 번 정독해보니 제가 글을 오해의 소지가 있게 작성하였습니다. 말씀해주신 부분에 대해서 더 깊이 있게 공부해보고 글을 수정하도록 하겠습니다. 의견 주셔서 다시 한 번 감사드립니다!

`let userService = UserService(repository: UserRepository.shared)` 다음과 같이 사용하면, 싱글톤을 이용하면서도 의존성 주입을 적용할 수 있을 것 같습니다! 실제로 Spring, NestJS와 같은 백엔드 프레임워크에서는 의존성 주입 + 싱글톤 패턴을 같이 사용하고 있어요. 싱글톤은 객체를 생성하는 방법에 대한 '생성 패턴'이기 때문에, 의존성 분리 원칙과 정반대의 개념이 아니거든요.