Dijkstra는 우려 분리에 대해 글을 쓸 때 코드 모듈화를 계획 했습니까?


9

먼저, 나는 Edsger W. Dijkstra의 1974 년 논문 "과학적 사고의 역할에 관한"을 읽었습니다.

내가 당신에게 설명하려고 노력하겠습니다. 내 취향에 맞는 것은 모든 지적 사고의 특징입니다. 그것은 자신이 일관성을 유지하기 위해 자신의 주제의 측면을 심도있게 연구하고자하는 것이며, 항상 하나의 측면만으로 자신을 차지하고 있다는 것을 알고 있습니다. 우리는 프로그램이 정확해야한다는 것을 알고 있으며 그 관점에서만 연구 할 수 있습니다. 우리는 또한 그것이 효율적이어야한다는 것을 알고 있으며, 언젠가는 그 효율성을 연구 할 수 있습니다. 다른 분위기에서 우리는 스스로에게 물어볼 수 있으며, 그렇다면 : 왜, 프로그램이 바람직한 지 묻습니다. 그러나 이러한 다양한 측면을 동시에 다루면 아무것도 얻을 수 없습니다. 내가 때때로 "문제의 분리"라고 부르는 것인데, 비록 완벽하게 가능하지는 않지만 내가 아는 한, 생각의 효과적인 순서를 정할 수있는 유일한 기술이다. 이것이 내가 "어떤 측면에주의를 집중시키는"것의 의미입니다. 그것은 다른 측면을 무시하는 것을 의미하는 것이 아니라, 단지이 측면의 관점에서, 다른 측면은 관련이 없다는 사실에 대한 정의를 수행하는 것입니다. 한 트랙과 여러 트랙을 동시에 생각하고 있습니다.

코드의 모듈화에 대한 현대의 분리 문제에 대해 이야기합니다. 그러나 위의 인용문을 읽으면 한 번에 하나의 특정 작업에만 집중하고 다른 측면에는 초점을 맞추지 않는 것으로 이해합니다. 이것은 반드시 코드를 모듈 식 덩어리로 분리해야한다는 것을 의미하지는 않습니다.

즉, 하나의 파일에는보기, 저장소, 컨트롤러, 이벤트 처리, 팩토리 등의 개념이 모두 하나의 파일에 있다는 코드가 있다고 가정하십시오.

간단한 예를 들어, 데이터 액세스 및보기 (출력) 권한이있는 코드는 다음과 같습니다.

$sql = "SELECT * FROM product WHERE id = " . db_input($id);
$row = db_fetch_array(db_query($sql)); 
<option value="<?=$row['id']?>"<?= $row['ver'] == $row['ver'] ? '  selected="selected"' : '' ?>>Version <?=$row['ver']?></option>

최신 OO를 사용하면 리포지토리 패턴을 사용하여 자체 파일에 데이터 액세스를 배치 할 수 있으며 View 코드는 자체 파일 템플릿으로 이동할 수 있으며 컨트롤러 (또는 Action 또는 Request Handler)를 통해 통신하기 위해 이들을 함께 연결할 수 있습니다. 팩토리를 추가하여 다양한 종속성을 작성하고 연결하십시오. 그리고 그 팩토리를 정의하는 구성 파일을 가질 수 있습니다. 분명히 단일 파일에서 한 걸음 떨어져 있습니다.

우려 분리에 대한 나의 질문은 다음과 같습니다 : Dijkstra의 인용문을 읽으면, 그가 우려 분리를 "파일 또는 자체 기능 / 메소드 등으로 모듈 식 분리"하는 것이 아니라고 생각했을 수도 있습니다. 그는 코드에서 물리적으로 분리되어 있는지 여부에 관계없이 다른 중요하지만 현재 고려되지 않은 다른 측면에 중점을 두지 않고 프로그램의 측면에 마음을 집중시키는 것을 의미했습니다.

그렇다면 왜 우리는 물리적 모듈 식 코드 분리 및 디자인 패턴에 부담을 줍니까? 코드 구성 방식에 관계없이 한 측면에만 집중하는 것만으로는 충분하지 않습니까?

나는 가장 끔찍한 스파게티 코드를 작성하는 것에 대해 이야기하고 있지 않고 그 측면 만 고려한다면 그것은 부담이 될 것입니다. 그러나 결국, 내가 가고 싶은 것은, 물리적 코드 분리를 수행하는 이유, 정신적으로 한 측면에 집중할 필요가 없을 때 왜 코드를 분리 된 파일이나 청크로 (메서드)로 나눕니 까?

우려의 분리가 육체적 인 것이 아니라 정신적 인 운동으로 남아야합니까?
다시 말해서, 프로그래밍의 정신 (초점)과 물리적 (코드-종이) 측면 사이에 단절이 있어야 하는가?


5
나는 1974 년까지 모듈 식 프로그래밍을 분명하게 보았 기 때문에 그 논문에서 그것을 명시 적으로 논의하지 않은 이유입니다. 모듈화 방법에 대한 Parnas의 논문은 1972 년에 있었으며, 그때 까지 모듈화 여부 는 더 이상 문제가되지 않았습니다. 실제로, 당신이 묘사하는 것은 모듈 식 프로그래밍이 아니라, 구조화 된 프로그래밍 입니다. Dijkstra는 1968 년 그의 고전적인 "고해를 겪는 고스트"논문에서 이미 찬성했습니다.
Jörg W Mittag

아마 '심리의 분리'를 정신 집중 운동으로 이해하고 종이에 코드의 측면을 캡슐화하는 방법으로 모듈화를 이해할 수 있습니다. 그러나 저는 이제 분리와 개념의 분리를 별도의 개념으로 봅니다.
Dennis

@ JörgWMittag, 구조적 프로그래밍과 모듈 식 프로그래밍의 차이점을 정의 할 수 있습니까? Google의 일부 링크는 동일하다고 제안합니다.
Dennis

구조화 = IF, WHILE, FOR대신 GOTO. Modular = 잘 정의 된 퍼블릭 API를 가진 모듈은 숨겨진 내부 구현 및 표현과 엄격하게 분리됩니다. (예 : Modula, Mesa, Modula-2, Modula-3, 이후 파스칼 방언 ( UNIT).)
Jörg W Mittag

답변:


2

Dijkstra는 생각하는 방법에 대한 명확한 진술을하고 있습니다. 프로그램 (및 프로세스) 모듈화 (바람직 함)는 아마도 그 생각의 결과 일 수 있지만, 그가 만드는 핵심 요점은 문제를 평가하는 방법입니다. 이 프로그램은 일반적으로 문제에 대한 해결책이며 "문제의 분리"를 옹호함으로써 현명한 조언을 제공합니다. 가장 좋은 예는 아마도 "최적화"일 것입니다. 농담은 "프로그램 최적화를 계획 할 때 첫 번째 전략은 다음과 같아야합니다."입니다. 즉, 먼저 프로그램을 올바르게 작성하는 데 집중하고 싶습니다. 빠르고 화려하게 만드는 것은 분리해야 할 문제이지만 완전히 제거되지는 않습니다.


14

우려의 분리는 관련 될 필요가없는 것들을 개별적으로 고려하는 추상적 인 사고 방식입니다.

모듈화 (관련되지 않은 기능 그룹을 모듈로 분리), 캡슐화 (모듈의 내부 세부 사항 숨기기) 및 추상화 (일반을 특정과 분리, 구현을 아이디어와 분리)는 모두 도메인에서 이러한 사고 방식을 구현하는 수단입니다. 소프트웨어 디자인.


9

나는이 논문이 역사적으로 흥미가있는 반면, 40 년 전 Dijkstra가 "문제의 분리"라는 용어가 의미하는 바는 오늘날 특별히 관련이 없다고 제안한다. 오늘날에는 변조와 관련하여 광범위하게 사용됩니다.

모듈화가 매우 유익하고 이러한 혜택이 우리에게 부과되는 "부담"을 훨씬 능가한다는 많은 증거가 있습니다. 당시 Dijkstra가 의미했던 바가 무엇이든 각각 한 가지에만 초점을 둔 작은 코드 덩어리가 작성, 읽기, 이해, 유지 관리 및 테스트가 더 쉬운 코드로 이어진다는 사실을 바꾸지 않습니다.


5
우려 분리에 대한 현대의 많은 생각은 결국 IBM의 Aspect Oriented Programming을 낳은 초기 논문에서 나온 것입니다. 초기 논문 (90 년대 후반부터 2000 년대 초)이 가장 큰 영향을 미친다고 생각합니다. 오랜 시간이 지났고 웹 사이트가 모두 바뀌 었습니다. 다시 찾을 수 있는지 확실하지 않습니다.
Berin Loritsch

2
어려운 부분은 "한 가지"의 의미를 정의하려고합니다. 그것 없이는 아이디어는 실제 코드 작성 측면에서 쓸모가 없으며, 잘못 작성하면 코드 작성, 읽기, 이해, 유지 관리 및 테스트의 어려움에 즉시 해로운 영향을 미칩니다.
jpmc26

1
(a) Dijkstra가 "문제 분리"라는 의미로 생각하는 것을 설명하고 (b) 그가 의미하는 것이 더 이상 관련이 없다고 생각하는 이유를 설명 할 수 있다면 귀하의 입장을 이해하는 데 실제로 도움이 될 것입니다.
John R. Strohm

2

Dijkstra의 개념과 비교할 수있는 우려의 분리에 대한 개인적인 예를들 수 있습니다. 소프트웨어에서 특정 주제를 분석 할 때 세 가지 관점을 구성합니다.

  1. 먼저 데이터를 고려합니다. 데이터는 문제점의 논리 술어를 나타냅니다. 클래스는 실세계의 엔티티를 추상화하기 위해 구성되며 속성은 추상화의 매개 변수입니다. 클래스 간 연결은 클래스 인스턴스 간의 기능 매핑을 나타냅니다. 이 시점에서 사고와 관련된 코드는 없으며 처리 개념도 없습니다. 주제와 관련된 논리에 대한 정적 견해.
  2. 둘째, 역학을 고려합니다. 사소한 수명주기가있는 모든 클래스는 유한 상태 머신으로 모델링됩니다. 여기에는 시퀀싱 실행 및 동기화에 대한 고려 사항이 포함됩니다. 다시 말하지만, 코드가 사물이 어떻게 상호 작용하고 순서를 결정하는지는 알 수 없습니다.
  3. 셋째, 처리를 고려합니다. 여기에서 상태 전이 또는 다른 동기 작업에서 수행해야하는 실제 알고리즘 작업.

결국, 주제 자체에 대한 세 가지 측면을 얻은 다음 코드 자체와 유지 관리에 편리한 그룹화로 코드로 공식화 할 수 있습니다. 세 가지 측면은 단순한 정신 운동이 아닙니다. 모든 측면에 대한 서면 설명을 작성합니다. 왜? 주제가 충분히 크면 단기 기억에 하나의 완전한 패싯조차도 가질 수 없기 때문입니다. 주제가 작 으면 머리에 모든 것을 담을 수 있기 때문에 거의 모든 접근법이 효과가 있습니다.

우려를 분리하려는 동기는 인간의 단기 기억 한계를 수용하는 것입니다. 컴퓨터 프로그래머는 단기 기억으로 조작 할 수있는 개념의 수에있어 대부분의 다른 사람들보다 더 능력이있는 경향이 있지만, 우리는 단순히 한 번에 모든 것을 머리에 담을 수는 없습니다. 효과를 내려면 우려를 체계적으로 구분해야합니다.다른 특정 측면에 초점을 맞추기 위해 문제의 하나 이상의 측면을 배제하십시오. 물론, 하나의 측면을 배제한다고해서 고려에서 사라지는 것은 아닙니다. 솔루션을 달성하기 위해 모든 문제 측면을 결합하는 수단이 있어야합니다. 경험에 따르면 분리 및 재조합의 최종 결과로 인해 여러 측면이 혼동 될 수있는 단일 도약보다 더 이해하기 쉬운 솔루션이 생성되는 경우가 많습니다. 특히 문제의 크기가 크거나 복잡한 경우에 해당합니다.


1

우려의 분리는 구현 방법에 관계없이 코드 구성 모델로 전파되는 논리적 개념입니다. 코드 파일은 기술적 인 세부 사항 일 뿐이며 소프트웨어를 관리 할 수있는 방법 중 하나입니다. 영역 확장을 축소 할 수있는 훌륭한 편집기가 포함 된 단일 파일은 잠시 동안 작동 할 수도 있습니다. 또는 클래스와 메소드를 부모-자식으로 별도의 테이블에 저장하는 관계형 데이터베이스는 저장 매체로 작동 할 수 있습니다. 그러나 소스 코드가 필요한 세계에서는 텍스트 파일을 이길 수 없습니다.

  • 가지고 다닐 수 있는
  • 다양한 외부 도구로 액세스 가능
  • 여러 프로그래머가 액세스 가능
  • 버전 및 비교 가능
  • 파일 처리에 매우 뛰어난 운영 체제로 확장 가능

결론은 우리 인간이 한 번에 다른 것들을 생각하거나 다루는 데 능숙하지 않다는 것입니다. 따라서 당시에 고려하지 않은 다른 부분을 망칠 위험없이 한 번에 한 가지만 생각하고 작업 할 수있는 모델이 필요합니다. 따라서 우리는 한 번에 하나의 벽돌을 쌓아 놓고 이전에 놓인 벽돌이 나중에 놓인 벽돌을 방해하지 않도록합니다. 나중에 벽돌을 바꾸고 싶다면 물건이 무너져서는 안됩니다. 그것은 우리의 원 트랙 마인드에 적합한 모델입니다.

이것은 곰팡이 또는 조류가 자라는 방식이 아닙니다 ... 겸손한 사실은 어떻습니까?


-1

"현대 OO를 사용하면 자체 파일에 데이터 액세스를 할 수 있습니다"라고 말하고 "문제의 분리가 신체적 인 것이 아니라 정신적 인 운동으로 남아야합니까?" 현대 OO 교장들이 우리를 지시하는 곳에주의를 기울 이겠습니다.

OO를 사용하여 개발할 때 SOLID 사용자를 따라야합니다. 여기에는 좋은 연결 고리 가 있지만 "문제 분리"에 대한 TLDR은 대부분 SOLID의 S : 단일 책임 원칙 또는 SRP에 있습니다.

가장 확실한 것은 정신적 인 운동이 아니라 육체적 인 운동입니다. 구체적인 예를 들어 MVC (또는 형제 MVVM 및 MVP)는 Model, View 및 Controller / Presenter / ViewModel의 콘서트를 별도의 파일 로 물리적으로 분리 하도록 지시 합니다. "혼합 개념"경향을 더욱 제한하기 위해 별도의 어셈블리로 구현되는 MVVM 구현을 보았습니다.

그러나. 이것에 대해 밥 아저씨의 견해를 따르면 그것은 단순한 "이것은보기이고 이것은 모델입니다"를 넘어선 것 입니다.

특정 OO 요소에 대한 요구 사항 의 출처 를 고려해야합니다 . 예를 들어 고객이 원하는 것을 운영 담당자가 원하는 것과 혼합하는 경우 SRP도 위반하는 것입니다. 또는 밥 아저씨가하는 것처럼 : 클래스는 한 가지만 바꾸어야합니다.

제공된 링크를 사용하여 더 자세히 조사하거나 "고체 원칙"에 대한 웹 검색을 수행하는 것이 좋습니다.


아닙니다. SOLID 원칙은 실제 코드 작성 (실제 철학적)과는 거리가 멀기 때문에 좋은 코드를 작성하는 방법을 이미 알고 있으면 어느 정도 나 중복 될 수 있습니다. 이미 경험과 능력이없는지도 원칙으로 사용하면 코드 품질이 매우 떨어집니다.
jpmc26
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.