240705_10_한상인

dart_240611.md

@@ -6,7 +6,11 @@
 - 
 abstract 클래스
 - 사물의 어떤 큰 특징들을 보고 만드는 편
+- 상속을 통해 기능을 재사용하고자 할 때 사용한다
+- 필드와 메서드를 포함 할 수 있고, 상속받은 클래스들이 일부 메서드를 구현하도록 강제한다
 - abstract class 만 사용하자
+- 'is - a' 관계를 나타낼 때 사용한다. 'Medic' 은 'Unit' 이다 : OK! 
+  (but Unit은 Medic이다: NO! 유닛이 메딕만 있는것이 아니다)
 - 추상 클래스에서는 {}을 넣지 않고 메서드를 쓴다 (); 요렇게 끝내면 됨
 - 추상 클래스는 인스턴스화 금지(안된다잉)
 - 추상 클래스는 메서도가 없어도 괜찮다(group만을 만드려고 그러는 경우가 있다)
@@ -17,9 +21,13 @@ abstract 클래스
 
 interface
 - 다중 구현이 가능하다
-- 인터페이스 안에서는 프로퍼티 정의 해놓으면(getter/setter) 상속 받은데서 getter/setter 오버라이드를 해야되는데 번거롭다
+- 클래스가 구현 해야 할 메서드의 목록을 제공한다
+- 'can-do' 관계를 나타낼 때 사용한다. 'Medic'은 'Healable' 능력을 가지고(할 수)있다
+- 인터페이스 안에서는 프로퍼티 정의 해놓으면(getter/setter) 
+- 상속 받은데서 getter/setter 오버라이드를 해야되는데 번거롭다
 - 그래서 주로 메서드를 정의 해놓는 편이 나을것이다
 - 인터페이스 안에는 다 미정의 되어 있는 기능
 - 보통 독립적인 기능들이 모여있다(사람이라면 말하기,걷기등..)
-- abstract interface class 만 사용하자(implements 만 사용하자 공식문서에는 그렇게 되어있다구!!)
-- 
+- 인터페이스는 메서드 시그니처만을 정의한다
+- abstract interface class 만 사용하자
+- (implements 만 사용하자 공식문서에는 그렇게 되어있다구!!)

dart_240612.md

@@ -2,6 +2,163 @@
 - 다형성을 알고 나면 개발이 즐거워진다(제발)
 - 다형성 - 공통메소드를 통합
 - 공통성은 없는데 메소드(기능)만 동일하게 가지고 있으면 interface에서 구현한다
+- 
+- 
+- 스타크래프트 게임을 예로 들어 크게 
+- **유닛(Unit)**과 **건물(Structure)**로 분류할 수 있습니다. 또한 테란(Terran), 저그(Zerg), 프로토스(Protoss) 종족으로도 나눌 수 있으며, 
+- 테란의 경우 **바이오닉(Bionic)**과 **기계 유닛(Mechanic)**으로도 나눌 수 있습니다.
+
+유닛과 건물의 공통 기능과 특정 기능
+유닛과 건물은 공통 기능과 특정 기능을 가지고 있습니다. 공통 기능은 각각의 클래스에서 별도로 정의하기보다는, 
+상위 클래스에서 정의해 놓고 하위 클래스에서 필요할 때 메서드를 재정의(@override)하여 사용하는 것이 더 효율적입니다. 
+예를 들어, 테란의 메딕 유닛은 바이오닉(Bionic)이고 유닛(Unit)이며 테란 종족(Terran)입니다. 
+메딕은 다른 유닛과 공통적인 기능과 특정 기능을 모두 가지고 있습니다.
+
+공통 기능과 특정 기능의 예
+메딕의 공통 기능으로는 이동(move), 멈춤(hold), 체력(HP), 마력(MP) 등이 있으며, 
+특정 기능으로는 회복(Healable) 기능이 있습니다. 
+공통적인 기능은 특정 유닛에 국한되지 않기 때문에 인터페이스에서 선언하고, 
+이를 통해 각 클래스에서 필요할 때 구현하는 것이 효율적입니다.
+
+
+메서드 오버라이딩(Method Overriding):
+
+상위 클래스나 인터페이스에서 정의한 메서드를 하위 클래스에서 재정의하여, 
+동일한 이름의 메서드가 클래스마다 다르게 동작할 수 있게 합니다.
+예를 들어, Unit 클래스의 move() 메서드는 Medic와 Marine에서 서로 다른 방식으로 동작할 수 있습니다.
+
+
+인터페이스 구현(Interface Implementation):
+
+여러 클래스가 같은 인터페이스를 구현하여 동일한 메서드를 각각 다르게 정의할 수 있습니다.
+예를 들어, Healable 인터페이스의 heal() 메서드는 Medic와 Protoss High Templar에서 각각 다르게 구현될 수 있습니다.
+
+
+객체의 동적 바인딩(Dynamic Binding):
+
+실행 시간에 객체의 실제 타입에 따라 호출되는 메서드가 결정됩니다.
+예를 들어, Unit 타입의 변수에 Medic 객체를 할당하면, Unit 타입을 통해 Medic의 move() 메서드를 호출할 수 있습니다.
+
+
+다형성을 통한 유연성:
+
+다형성을 통해 코드의 유연성을 높일 수 있으며, 이는 새로운 클래스나 기능을 추가할 때 기존 코드를 수정하지 않고도 기능을 확장할 수 있게 합니다.
+예를 들어, 새로운 유닛을 추가할 때 Unit 인터페이스를 구현하기만 하면 기존 코드에서 이 새로운 유닛을 사용할 수 있습니다.
+
+- 추상 클래스와 인터페이스의 차이점
+* 추상 클래스의 특징
+추상 클래스는 상속을 통해 기본 기능을 정의하고 하위 클래스에서 이를 구체적으로 구현하게 합니다.
+추상 클래스를 상속(extends)받으면, 상위 클래스의 모든 메서드를 재정의(@override)하거나 기본적으로 제공된 기능을 사용하게 됩니다.
+상속받은 하위 클래스에서 특정 기능만 필요할 때도 불필요한 기능까지 포함해야 할 수 있습니다.
+* 인터페이스의 특징
+인터페이스는 클래스가 구현해야 할 메서드의 목록을 정의합니다. 인터페이스는 특정 기능을 제공하는 데 초점을 맞춥니다.
+인터페이스를 구현(implements)하면 필요한 기능만 선택적으로 구현할 수 있어 유연성을 높일 수 있습니다.
+다중 인터페이스를 통해 여러 기능을 조합하여 사용할 수 있으며, 이는 상속의 단점을 보완합니다.
+왜 인터페이스가 더 적합한가?
+추상 클래스를 사용하면 상위 클래스의 모든 기능을 상속받아야 하므로, 하위 클래스에서 필요하지 않은 기능까지 포함될 수 있습니다. 
+반면, 인터페이스는 필요한 기능만을 선언하고 이를 선택적으로 구현할 수 있기 때문에 유연성과 확장성을 더욱 높일 수 있습니다.
+
+따라서, 추상 클래스를 사용하는 것보다 인터페이스를 선언하여 필요한 기능만 선택적으로 구현하는 것이 더 적합합니다. 
+인터페이스는 다양한 클래스가 동일한 기능을 구현할 수 있게 하여 코드의 재사용성을 높이고, 시스템을 보다 유연하게 설계할 수 있게 합니다.
+
+
+```dart
+// 추상 클래스: 기본 기능 정의
+abstract class Unit {
+  int hp;
+  int mp;
+
+  void move();
+  void hold();
+}
+
+// 인터페이스: 특정 능력 정의
+abstract interface class Healable {
+  void heal();
+}
+
+abstract interface class Attackable {
+  void attack();
+}
+
+// 인터페이스: 종족 정의
+abstract interface class Terran {
+  void color();
+}
+
+// 유닛: 메딕
+class Medic implements Unit, Healable, Terran {
+  @override
+  int hp = 60;
+
+  @override
+  int mp = 100;
+
+  @override
+  void move() {
+    print("Medic is moving");
+  }
+
+  @override
+  void hold() {
+    print("Medic is holding position");
+  }
+
+  @override
+  void heal() {
+    print("Medic is healing");
+  }
+
+  @override
+  void color() {
+    print("Medic's color is blue");
+  }
+}
+
+// 유닛: 마린
+class Marine implements Unit, Attackable, Terran {
+  @override
+  int hp = 40;
+
+  @override
+  int mp = 0;
+
+  @override
+  void move() {
+    print("Marine is moving");
+  }
+
+  @override
+  void hold() {
+    print("Marine is holding position");
+  }
+
+  @override
+  void color() {
+    print("Marine's color is blue");
+  }
+
+  // 유닛을 제어하는 함수
+  void commandUnit(Unit unit) {
+    unit.move();
+    unit.hold();
+  }
+
+  void main() {
+    Unit medic = Medic();
+    Unit marine = Marine();
+
+    commandUnit(medic);  // Medic is moving
+    commandUnit(marine); // Marine is moving
+  }
+}
+
+```
+
+
+  이건 다른 유닛들도 implements 할 수 있다는 말이 된다
+  그리고 메딕만의 특정기능은 class Medic 내에서 구현 할 수 있으며
+
 - 인스턴스 생성할때 공통 기능때문에 같은 interface로 묶을 수 있다
 - 추상적인 선언 = new 상세정의
 - 여러 인터페이스를 쉼표(,)로 받을 수 있다

dart_240618.md

@@ -137,8 +137,8 @@ Employee 타입 leader가 필드에 있었네?;;
 }
 
 ```
-이렇게 되어 있고, Department.fromJson 메서드는 이 JSON 데어티를 가져와서
-Employee.fromJson 메서드에 전달하여 Employee 객체로 역직렬화 되는것이다.
+이렇게 되어 있고, Department.fromJson 메서드는 이 JSON 데이터를 가져와서
+Employee.fromJson 생성자에 전달하여 Employee 객체로 역직렬화 되는것이다.
 
 테스트코드 형태를 equals 로 비교하면 띄어쓰기라던지 있으면 비교가 잘 안되니까
 Map 형태로 바꿔서 비교하는것이 더 나을거 같다

dart_240626.md

@@ -0,0 +1,44 @@
+## Model class
+- 클래스 별도 기능을 가지지 않는다
+- 데이터 소스를 앱에서 필요한 형태로 바꿔주는 역할
+- 모델 객체 클래스의 속성에 대한 데이터를 조회할 수 있는 클래스
+
+## 권장 폴더 구조
+- data 
+ - data_source
+ - model
+ - repository
+
+## subString, subList, take
+ - 셋팅 해놓은 숫자 이하로 값이 들어오면 에러발생 한다
+ - take는 안전하게 뒤에 세팅한 숫자만큼 가져올 수 있다
+## final
+ - 매개변수에도 final을 붙일 수 있지만, 병적이라 하지말자
+
+## List.unmodifiable
+ - repository에서 return 보낼대 캡슐화를 보낼때 List는 unmodifiable로 내보내면
+   수정불가
+
+## dynamic
+ - 다이나믹을 리턴할때 한번 더 map을 이용해서 리턴하는것이 안전하다
+
+## 블랙박스 테스트
+ - 사용자관점에서 입력값과 출력값이 예상대로 나오는지에 대해서만 테스트
+ - 내용이나, 로직등을 테스트 하지 않는다
+ - 경계값 분석(-1, 0, 1) , 상태전이
+
+## 단위 테스트 (Unit Test)
+ - 
+## unit8list
+ - 바이트데이터의 array
+
+## class
+ - 클래스 내에서 클래스를 생성하지 말자(다른 클래스는 생성자로 받으면 된다)
+ - 한 클래스는 한개의 책임만 가지자
+ - 
+## Test Double
+ - 의존성을 가장 낮추고 테스트가 가능하게 만드는 것
+ - stub, spy등 모든것은 mock으로 볼 수 있다(2007년 마이크로소프트)
+
+## interface
+- 목 객체를 

dart_240628.md

@@ -0,0 +1,64 @@
+data_source: 데이터 소스와 직접적으로 상호작용하는 로직을 포함합니다. 
+             예를 들어, API 호출이나 데이터베이스 쿼리 등이 이에 해당합니다.
+
+dto (Data Transfer Object): 네트워크 요청이나 응답에서 사용되는 객체를 정의합니다. 
+                            주로 API로부터 받은 데이터의 구조를 정의하는 데 사용됩니다.
+
+mapper: 한 형태의 객체를 다른 형태로 변환하는 로직을 담당합니다.
+        예를 들어, dto를 앱 내부에서 사용하는 model 객체로 변환하는 기능을 포함할 수 있습니다.
+
+model: 애플리케이션 내부에서 사용하는 데이터 모델을 정의합니다. 
+       이는 비즈니스 로직에 사용되는 주요 데이터 구조입니다.
+
+repository: 데이터 소스와 애플리케이션 사이의 중간자 역할을 합니다. 
+            데이터를 가져오고, 캐싱하고, 변환하는 등의 작업을 수행합니다.
+
+```dart
+enum ContentType { article, image, video, unknown }
+
+abstract class Content {
+  int? id;
+  String? title;
+  String? content;
+  String? url;
+  String? caption;
+  DateTime? createdAt;
+  ContentType type;
+
+  Content({
+    this.id,
+    this.title,
+    this.content,
+    this.url,
+    this.caption,
+    this.createdAt,
+    required this.type,
+  });
+
+  factory Content.fromJson(Map<String, dynamic> json) {
+    switch (json['type']) {
+      case 'article':
+        return ArticleContent.fromJson(json);
+      case 'image':
+        return ImageContent.fromJson(json);
+      case 'video':
+        return VideoContent.fromJson(json);
+      default:
+        return UnknownContent.fromJson(json);
+    }
+  }
+}
+
+```
+
+위 코드는 어느 폴더에 있는게 가장 어울릴까?
+
+enum은 애플리케이션의 다양한 부분에서 사용될 수 있으며, 그 위치는 enum이 어떤 목적으로 사용되는지에 따라 달라집니다. 예를 들어:
+API 응답에서 특정 값을 나타내기 위해 사용되는 enum은 dto 폴더에 위치하는 것이 적절할 수 있습니다.
+애플리케이션 내부의 비즈니스 로직에서 사용되는 enum은 model 폴더에 더 적합할 수 있습니다.
+데이터 소스의 종류를 구분하는 enum은 data_source 폴더에 속할 수 있습니다.
+
+json to dart 라이브러리 사용시, 
+json_serializable을 사용하면, json_serializable은 json 데이터를 dart 객체로 변환하는 데 사용되는 코드를 생성합니다. 
+이를 통해 json 데이터를 dart 객체로 변환하고, dart 객체를 json 데이터로 변환하는 코드를 쉽게 작성할 수 있습니다.
+

dart_240703.md

@@ -0,0 +1,14 @@
+* dto를 사용하지 않을때 모델에서 사용하는 방법중에 @jsonKey(name: xxx) 가 있다.
+* 이건 들어오는 이름 대신에 내가 임의로 사용하는 이름으로 변경해서 쓰겠다 할때 사용한다.
+
+jsonSeializable과 equtable을 함께 사용한다
+
+URL 고수준 : 개발자가 사용하기 쉬운 수준
+바이너리 데이터 : 2진 데이터
+
+소켓 : 이쪽을 통해서 통신을 한다
+TCP/IP : IP 기준으로 통신한다
+
+cookie 같은건 모바일에선 sharedPreference 등으로 대체
+
+base64?