메서드 인수로 부울이 허용되지 않습니까? [닫은]

내 동료는 메서드 인수로 부울을 사용할 수 없다고 말합니다 . 그것들은 열거로 대체 될 것입니다. 처음에는 어떤 이점도 보지 못했지만 그는 나에게 모범을 보였습니다.

이해하기 쉬운 것은 무엇입니까?

file.writeData( data, true );

또는

enum WriteMode {
  Append,
  Overwrite
};

file.writeData( data, Append );

이제 알았습니다! ;-)
이것은 두 번째 매개 변수로서 열거가 코드를 훨씬 더 읽기 쉽게 만드는 예입니다.

그래서,이 주제에 대한 당신의 의견은 무엇입니까?

부울은 "예 / 아니오"선택을 나타냅니다. "예 / 아니오"를 나타내려면 부울을 사용하십시오. 자체 설명이 필요합니다.

그러나 두 가지 옵션 중 하나를 선택하는 것이 분명한 예 또는 아니오가 아니라면 열거 형을 더 쉽게 읽을 수 있습니다.

열거 형은 또한 세 번째 선택 (또는 그 이상)을 원하는 향후 수정을 허용합니다.

문제를 가장 잘 모델링하는 것을 사용하십시오. 제공하는 예에서 열거 형이 더 나은 선택입니다. 그러나 부울이 더 나은 다른 경우가 있습니다. 당신에게 더 의미가있는 것 :

lock.setIsLocked(True);

또는

enum LockState { Locked, Unlocked };
lock.setLockState(Locked);

이 경우에는 매우 명확하고 모호하지 않다고 생각하기 때문에 부울 옵션을 선택할 수 있으며, 잠금 상태가 두 개 이상이 아닐 것이라고 확신합니다. 여전히 두 번째 선택은 유효하지만 불필요하게 복잡한 IMHO입니다.

나에게는 부울이나 열거를 사용하지 않는 것이 좋은 접근 방법입니다. Robert C. Martin은 그의 Clean Code Tip # 12 : Eliminate Boolean Arguments 에서이를 매우 명확하게 포착합니다 .

부울 인수는 함수가 한 가지 이상을 수행함을 크게 선언합니다. 혼란스럽고 제거해야합니다.

방법은 하나 이상의 일을하면 오히려 귀하의 경우 예를 들어 두 개의 서로 다른 방법을 써야한다 : file.append(data)와 file.overwrite(data).

열거 형을 사용한다고해서 더 명확 해지지는 않습니다. 아무것도 변경하지 않고 여전히 플래그 인수입니다.

나는 당신이 거의 이것에 대해 스스로 대답했다고 생각합니다. 최종 목표는 코드를 더 읽기 쉽게 만드는 것입니다.이 경우 enum은 그렇게했습니다. IMO는 항상 포괄적 인 규칙보다 최종 목표를 보는 것이 가장 좋습니다. 지침으로 즉, 열거 형은 일반적인 bools, int 등보다 코드에서 더 쉽게 읽을 수 있지만 항상 규칙에 예외가 있습니다.

쿠바 미사일 위기 때 아들 라이 스티븐슨이 유엔 주재 조린 대사에게 던진 질문을 기억 하십니까?

"당신은 지금 세계 여론의 법정에 있고 예 또는 아니오라고 대답 할 수 있습니다 . 당신은 [미사일]이 존재한다는 것을 부인했으며, 제가 당신을 올바르게 이해했는지 알고 싶습니다 .... 기다릴 준비가되어 있습니다. 그게 당신의 결정이라면 지옥이 멈출 때까지 내 대답을 위해. "

메서드에있는 플래그가 이진 결정에 고정 할 수있는 특성이 있고 해당 결정이 3 방향 또는 n 방향 결정으로 바뀌지 않는 경우 부울로 이동합니다. 표시 : 플래그는 isXXX 입니다.

모드 스위치 인 경우 부울로 만들지 마십시오 . 처음에 메소드를 작성할 때 생각했던 것보다 항상 하나 이상의 모드 가 있습니다.

하나 이상의 모드 딜레마는 예를 들어 유닉스를 괴롭 혔습니다. 파일이나 디렉토리가 현재 가질 수있는 가능한 권한 모드는 파일 유형, 소유권 등에 따라 모드의 이상한 이중 의미를 초래합니다.

이것이 나쁜 일이라는 두 가지 이유가 있습니다.

1. 어떤 사람들은 다음과 같은 메소드를 작성하기 때문입니다.

   ProcessBatch(true, false, false, true, false, false, true);
   

   이것은 매개 변수를 혼합하기가 너무 쉽기 때문에 분명히 나쁘고, 당신이 지정하는 것을 보면 알 수 없습니다. 하지만 부울 하나만해도 나쁘지는 않습니다.

2. 간단한 예 / 아니오 분기로 프로그램 흐름을 제어하는 ​​것은 어색한 방식으로 하나로 묶인 완전히 다른 두 가지 기능이 있음을 의미 할 수 있기 때문입니다. 예를 들면 :

   public void Write(bool toOptical);
   

   정말 두 가지 방법이어야합니다

   public void WriteOptical();
   public void WriteMagnetic();
   

   이것들의 코드는 완전히 다를 수 있기 때문에; 모든 종류의 다른 오류 처리 및 유효성 검사를 수행해야하거나 나가는 데이터의 형식을 다르게 지정해야 할 수도 있습니다. Write()또는 사용만으로는 알 수 없습니다 Write(Enum.Optical)(물론 원하는 경우 내부 메서드 WriteOptical / Mag를 호출하기 만하면 이러한 메서드 중 하나를 사용할 수 있음).

상황에 따라 다릅니다. 나는 # 1을 제외하고 그것에 대해 너무 큰 거래를하지 않을 것입니다.

열거 형이 더 좋지만 부울 매개 변수를 "허용되지 않음"이라고 부르지 않습니다. 때로는 작은 부울 하나를 던져서 계속 진행하는 것이 더 쉽습니다 (개인 메서드 등을 생각해보십시오).

부울은 Python 및 Objective-C와 같이 이름이 지정된 매개 변수가있는 언어에서 괜찮을 수 있습니다. 이름은 매개 변수의 기능을 설명 할 수 있기 때문입니다.

file.writeData(data, overwrite=true)

또는:

[file writeData:data overwrite:YES]

나는 그것이 좋은 규칙 이라는 것에 동의하지 않을 것 입니다. 분명히 Enum은 어떤 경우에는 더 명확하거나 장황한 코드를 만들지 만 일반적으로 도달 범위를 초과하는 것처럼 보입니다.

먼저 여러분의 예를 들어 보겠습니다. 좋은 코드를 작성하는 프로그래머의 책임 (및 능력)은 부울 매개 변수가 있다고해서 실제로 위험에 처하지 않습니다. 귀하의 예제에서 프로그래머는 다음과 같이 작성하여 자세한 코드를 작성할 수 있습니다.

dim append as boolean = true
file.writeData( data, append );

또는 더 일반적인 것을 선호합니다

dim shouldAppend as boolean = true
file.writeData( data, shouldAppend );

둘째 : 여러분이 준 Enum 예제는 CONST를 전달하기 때문에 "더 나은"것입니다. 대부분의 응용 프로그램에서 함수에 전달되는 시간 매개 변수의 대부분은 VARIABLES입니다. 이 경우 두 번째 예제 (좋은 이름의 변수 제공)가 훨씬 낫고 Enum은 약간의 이점을 제공했을 것입니다.

열거 형에는 확실한 이점이 있지만 모든 부울을 열거 형으로 바꾸면 안됩니다. 참 / 거짓이 실제로 무슨 일이 일어나고 있는지 나타내는 가장 좋은 방법 인 곳이 많이 있습니다.

그러나 그것들을 메소드 인자로 사용하는 것은 약간 의심 스럽습니다. 왜냐하면 그들이해야 할 일을 파헤 치지 않고서는 볼 수 없기 때문입니다. 참 / 거짓이 실제로 무엇을 의미 하는지 볼 수 있기 때문입니다.

속성 (특히 C # 3 개체 이니셜 라이저 사용) 또는 키워드 인수 (la ruby ​​또는 python)는 부울 인수를 사용하는 경우 훨씬 더 나은 방법입니다.

C # 예 :

var worker = new BackgroundWorker { WorkerReportsProgress = true };

루비 예

validates_presence_of :name, :allow_nil => true

Python 예

connect_to_database( persistent=true )

부울 메서드 인수가 올바른 일이라고 생각할 수있는 유일한 것은 속성이나 키워드 인수가없는 Java입니다. 이것이 내가 자바를 싫어하는 이유 중 하나이다 :-(

많은 경우에 열거 형이 부울보다 더 읽기 쉽고 확장 가능하다는 것은 사실이지만, "부울은 허용되지 않는다"라는 절대적인 규칙은 멍청합니다. 융통성이없고 비생산적입니다. 인간의 판단을위한 여지를 남기지 않습니다. 유용하기 때문에 대부분의 언어에서 기본 내장 유형입니다. 다른 내장 유형에 적용하는 것을 고려하십시오. 예를 들어 "int를 매개 변수로 사용하지 마십시오"라고 말하는 것은 미친 짓일 것입니다.

이 규칙은 버그 나 런타임 성능의 가능성이 아니라 스타일의 문제 일뿐입니다. 더 나은 규칙은 "가독성을 위해 부울보다 열거 형을 선호"하는 것입니다.

.Net 프레임 워크를 살펴보십시오. 부울은 꽤 많은 메소드에서 매개 변수로 사용됩니다. .Net API는 완벽하지 않지만 매개 변수로 부울을 사용하는 것이 큰 문제라고 생각하지 않습니다. 도구 설명은 항상 매개 변수의 이름을 제공하며 이러한 종류의 지침도 작성할 수 있습니다. 메소드 매개 변수에 대한 XML 주석을 채우면 도구 설명에 표시됩니다.

또한 부울을 열거 형으로 명확하게 리팩터링해야하는 경우가 있다고 덧붙여 야합니다. 클래스 나 메서드 매개 변수에 두 개 이상의 부울이 있고 모든 상태가 유효하지 않은 경우 (예 :이를 갖는 것이 유효하지 않습니다) 둘 다 true로 설정 됨).

예를 들어, 클래스에 다음과 같은 속성이있는 경우

public bool IsFoo
public bool IsBar

그리고 두 가지 모두 동시에 사실을 갖는 것은 오류입니다. 실제로 얻은 것은 세 가지 유효한 상태이며 다음과 같이 더 잘 표현됩니다.

enum FooBarType { IsFoo, IsBar, IsNeither };

동료가 더 잘 준수 할 수있는 몇 가지 규칙은 다음과 같습니다.

• 당신의 디자인에 독단적이지 마십시오.
• 코드 사용자에게 가장 적합한 것을 선택하십시오.
• 이번 달에 모양이 마음에 든다고해서 모든 구멍에 별 모양의 못을 박 으려고하지 마세요!

부울은 프레임 워크의 기능을 확장하지 않으려는 경우에만 허용됩니다. Enum은 함수 호출의 이전 구현을 중단하지 않고 열거 형을 확장 할 수 있기 때문에 선호됩니다.

Enum의 또 다른 장점은 읽기가 더 쉽다는 것입니다.

방법이 다음과 같은 질문을하는 경우 :

KeepWritingData (DataAvailable());

어디

bool DataAvailable()
{
    return true; //data is ALWAYS available!
}

void KeepWritingData (bool keepGoing)
{
   if (keepGoing)
   {
       ...
   }
}

부울 메서드 인수는 절대적으로 완벽 해 보입니다.

방법에 따라 다릅니다. 방법이 매우 명백하게 참 / 거짓 인 일을한다면 괜찮습니다. 예를 들면 아래와 같습니다. [이 방법이이 방법에 가장 적합한 설계라고 말하는 것은 아니지만 사용법이 명백한 예일뿐입니다].

CommentService.SetApprovalStatus(commentId, false);

그러나 언급 한 예와 같은 대부분의 경우 열거 형을 사용하는 것이 좋습니다. .NET Framework 자체에는이 규칙을 따르지 않는 많은 예가 있지만, 이는주기의 후반부에이 디자인 지침을 도입했기 때문입니다.

그것은 일을 좀 더 명확하게 만들지 만 인터페이스의 복잡성을 엄청나게 확장하기 시작합니다-추가 / 덮어 쓰기와 같은 순수한 부울 선택에서 과잉처럼 보입니다. 추가 옵션을 추가해야하는 경우 (이 경우 생각할 수 없음) 언제든지 리팩터링을 수행 할 수 있습니다 (언어에 따라 다름).

Enum은 확실히 코드를 더 읽기 쉽게 만들 수 있습니다. (적어도 .net에서는)주의해야 할 몇 가지 사항이 있습니다.

enum의 기본 저장소는 int이므로 기본값은 0이되므로 0이 적절한 기본값인지 확인해야합니다. (예를 들어 구조체는 생성 될 때 모든 필드가 0으로 설정되어 있으므로 0 이외의 기본값을 지정할 방법이 없습니다. 0 값이 없으면 int로 캐스팅하지 않고 열거 형을 테스트 할 수도 없습니다. 나쁜 스타일.)

열거 형이 코드에 비공개 인 경우 (공개적으로 노출되지 않음) 여기서 읽기를 중지 할 수 있습니다.

열거 형이 어떤 방식 으로든 외부 코드에 게시 되거나 프로그램 외부에 저장되는 경우 명시 적으로 번호를 매기는 것이 좋습니다. 컴파일러는 자동으로 0부터 번호를 지정하지만 값을 제공하지 않고 열거 형을 재 배열하면 결국 결함이 발생할 수 있습니다.

나는 합법적으로 쓸 수있다

WriteMode illegalButWorks = (WriteMode)1000000;
file.Write( data, illegalButWorks );

이를 방지하기 위해, 확신 할 수없는 열거 형 (예 : 공개 API)을 사용하는 코드는 열거 형이 유효한지 확인해야합니다. 이것을 통해

if (!Enum.IsDefined(typeof(WriteMode), userValue))
    throw new ArgumentException("userValue");

유일한 경고 Enum.IsDefined는 반사를 사용하고 느리다는 것입니다. 또한 버전 관리 문제도 있습니다. 열거 형 값을 자주 확인해야하는 경우 다음을 수행하는 것이 좋습니다.

public static bool CheckWriteModeEnumValue(WriteMode writeMode)
{
  switch( writeMode )
  {
    case WriteMode.Append:
    case WriteMode.OverWrite:
      break;
    default:
      Debug.Assert(false, "The WriteMode '" + writeMode + "' is not valid.");
      return false;
  }
  return true;
}

버전 관리 문제는 이전 코드가 보유한 2 개의 열거 형을 처리하는 방법 만 알 수 있다는 것입니다. 세 번째 값을 추가하면 Enum.IsDefined가 true가되지만 이전 코드가이를 처리 할 수는 없습니다. 으악.

[Flags]열거 형으로 할 수있는 재미가 훨씬 더 많으며 이에 대한 유효성 검사 코드는 약간 다릅니다.

또한 이식성 ToString()을 위해 열거 형에 대한 호출 을 사용 Enum.Parse()하고 다시 읽을 때 사용해야 합니다. 둘 다 ToString()및 열거 형도 Enum.Parse()처리 할 수 [Flags]있으므로 사용하지 않을 이유가 없습니다. 이제 코드를 깨지 않고는 열거 형의 이름을 변경할 수도 없기 때문에 또 다른 함정입니다.

그래서 가끔은 부울 하나만으로도 빠져 나갈 수 있을까요?

IMHO 열거 형은 두 개 이상의 옵션이 가능한 모든 상황에서 확실한 선택이 될 것 같습니다. 그러나 부울이 필요한 모든 상황이 있습니다. 이 경우 bool이 작동하는 enum을 사용하는 것이 4가 작동 할 때 7 단어를 사용하는 예라고 말할 수 있습니다.

부울은 두 가지 중 하나 (예 : 전구 상태, 켜짐 또는 꺼짐) 중 하나 일 수있는 분명한 토글이있을 때 의미가 있습니다. 그 외에는 전달하고있는 내용이 분명하도록 작성하는 것이 좋습니다 (예 : 디스크 쓰기-버퍼링되지 않음, 라인 버퍼링 또는 동기). 지금 동기 쓰기를 허용하고 싶지 않더라도 (따라서 두 가지 옵션으로 제한됨), 한눈에 무엇을하는지 알기 위해 더 자세한 정보를 작성하는 것이 좋습니다.

즉, False 및 True (부울 0 및 1)를 사용할 수도 있으며 나중에 더 많은 값이 필요한 경우 사용자 정의 값 (예 : 2 및 3)과 이전 0/1 값을 지원하도록 함수를 확장 할 수 있습니다. 멋지게 이식되므로 코드가 손상되지 않아야합니다.

때로는 오버로드로 다른 동작을 모델링하는 것이 더 간단합니다. 귀하의 예에서 계속하려면 다음과 같습니다.

file.appendData( data );  
file.overwriteData( data );

이 방법은 매개 변수가 여러 개인 경우 성능이 저하되며 각각 고정 된 옵션 세트를 허용합니다. 예를 들어, 파일을 여는 메소드에는 파일 모드 (열기 / 만들기), 파일 액세스 (읽기 / 쓰기), 공유 모드 (없음 / 읽기 / 쓰기)의 여러 순열이있을 수 있습니다. 총 구성 수는 개별 옵션의 카티 전 곱과 같습니다. 당연히 이러한 경우 다중 과부하는 적절하지 않습니다.

열거 형은 일부 언어 (예 : C #)에서 정확한 열거 형 값의 유효성을 검사하는 것이 어려울 수 있지만 경우에 따라 코드를 더 읽기 쉽게 만들 수 있습니다.

종종 부울 매개 변수가 새 오버로드로 매개 변수 목록에 추가됩니다. .NET의 한 가지 예는 다음과 같습니다.

Enum.Parse(str);  
Enum.Parse(str, true); // ignore case

후자의 오버로드는 첫 번째보다 이후 버전의 .NET 프레임 워크에서 사용할 수있게되었습니다.

두 가지 선택 만있을 것이라는 것을 알고 있다면 부울이 괜찮을 수 있습니다. 열거 형은 이전 코드를 손상시키지 않는 방식으로 확장 할 수 있지만, 이전 라이브러리는 새 열거 형 값을 지원하지 않을 수 있으므로 버전 관리를 완전히 무시할 수 없습니다.

편집하다

최신 버전의 C #에서는 IMO가 열거 형과 동일한 방식으로 호출 코드를 더 명확하게 만들 수있는 명명 된 인수를 사용할 수 있습니다. 위와 동일한 예를 사용하여 :

Enum.Parse(str, ignoreCase: true);

두 가지 옵션이있는 메서드에서 Enum이 좋은 방법이라는 데 동의합니다 (그리고 두 가지 옵션 만 열거 형없이 가독성을 가질 수 있음).

예 :

public void writeData(Stream data, boolean is_overwrite)

열거 형을 좋아하지만 부울도 유용합니다.

이것은 이전 게시물에 대한 늦은 항목이며, 아무도 읽지 않을 정도로 페이지 아래에 있지만 아무도 이미 말하지 않았기 때문에 ....

인라인 주석은 예상치 못한 bool문제 를 해결하는 데 큰 도움이됩니다 . 원래의 예는 특히 끔찍합니다. 함수 해제에서 변수의 이름을 지정하려고한다고 상상해보세요! 그것은 다음과 같을 것입니다.

void writeData( DataObject data, bool use_append_mode );

그러나 예를 들어 그것이 선언이라고 가정 해 봅시다. 그런 다음 설명되지 않은 부울 인수에 대해 인라인 주석에 변수 이름을 넣습니다. 비교

file.writeData( data, true );

와

file.writeData( data, true /* use_append_mode */);

그것은 정말로 논쟁의 정확한 성격에 달려 있습니다. 예 / 아니오 또는 참 / 거짓이 아닌 경우 열거 형을 사용하면 더 쉽게 읽을 수 있습니다. 그러나 열거 형을 사용하면 기본 유형의 정의되지 않은 값이 전달 될 수 있으므로 인수를 확인하거나 허용 가능한 기본 동작을 가져야합니다.

예제에서 부울 대신 열거 형을 사용하면 메서드 호출을 더 읽기 쉽게 만드는 데 도움이됩니다. 그러나 이것은 메서드 호출에서 명명 된 인수 인 C #에서 내가 가장 좋아하는 항목을 대체합니다. 이 구문 :

var v = CallMethod(pData = data, pFileMode = WriteMode, pIsDirty = true);

완벽하게 읽을 수 있고 프로그래머가해야 할 일을 할 수 있습니다. 즉, IDE에서 어떻게 보이는지에 관계없이 메서드의 각 매개 변수에 대해 가장 적절한 유형을 선택하는 것입니다.

C # 3.0은 생성자에서 명명 된 인수를 허용합니다. 왜 그들이 방법으로 이것을 할 수 없는지 모르겠습니다.

부울 값 true/ false만. 그래서 그것이 무엇을 나타내는지는 분명하지 않습니다. Enum의미있는 이름을 가질 수 있습니다 예를 들어 OVERWRITE, APPEND등 그래서 열거 형이 더 낫다.