[블로그 글쓰기 챌린지: Writing Mob]에 대한 간단한 안내

4회 차에는 Jetpack Compose의 상태 감지와 SideEffect, SOLID, Jetpack Navigation, Fragment 간 데이터 공유 방법에 관한 내용이 있습니다. 자세한 내용은 아래 링크에서 확인하실 수 있습니다. 많은 관심과 응원 부탁드립니다. 좋아요 또는 댓글은 각 블로그에 직접 남겨 주시면 좋겠습니다. 감사합니다.

잘못된 내용이나 사소한 오탈자 등 소중한 피드백은 대환영입니다. 해당 블로그에 댓글로 남겨 주시면 됩니다.

아래 내용은 LilysAI를 통해 요약하였습니다.

빅스

https://interlude.tistory.com/30

1. SOLID의 개요

2. 단일 책임 원칙의 이해

3. 우발적 중복과 단일 책임 원칙(SRP) 위반

4. 병합의 중요성

5. Employee 클래스 관리 방법

6. SRP의 이해와 발전 방향

SOLID 원칙 중 첫 번째인 단일 책임 원칙(SRP)에 대해 설명하는 영상입니다. SRP는 '클래스는 단 하나의 책임만 가져야 한다'는 원칙으로, 여기서 '책임'은 '변경의 이유'로 해석해야 합니다. 즉, 클래스는 오직 하나의 액터(시스템을 사용하는 목적이 같은 집단)에 대해서만 책임져야 합니다. Employee 클래스를 예시로 들어 SRP 위반 시 발생할 수 있는 우발적 중복과 병합 문제를 설명하고, 이를 해결하기 위한 세 가지 방법(클래스 분리, 퍼사드 패턴, Employee 클래스 재구성)을 제시합니다. 궁극적으로 SRP를 지키는 이유는 코드를 더 유지보수하기 쉽게 만들기 위함이며, Facade 클래스가 비즈니스 로직을 포함하지 않는다면 SRP를 위반하지 않는다고 설명합니다.

케이엠

https://velog.io/@kmkim2689/di-basics

1. 다른 클래스의 기능 활용하기

2. 컴포넌트와 재사용성

3. 의존성과 문제점

4. 의존성 주입(Dependency Injection) 소개

5. 의존 역전 원칙(DIP)

코드 재사용을 위한 핵심 개념인 컴포넌트와 의존성을 명확하게 설명합니다. 특히, 다른 곳의 기능을 내 코드에서 사용하기 위한 세 가지 주요 방법인 의존성 주입(DI), 서비스 로케이터(Service Locator), 그리고 IoC 컨테이너를 비교 분석합니다. DI 프레임워크인 Hilt와 Koin의 사용법을 예시 코드와 함께 제시하여 실제 개발에 적용할 수 있도록 돕고, DI와 함께 SOLID 원칙 중 하나인 의존성 역전 원칙(DIP)을 설명하여 코드의 유연성과 유지보수성을 높이는 방법을 제시합니다. 이 튜토리얼을 통해 독자는 효율적인 코드 설계와 유지보수가 용이한 애플리케이션 개발 능력을 향상시킬 수 있습니다.

호두

https://walnut-dev.tistory.com/6

1. SOLID 개요 및 중요성

2. SOLID 원칙의 이해

3. SRP(단일 책임 원칙)의 중요성

4. 개방-폐쇄 원칙 (OCP)

5. 리스코프 치환 원칙 (LSP)

6. SOLID 원칙에 대한 이해와 적용 방법

이 글은 SOLID 원칙을 쉽고 가볍게 설명하며, 개발자가 객체 지향 설계를 더 효과적으로 수행하도록 돕는 것을 목표로 합니다. SOLID는 단일 책임 원칙(SRP), 개방-폐쇄 원칙(OCP), 리스코프 치환 원칙(LSP), 인터페이스 분리 원칙(ISP), 의존성 역전 원칙(DIP)으로 구성됩니다. 각 원칙의 정의와 배경을 설명하고, 실제 코드에 적용하는 방법과 주의사항을 제시합니다. SOLID원칙은 무조건적인 규칙이 아닌, 상황에 따라 유연하게 적용할 수 있는 지침임을 강조하며, 꾸준한 연습과 동료와의 피드백을 통해 SOLID원칙을 내재화하는 것이 중요하다고 조언합니다. 이 글을 통해 독자는 SOLID원칙을 이해하고, 객체 지향 설계능력을 향상시킬 수 있습니다.

베르

https://seonghoonc.tistory.com/58

1. Jetpack Compose의 SideEffect 활용

2. produceState의 활용

3. derivedStateOf의 올바른 사용법

4. SnapshotFlow와 효과 관리

이 글은 Jetpack Compose의 SideEffect에 대한 공식 문서를 분석하고, Compose 상태를 외부 코드와 공유하거나 외부 상태를 Compose 상태로 변환하는 방법, 그리고 불필요한 Recomposition을 방지하는 방법에 대해 설명합니다. SideEffect는 Compose 상태를 Compose 외부의 객체에 공유할 때 사용되며, produceState는 외부 상태를 Compose 상태로 변환하는 데 유용합니다. derivedStateOf는 상태 변경이 잦을 때 UI 업데이트를 최적화하는 데 사용되지만, 비용이 많이 들 수 있으므로 신중하게 사용해야 합니다. snapshotFlow는 Compose State를 cold Flow로 변환하여 비동기적으로 처리할 수 있게 합니다. Jetpack Compose에서 SideEffect를 올바르게 사용하는 방법을 이해하고, 효율적인 UI 개발을 위한 팁을 제공하는 것이 이 글의 핵심 주제입니다.

벼리

http://velog.io/@geun5744/stateful%ED%95%9C-%EA%B0%9D%EC%B2%B4-%EA%B4%80%EC%B0%B0%ED%95%98%EA%B8%B0

1. 상태 변화 감지와 UI 업데이트

2. State 동작의 중요성

3. stateful 데이터 감지 및 UI 업데이트 방법

4. SnapshotStateList의 이해

이 글은 Jetpack Compose에서 UI가 업데이트되지 않는 문제를 해결하는 방법을 제시합니다. Compose에서 ` MutableList`와 같은 변경 가능한 데이터 타입은 변화를 감지하지 못해 Recomposition이 발생하지 않습니다. 이를 해결하기 위해 `mutable StateListOf`를 사용하여 `SnapshotStateList` 객체를 생성하고, 이 객체가 데이터 변화를 감지하여 UI를 업데이트하도록 합니다. `Snapshot StateList`는 리스트 형태의 상태 저장 객체로, 리스트 아이템의 변경 사항을 자동으로 Compose UI에 반영하여 UI 성능 향상에 기여합니다. 따라서, `mutable StateListOf`를 통해 상태 변화를 관찰하고 UI를 업데이트하는 방법을 이해하는 것이 중요합니다.

해나

https://velog.io/@hxeyexn/activityViewModels

1. Fragment 간 데이터 공유 방법

2. AAC ViewModel과 Fragment KTX 개요

3. activityViewModels()의 개념

4. SharedViewModel 생성 및 사용 방법

5. Fragment 간 SharedViewModel 데이터 공유의 제약

6. 결론 요약

이 글은 Android 앱 개발 시 Fragment 간 데이터 공유의 어려움을 해결하기 위한 방법을 제시합니다. 핵심은 `Shared ViewModel`을 활용하는 것인데, 이는 AAC ViewModel과 FragmentKTX의 `activity ViewModels()` API를 통해 구현됩니다. `activity ViewModels()`는 부모 Activity의 ViewModel에 접근할 수 있게 해 주어, 같은 Activity 내의 Fragment들이 ViewModel 인스턴스를 공유하도록 합니다. 이를 통해 Fragment들은 Activity의 Lifecycle에 따라 데이터를 일관되게 유지하고 공유할 수 있습니다. 하지만 주의할 점은, 서로 다른 Activity 간에는 `Shared ViewModel`을 통한 데이터 공유가 불가능하다는 것입니다. 이 튜토리얼은 Fragment 간 효율적인 데이터 공유를 가능하게 하는 방법을 제시합니다.

꼬상

https://velog.io/@tyui13/Jetpack-Navigation-%EC%A0%9C%EB%8C%80%EB%A1%9C-%EC%82%AC%EC%9A%A9%ED%95%98%EA%B8%B0

1. Jetpack Navigation의 이해

2. Jetpack Navigation의 핵심 컴포넌트

3. Compose 이전의 Navigation 방식

4. Compose Navigation 사용법 (ver 2.8.0 이전)

5. Compose Navigation 2.8.0 이후의 변화

안드로이드 Jetpack Navigation 라이브러리의 변화 과정을 명확하게 설명합니다. XML 기반에서 Compose 기반으로 전환되면서 Navigation 방식이 어떻게 변화했는지, 그리고 각 방식의 장단점을 비교 분석합니다. 특히, Compose Navigation 2.8.0 이후에 도입된 Kotlin Serialization을 통한 타입 안정성 확보가 핵심 내용입니다. 이 글을 통해 독자는 Navigation의 개념과 컴포넌트를 이해하고, 프로젝트 환경에 맞는 Navigation 방식을 선택하는 데 도움을 받을 수 있습니다. 타입 안정성을 확보하며 Navigation을 구현하는 방법을 제시합니다.

빙티

https://velog.io/@s6m1n/writing-mob-4

1. 객체 지향 프로그래밍의 특징 및 SOLID 원칙 소개

2. 단일 책임 원칙(SRP)의 개념과 적용 방법

3. SRP 원칙 위반으로 인한 문제점

4. 클래스의 책임 분리 및 변경 필요성

5. 책임을 다른 클래스로 분리하기

이 글은 SOLID 원칙 중 하나인 단일 책임 원칙(SRP)을 실제 코드에 적용하는 과정을 보여줍니다. SRP는 클래스가 하나의 책임만을 가져야 한다는 원칙입니다. `VisitedAtSelectionFragment` 클래스가 UI 로직과 도메인 로직을 동시에 처리하여 SRP를 위반하는 사례를 분석하고, 날짜/시간 관련 로직을 `CalendarState` 클래스로 분리하여 책임을 분산시키는 리팩토링 과정을 설명합니다. 이를 통해 코드의 가독성, 유지보수성, 테스트 용이성을 향상시키는 방법을 제시하며, 객체지향 프로그래밍의 핵심 원리를 실질적으로 이해하고 적용하는 데 도움을 줍니다.

악어

https://velog.io/@hogu59/writing-mob-4-1

https://velog.io/@hogu59/writing-mob-4-2

1. 객체지향 설계의 중요성

2. 객체지향설계의 개념

3. 객체지향의 개념 이해하기

4. 객체지향의 개념 및 차별성

5. 객체지향 설계를 위한 핵심 접근 방식

6. 객체지향적 설계의 장점

7. 객체지향 설계의 핵심

이 글은 객체지향 설계의 핵심 개념과 접근 방식을 설명합니다. 객체지향 설계는 단순히 코드를 작성하는 것을 넘어, 소프트웨어 세계를 창조하는 과정으로 정의합니다. 객체는 상태와 행동을 가지며, 명확한 책임을 수행하고, 다른 객체와 협력하는 독립적인 단위입니다. 객체지향 설계에서는 객체들이 서로 협력하여 시스템을 구성하는 것이 중요하며, 이를 통해 코드의 유지보수성과 확장성을 높일 수 있습니다. 객체중심으로 사고하고 설계하는 방법을 익히면 더 좋은 코드와 소프트웨어를 만들 수 있습니다.

1. SOLID의 첫 번째 원칙 - SRP (단일 책임 원칙)

2. 단일 책임 원칙의 적용 사례

3. 단일 책임 원칙의 적용 예시

4. 단일 책임 원칙(SRP)과 다중 상속의 관계

5. 단일 책임 원칙(SRP)의 이해

6. SRP (단일 책임 원칙)의 이해

이 글은 객체지향 설계의 핵심 원칙인 SOLID 중 첫 번째, SRP(단일 책임 원칙)에 대해 설명합니다. SRP는 '클래스는 변경되어야 할 이유가 오직 하나여야 한다'는 원칙으로, 유지보수성을 높이는 데 기여합니다. 책임의 정의와 함께, 단일 책임을 판단하는 다양한 기준(함수, 메서드, 상속, 의존성)에 대한 오해와 진실을 파헤칩니다. 결론적으로, SRP는 절대적인 규칙이 아닌, 소프트웨어의 변화와 유지보수를 고려하여 적용해야 하는 유연한 지침임을 강조합니다. 궁극적으로는 '하나의 모듈은 오직 하나의 액터에 대해서만 책임져야 한다'는 로버트 C. 마틴의 조언을 통해 SRP에 더 가까워질 수 있음을 제시합니다.

[블로그 글쓰기 챌린지: Writing Mob 4회]

댓글