본문 바로가기

IT.모바일/배움

Dart lowerCamelCase / static const / 생성자 ? ?? / required / named positional parameter | DART 언어

by FrankUniq 2023. 12. 1.
SMALL

변수, 속성 이름 규칙

Dart에서는 변수와 속성 이름에 대해 lowerCamelCase 규칙을 권장합니다.
이 규칙에 따라 각 단어의 첫 글자는 소문자로 시작해야 하며, 두 번째 단어부터는 첫 글자를 대문자로 합니다.
ex. int santa; int merryChristmas;

static int num = 50; vs. static const int num = 50;의 차이:

  • **static** int num = 50;: 이 선언은 num이 클래스의 모든 인스턴스에 대해 공유되는 정적(static) 변수임을 의미합니다. 이 변수는 프로그램 실행 중에 변경될 수 있습니다.
  • **static const** int num = 50;: 이 선언은 num이 정적(static)이면서 상수(const)임을 의미합니다. 즉, 이 값은 프로그램 전체에서 공유되고 한 번 설정되면 변경할 수 없습니다. 컴파일 타임에 값이 결정되며, 런타임에는 변경할 수 없습니다.

생성자 문법

  • Cleric(this.name, {int num1, int num2}): 이 구문은 Cleric 클래스의 생성자입니다.
    this.name은 생성자의 인자로 전달된 name을 클래스의 name 필드에 할당합니다.
    {int num1, int num2}는 선택적 매개변수를 나타냅니다. 중괄호 {} 안에 있는 매개변수는 필수가 아니며, 제공되지 않을 수도 있습니다.
  • : this.num1 = num1 ?? A, this.num2 = num2 ?? B: 이 부분은 생성자 본문 이전에 실행되는 초기화 리스트입니다.
    num1 ?? Anum1null이 아니면 num1 값을 사용하고, null이면 A를 사용합니다.
    마찬가지로, num2 ?? Bnum2null이 아니면 num2 값을 사용하고, null이면 B를 사용합니다.
    이렇게 함으로써, num1이나 num2가 제공되지 않을 때 기본값으로 AB를 사용할 수 있습니다.

코드에서 보면,

Cleric(this.name, {int num1, int num2}) // name 필수 제공, num1, num2 선택 제공
      : this.num1 = num1 ?? A, // num1 제공되지 않을 경우 A로 초기화
        this.num2 = num2 ?? B; // num2 제공되지 않을 경우 B로 초기화

required

required 키워드는 Dart의 null safety 기능과 관련이 있습니다. 이 기능을 사용하면 모든 변수와 매개변수가 기본적으로 non-nullable(즉, null 값을 가질 수 없음)이 됩니다. 이때, 선택적 매개변수(중괄호 {}로 묶인 매개변수)에 대해 null이 허용되지 않게 하려면 required 키워드를 사용해야 합니다.

name 매개변수는 생성자에서 필수적으로 요구되므로, required 키워드 없이도 정상적으로 동작합니다. 이는 name이 positional 매개변수(위치에 따라 결정되는 매개변수)이기 때문입니다. 그러나 num1num2는 선택적인 named 매개변수로 중괄호 {} 안에 정의되어 있습니다. 이 경우, required 키워드는 필요하지 않습니다. 왜냐하면, 이 매개변수들은 기본적으로 null을 허용하기 때문이며, 생성자의 초기화 리스트에서 ?? 연산자를 사용해 null인 경우 기본값을 설정하기 때문입니다.

required를 사용하는 예는 다음과 같습니다:

Cleric({required this.name, int? num1, int? num2}) 
      : this.num1 = num1 ?? A, 
        this.num2 = num2 ?? B;
}

위 코드에서 name은 필수적인 named parameter[명명 매개변수]이며,
num1num2는 선택적이지만 null을 허용하지 않는 named parameter입니다.
int?null을 허용하는 정수 타입을 의미합니다.

Cleric({required this.name, int num1, int num2})Cleric(this.name, {int num1, int num2})의 차이

두 생성자는 name 매개변수를 다루는 방식이 다릅니다. 이 차이는 매개변수가 필수인지, 선택적인지에 따라 다릅니다:

  1. Cleric({required this.name, int num1, int num2}):
    • 이 생성자는 모든 매개변수를 named 매개변수로 처리합니다. 매개변수 이름 앞에 중괄호 {}를 사용합니다.
    • required 키워드는 name 매개변수가 필수적임을 의미하며, 이 매개변수 없이 Cleric 인스턴스를 생성할 수 없습니다.
    • 이 생성자를 사용하면, 인스턴스를 생성할 때 매개변수 이름을 명시적으로 지정해야 합니다. 예: Cleric(name: "abc", num1: 40, num2: 5)
  2. Cleric(this.name, {int num1, int num2}):
    • 이 생성자는 name을 positional[지정] 매개변수로, num1num2를 선택적인 named 매개변수로 처리합니다.
    • this.name은 인스턴스 생성 시 반드시 제공해야 하는 필수 매개변수입니다.
    • num1num2는 선택적으로 제공할 수 있으며, 제공하지 않으면 null 또는 기본값(초기화 리스트에서 처리)을 가집니다.
    • 이 생성자를 사용하면, name은 항상 제공해야 하며, num1num2는 선택적으로 이름을 지정하여 제공할 수 있습니다. 예: Cleric("abc", num1: 40, num2: 5)

결론적으로, 두 생성자는 name 매개변수를 다루는 방식에서 주요한 차이를 보입니다: 첫 번째는 모두 이름을 지정해야 하는 named 매개변수 방식이고, 두 번째는 name을 필수로 하는 positional 매개변수와 나머지를 선택적인 named 매개변수로 처리하는 방식입니다.

 

Named Parmaeter와 Positional Parameter 두 생성자 스타일은 서로 다른 사용 시나리오와 선호도에 따라 선택될 수 있습니다. 각각의 장단점을 비교해보겠습니다:

  1. Named Parameter 생성자 (Cleric({required this.name, int? a, int? b})):
    • 장점:
      • 매개변수의 순서가 중요하지 않아 호출 시 유연합니다.
      • 매개변수의 이름을 명시해야 하므로, 코드의 가독성이 좋아집니다.
      • 매개변수를 선택적으로 제공할 수 있어, 다양한 사용 사례에 적합합니다.
    • 단점:
      • 매개변수 이름을 항상 명시해야 하므로, 호출 시 조금 더 많은 타이핑이 필요합니다.
    • 적합한 사용 사례:
      • 매개변수가 많고, 각각의 목적이 명확할 때.
      • 함수 호출 시, 매개변수의 순서를 자유롭게 하고 싶을 때.
  2. Positional Parameter 생성자 (Cleric(this.name, {int? a, int? b})):
    • 장점:
      • 가장 중요한 매개변수(name)를 먼저 위치시켜, 사용 시 직관적입니다.
      • 선택적 매개변수(hp, mp)는 명시적으로 제공할 수도 있고, 생략할 수도 있어 유연합니다.
    • 단점:
      • name 매개변수는 항상 첫 번째 위치에 와야 하므로, 호출 시 순서를 고려해야 합니다.
    • 적합한 사용 사례:
      • 몇몇 매개변수가 항상 필요하고, 나머지는 선택적일 때.
      • 함수 호출 시, 가장 중요한 매개변수를 먼저 제시하고 싶을 때.

결론적으로, 어떤 생성자가 '낫다'고 말하기보다는, 각각의 사용 사례와 개발자의 선호에 따라 적절한 방식을 선택하는 것이 중요합니다. 이름(name)이 항상 필요하고, 나머지 매개변수는 선택적인 경우, 두 번째 방식이 더 직관적일 수 있습니다. 반면, 모든 매개변수를 동등하게 취급하고 싶거나, 함수 호출 시 매개변수의 순서를 자유롭게 하고 싶다면, 첫 번째 방식이 더 적합할 수 있습니다.

댓글