“구성에 대한 컨벤션”이 기본 프로그래밍 원칙을 위반하지 않습니까?

WPF MVVM 프레임 워크 Caliburn.Micro 를보고 많은 표준 항목이 명명 규칙을 기반으로한다는 것을 읽었습니다 .

예를 들어, View의 속성을 ViewModel의 속성에 자동 바인딩합니다. 이것이 편리한 것처럼 보이지만 (일부 보일러 플레이트 코드를 제거함) 첫 번째 본능적 인 반응은이 코드를 읽는 새로운 프로그래머에게는 완전히 분명하지 않다는 것입니다. 다시 말해서, 응용 프로그램의 기능은 자체 코드가 아니라 프레임 워크의 문서에 의해 완전히 설명됩니다.

편집하다:

따라서이 접근 방식을 컨벤션 오버 컨벤션이라고합니다. 이에 관한 질문을 찾을 수 없으므로 질문을 변경했습니다.

내 질문은 :

구성에 대한 관습이 올바른 것을 단순화하는 방법입니까, 아니면 일부 프로그래밍 원칙을 위반 하는가?

"응용 프로그램은 자체 코드로 완전히 설명해야한다"는 기본 프로그래밍 원칙으로 간주하지 않습니다. 단순히 응용 프로그램의 코드를 보면 설명되지 않는 많은 것들이 있습니다. 프로그래밍 언어 자체의 기본 사항 (구문 및 의미)을 알고있는 것 외에도 규칙을 알아야합니다. Java의 식별자가 대문자로 시작하면 유형입니다. 알아야 할 이러한 규칙이 많이 있습니다.

구성에 대한 협약은 프로그래머가해야 할 결정의 양을 줄이는 것입니다. 어떤 것들은 이것이 명백하다-아무도 타입의 대문자가 프로그램의 상단에 선언해야 할 언어를 갖는 것을 고려하지 않을 것이다. 그러나 다른 것들에 대해서는 그렇게 명확하지 않다.

컨벤션 및 구성의 균형을 맞추는 것은 어려운 작업입니다. 규칙이 너무 많으면 코드가 혼동 될 수 있습니다 (예 : Perl의 암시 적 변수 사용). 한 시스템에서 얻은 지식이 다른 시스템을 연구 할 때 거의 유용하지 않기 때문에 프로그래머 측의 자유가 너무 많으면 시스템을 이해하기 어려울 수 있습니다.

프로그래머가 컨벤션을 지원하는 좋은 예는 Eclipse 플러그인을 작성할 때입니다. 내가 본 적이없는 플러그인을 볼 때 나는 그것에 대해 많은 것을 즉시 알고 있습니다. 종속성 목록은 MANIFEST.MF에 있고 확장 점은 plugin.xml에 있으며 소스 코드는 "src"에 있습니다. 이러한 것들이 프로그래머가 정의해야한다면, 모든 단일 Eclipse 플러그인은 다르며 코드 탐색은 훨씬 더 어려울 것입니다.

@JesperE에 +1을 부여하고 무언가를 추가하고 싶습니다.

프로그래밍 원칙을 위반합니까?

그렇습니다. "구성에 대한 컨벤션"은 "명시 적 묵시적보다 낫다"라는 원칙을 위반합니다 (예 : "Zen-Of-Python"참조 ).

반면에 반대되는 "컨벤션에 대한 구성"은 "단순이 복잡한 것보다 낫다"를 위반하는 경향이 있으며, 구성에서 코드에 사용 된 이름을 반복해야하기 때문에 미묘한 방식으로 DRY 원칙 을 위반 합니다. .

일부 "컨벤션 오버 컨벤션"은 합리적인 기본값으로 요약됩니다. 비표준 목적으로 사용하도록 구성해야합니다. 여기서 Struts와 Rails를 비교해야합니다. Rails에서는 "액션 / 스크린"을 폴더에 넣어야 만 작동합니다. Struts에서는 여전히 폴더에 저장해야하지만 action-name 및 JSP 파일과 양식 이름 및 양식 Bean을 작성하고 Struts-config에서이 세 가지가 함께 작동하는 방법을 지정해야합니다. xml AND 양식이 요청에 속해 있음을 지정합니다 (RESTful). 충분하지 않은 경우 form / form-bean 매핑에는 Struts-config에 자체 섹션이 있으며 동일한 파일의 작업 섹션에 독립적으로 매핑되며 JSP 파일의 필기 문자열을 사용하여 작동합니다. 정확히. 각 화면마다 그것은 최소한 6 가지해야 할 일이며 오류를 일으킬 수있는 많은 기회입니다. 필자는 필요한 경우 Rails에서 대부분 또는 모든 것을 수동으로 설정할 수 있다고 생각하지만 Struts 개발 시간의 2/3는 불필요한 복잡한 계층을 구축하고 유지하는 데 소요됩니다.

공평하게 Struts 1은 사람들이 데스크탑과 웹 사이에서 애플리케이션을 이식 할 때 설계되었습니다. Struts의 유연성 덕분에 Rails가하는 모든 일과 데스크탑 응용 프로그램에 필요한 모든 것에 적합합니다. 불행히도, 유연성을 가능하게하는 구성의 산은 웹 응용 프로그램이나 데스크톱 응용 프로그램 만 작성해야하는 사람에게는 큰 공과 사슬입니다.

나는 어딘가에서 다음 단계 를 취해 “Configuration over Code ” 라고 주장 했지만 논리적으로 극단적 인 결과를 보인 결과 구성이 새로운 코딩 언어가된다. 복잡하지 않은 방식으로 복잡한 방식으로 진행된 쉘 게임이었습니다. 또한 잘 설계된 프로그래밍 언어가 가지고있는 모든 유형 검사 및 기타 안전망에 감사했습니다. 공간이나 아포스트로피를 추가해도 오류 메시지없이 터지는 반 베이크 구성 파일 형식은 편집 도구 세트와이를 위해 작성된 품질 컴파일러가있는 품질 프로그래밍 언어에 비해 개선되지 않습니다.

합리적인 기본값이 확장 성과 모듈성에 대한 이론적 원칙을 위반한다고 생각할 수 없습니다. Ruby / Rails 프로그래머는 모든 구성이 여러 XML 파일로 명시 적으로 구성된 Struts 1과 같은 프레임 워크로 전환하는 것보다 더 빨리 포커를 할 것입니다. 나는 Rails vs. Struts IN GENERAL을 주장하지는 않지만 그 관습은 큰 생산성 승리가 될 수 있습니다. 이 두 기술은 내가 본 것 중 가장 극단적 인 실제 비교입니다.

Java로 작업하는 경우 Joshua Bloch의 "Effective Java", 항목 2 : "많은 생성자 매개 변수가있는 경우 빌더 고려"(pp. 11-16)를 확인하십시오. 대부분의 경우 일부 매개 변수 (구성)가 필요하고 일부는 선택적입니다. 기본 아이디어는 필요한 구성 만 요구하고 사용자 (다른 프로그램 일 수 있음) 만 필요에 따라 추가 옵션을 지정하도록하는 것입니다. 한 달 전에이 패턴으로 많은 코드를 정리했으며 긍정적으로 빛났습니다.

다시 말해서, 응용 프로그램의 기능은 자체 코드가 아니라 프레임 워크의 문서에 의해 완전히 설명됩니다.

프레임 워크를 사용하는 응용 프로그램의 기능은 항상 프레임 워크에 의존하므로 구성에 대한 컨벤션은 그 점에서 차이가 없습니다.

경험상 컨피규레이션에 대한 컨벤션은 코드를 더 읽기 쉽게 만들뿐만 아니라 미묘한 버그 (특히 복사-붙여 넣기-버그)를 도입 할 가능성을 줄입니다.

예를 들어, 일부 프레임 워크 A에서 이벤트 FooBar가에 대한 호출을 트리거 한다고 가정 합니다 handleFooBar. 다른 프레임 워크 B에서이 상관 관계는 XML 파일 어딘가에 구성됩니다.

A에서는 간단하게

handleFooBar() {
   ...
}

맞춤법이 틀린 FooBar가 없으면 FooBar가 발생할 때마다 호출됩니다.

B에서는 또 다시

handleFooBar() {
   ...
}

뿐만 아니라

<eventconfiguration>
  <event>
    <type>FooBar</type>
    <handler>handleFooBar</handler>
  </event>
</eventconfiguration>

이 방법으로 수백 가지를 구성하면 실수로 너무 미묘한 버그를 만드는 것이 너무 쉽습니다.

<eventconfiguration>
  <event>
    <type>BarFoo</type>
    <handler>handleFooBar</handler>
  </event>
</eventconfiguration>

복사하여 붙여 넣은 후에 만 ​​변경 <type>했지만 변경하는 것을 잊었 기 때문 <handler>입니다.

이러한 구성 파일은 크고 단조롭 기 때문에 실제 프로그램 코드에서 비슷한 버그를 찾는 것보다 교정을 통해 버그를 찾을 가능성이 적습니다.

몇 가지 원칙을 위반했을 수도 있지만 동시에 가장 기본적인 설계 원칙 중 하나 인 SRP (Single Responsibility Principle)를 준수합니다.