If-less 프로그래밍 (기본적으로 조건부 없음)

If-less 프로그래밍 (기본적으로 조건부 없음)

---

한 동료가 코드에 조건문 ( "if"및 "switch"문)을 포함하지 않는 정책이있는 회사에서 일했으며 코드의 모든 결정이 다형성 및 다른 OO 원칙.

나는 좀 더 건조하고 업데이트하기 쉬운 코드를 갖는 이유 를 이해하고 있지만이 개념에 대한 더 자세한 설명을 찾고 있습니다. 또는 더 일반적인 디자인 접근 방식의 일부일 수도 있습니다.

누군가가 이것에 대한 자원을 가지고 있거나 이것과 관련하여 설명하거나 더 많은 용어를 가지고 있다면 더 많은 답변을 찾는 데 사용할 수 있습니다.

나는 SO에 대한 일종의 관련 질문을 찾았 지만 C ++에 익숙하지 않아서 거기에 대한 답변을 너무 많이 이해하지 못합니다.

(나는 OO 전문가 btw는 아니지만 관리 할 수 ​​있습니다)

저는 PHP에 가장 능숙하며 그 이후에는 Python을 사용하므로 해당 언어를 사용하는 정보를 선호합니다.

업데이트 : 동료에게 그가 정확히 의미하는 바에 대한 자세한 정보를 요청할 것입니다.

2015 년 업데이트 : 프로그래밍에서 수년간의 경험을 쌓은 후 이제이 정책의 목표는 프로그래머가 특정 위치에 조건문 (if 문)을 추가하여 우연한 방식으로 기능을 추가하는 것을 방지하는 것이었을 것입니다. 소프트웨어를 확장하는 더 좋은 방법 은 상속과 다형성을 사용하여 소프트웨어를 확장 하는 "개방 / 폐쇄 원칙" 을 사용하는 것입니다. 조건문 없이는 완전히 진행하기가 어렵 기 때문에 정책이 모든 조건문에 대해 매우 엄격한 지 여부를 강력히 의심합니다.

---

이 기사 와 같은 Anti-IF 캠페인 사이트 에는 몇 가지 리소스가 있습니다 .

정도의 문제라고 생각합니다. 조건문이 항상 나쁜 것은 아니지만 악용 될 수 있습니다 (그리고 자주).

추가 생각 (하루 후)

리팩토링 : 기존 코드의 디자인 개선은 이 주제 (및 기타 여러 주제)에 대한 좋은 참고 자료입니다. 조건부 다형성으로 바꾸기를 다룹니다 . 웹 사이트 에는 새로운 조건부 방문자로 조건 바꾸기도 있습니다.

나는 모든 진술 을 제거하는 것보다 단순성과 단일 책임 을 중요하게 생각합니다 if. 이 세 가지 목표는 종종 일치합니다. 순환 복잡도 메트릭 을 지원하는 정적 분석 도구는 중첩 또는 직렬 조건이있는 코드를 빠르게 지적 할 수 있습니다. if문은 후 리팩토링 남아있을 수 있지만, 작은 방법 및 / 또는 여러 클래스로 세분화 될 수있다.

업데이트 : Michael Feathers는 무조건 프로그래밍 에 대한 기사를 작성했습니다 .

이것은 인기있는 주제입니다 : Phil Haack on Death to the IF statement !

---

몇 년간의 프로그래밍 끝에 나는 내 자신의 질문으로 돌아 왔는데, 그 맥락은 이제 조금 더 잘 이해됩니다.

Sandi Metz의 좋은 이야기가 있는데, 그녀는 정말 털이 많은 if 문을 털이 덜한 것으로 리팩토링합니다. https://www.youtube.com/watch?v=8bZh5LMaSmE

---

나는 당신이 링크 한 게시물을 읽었고 그들은 일반적으로 모든 코드와 혼동되지 않도록 클래스 내에서 조건 문의 필요성을 제거하는 것에 대해 대부분 이야기하고있는 것 같습니다 . 특정 기능이 있는지 확인하기 위해 개체의 상태 (조건부 사용)를 확인해야하는 경우 실제로는 두 개의 개체 (기능을 지원하는 개체와 지원하지 않는 개체)가 있으며이를 두 개로 정의해야합니다. 대신 관련 클래스.

---

한 동료가 코드에 조건문 ( "if"및 "switch"문)을 포함하지 않는 정책이있는 회사에서 일했으며 코드의 모든 결정이 다형성 및 다른 OO 원칙.

동료가 무언가를 오해했거나 잘못된 단어를 사용하여 설명했다고 생각합니다. 그리고 조건문을 완전히 피할 수는 없습니다.

할 말이 있습니다. OOP 내에서 if 문이 확산되는 것은 잘못된 프로그래밍의 증상 일 수 있습니다. 몇 가지 예 :

이전 C 스타일 프로그래밍과 같이 함수의 반환 값을 확인하려면 if를 사용하지 마십시오.

int ret = some_func();
if (ret != null)
   //do something

이것은 C 코드에서 일반적이지만 OOP에서는 예외를 사용해야합니다.

try{
    do_something();
}catch(Exception e){
    e.printStackTrace(); //why I was not able to do something
    handle(e); //there is something else I could do to handle the occurred error
}

때때로 진술 확산이 잘못된 설계와 관련이있는 경우. Java에서 다음 예제를 고려하십시오.

BaseClass base;
if (base instanceof DerivedClassOneFromBase){
    DerivedClassOneFromBase d = (DerivedClassOneFromBase)base;
    d.methodOne();
}else if (base instanceof DerivedClassOneFromBase){
    DerivedClassTwoFromBase d = (DerivedClassTwoFromBase)base;
    d.methodTwo();
}

이것은 아마도 잘못된 디자인과 관련된 잘못된 if 문의 또 다른 예입니다. 두 파생 개체에 기본 클래스 BaseClass에 정의 된 공통 메서드가있는 경우에서는 구체적인 형식을 확인하고 캐스팅하는 대신 해당 메서드를 호출 할 수 있습니다.

base.commonMethod();

---

때로는 메서드 내부의 조건문이 하나의 메서드에서 여러 함수 또는 여러 유형 메서드를 수행하고 있다는 신호이기 때문에 좋지 않습니다.

Automobile이라는 클래스와 Car 및 Bike와 같은 하위 클래스 및 다음과 같은 메서드가있는 경우

drive(Automobile a)
   if (a.isCar)
      // do stuff
   else if (a.isBike)
      // do stuff

당신은 뭔가 잘못하고있을 가능성이 가장 높습니다. 유형에 따른 스위치가 아니더라도 종종 잘못 될 수 있습니다. 메소드가 일부 변수에 따라 여러 기능을 수행하는 경우 종종 하나 이상의 작업을 시도하며 여러 메소드로 분리되어야합니다.

예를 들면 :

save(Car c)
   if (c is new)
      // do some stuff
   else if (c is old)
      // do some stuff

두 가지 다른 기능이기 때문에 잠재적으로 저장 및 업데이트로 나눌 수 있습니다. 그것은 달려 있지만.

유효한 사용 사례가 많기 때문에 if 문을 완전히 금지하는 것은 어리석은 일입니다.

---

Avoiding conditionals does not necessarily mean you need to get it done by polymorphism or inheritance, take for example :

You have 3 different folders to store uploaded images, uploaded videos and uploaded pdf

You can write code as :

uploadMedia(mediaType){
   if(mediaType == images){
     uploadTo("myProject/images");
   }else if(mediaType == videos){
     upoloadTo("myProject/videos);  
   }else if(mediaType == pdf){
     uploadTo("myProject/pdf");
  }
}

Another alternative that people might use is switch-case :

uploadMedia(mediaType){
         switch(mediaType){
         case : images
         uploadTo("myProject/images");
         break;

         case : videos
         uploadTo("myProject/videos");
         break;

         case : pdf
         uploadTo("myProject/pdf");
         break;
    }
}

But then you can totally avoid conditional statement by using something like dictionary/hashmap/json (Depending upon whatever you work with) :

For example :

HashMap<String,String> mediaMap = new HashMap<>();

mediaMap.put("images","myProject/images");
mediaMap.put("videos","myProject/videos");
mediaMap.put("pdf","myProject/pdf");

//mediaType can be images/videos/pdf same as keys of mediaMap
uploadMedia(mediaType){
  uploadTo(mediaMap.get(mediaType));
}

This is sort of pseudo code so there might be syntax mistakes, but overall this concept is also helpful in avoiding conditionals. Also line of code can be reduced.

참고URL : https://stackoverflow.com/questions/7264145/if-less-programming-basically-without-conditionals