abstract, fromMap, abstract

abstract

`abstract`는 11살 아이가 쉽게 이해할 수 있게 이렇게 설명할 수 있어:

생각해보면, abstract는 설계도 같은 거야. 예를 들어, 자동차를 만든다고 할 때, 설계도는 "자동차에는 바퀴가 있어야 하고, 핸들이 있어야 해"라고 말해. 하지만 바퀴가 몇 개인지, 핸들이 어떤 모양인지는 알려주지 않아. 그건 실제로 자동차를 만들 때 결정해.

즉, abstract는 클래스가 어떤 기능을 가져야 하는지 정해주지만, 그 기능이 정확히 어떻게 동작하는지는 나중에 구현하라는 의미야.

abstract는 Dart에서 추상 클래스나 추상 메서드를 정의할 때 사용하는 키워드다. 추상 클래스는 직접 인스턴스화될 수 없으며, 반드시 서브클래스에서 구현되어야 한다.

역할:

• 공통 인터페이스 제공: 클래스가 가져야 할 메서드나 속성의 틀을 정의한다.
• 구현 강제: 추상 메서드는 구체적인 구현을 서브클래스에 강제한다.

예를 들어, SignalRepository는 abstract로 선언되어 특정 기능을 구현하도록 강제한다. 이를 통해 코드의 일관성과 확장성을 높일 수 있다.

fromMap의 역할

fromMap은 Map 데이터를 가져와서 앱에서 사용할 수 있는 Dart 객체로 변환하는 역할을 해. 예를 들어, Firebase나 API에서 데이터를 가져오면 Map 형태로 전달되는데, fromMap을 통해 이를 우리 앱에서 사용하기 쉬운 형태의 객체로 바꿀 수 있어.

데이터소스(DataSource)의 역할

DataSource는 앱이 외부 데이터(Firebase, API 등)와 통신하는 부분이야. 예를 들어, DataSource는 데이터를 가져오거나 저장하는 작업을 담당하고, 이런 데이터를 앱 내부에서 사용할 수 있게 전달해줘.

도메인 레이어에서 인터페이스를 `abstract`로 만드는 이유는 **유연성과 확장성**을 높이기 위해서야.

1. **구현 분리**: 인터페이스는 **구현체와 분리**되므로, 데이터 소스(API, Firebase 등)가 변경되더라도 비즈니스 로직에 영향이 없다.
2. **의존성 주입 가능**: 다양한 구현체를 DI로 주입할 수 있어 **테스트**나 **교체**가 쉽다.
3. **유지보수성**: 새로운 데이터 소스나 기능이 추가될 때 인터페이스만 따르도록 설계되어 있어 확장에 용이하다.

즉, 추상화는 구조의 견고함과 변경에 대한 유연성을 제공한다.

인터페이스를 사용하면 "약속" 같은 거야. 우리가 A라는 레고 조립 방법만 정해 놓고, 실제로 어떤 색이나 모양의 레고를 사용할지는 나중에 정하는 것과 같아.

예를 들어, 처음엔 Firebase를 사용해서 데이터를 가져오다가 나중에 다른 API로 바꾸어도, 비즈니스 로직 쪽에서는 "이 레고는 이 모양대로 조립돼야 해"라는 약속만 지키면 되기 때문에 아무 영향이 없어. 이렇게 하면 변경이 쉬워지고 앱이 더 유연해져!

try-catch문은 프로그램에서 에러가 생겨도 앱이 멈추지 않게 안전장치를 만들어 주는 거야.

• try: 에러가 날 수 있는 코드를 실행해.
• catch: 에러가 발생하면 이 부분이 실행되어, 에러 메시지를 보여주거나 문제를 처리할 수 있어.

예를 들어, 나누기를 할 때 0으로 나누면 에러가 나지만 try-catch를 사용하면 프로그램이 멈추지 않고 에러를 처리할 수 있어!