절차 적 프로그래밍 시대의 디자인 패턴은 무엇입니까? [닫은]

비슷한 : 20 년 전에 프로그래밍은 어떻게 되었습니까?

OOP 는 요즘 꽤 유행 하며 1960 년대 Simula 67 에 뿌리를두고 있으며 나중에 스몰 토크 와 C ++에 의해 대중화되었습니다 . DRY, SOLID, 객체 지향 세계의 디자인 패턴에 관한 많은 책이 있습니다.

그러나 OOP 패러다임이 널리 채택되기 전에 프로그래밍의 주요 원칙은 무엇입니까? 그리고 주요 디자인 패턴은 무엇입니까?

Java를 배우기 전에 Cobol 개발자였습니다. 나는 35 년 이상 발전해 왔습니다.

절차 적 언어 시대에 대부분의 처리는 일괄 처리로 수행되었습니다. 역사상 충분히 돌아가고, 프로그램 컴파일도 펀치 카드 데크로 일괄 처리되었습니다.

Kilian Foth의 주장 과 는 반대로 , 1970 년대와 1980 년대에 디자인 패턴이있었습니다. Cobol에서 다중 파일 일치 / 병합을 코딩하는 특정 방법이있었습니다. Cobol의 마스터 (테이프) 파일에 트랜잭션을 추가하여 코딩하는 특정 방법이있었습니다. Cobol에서 보고서 생성을 코딩하는 특정 방법이있었습니다. 그렇기 때문에 IBM의 Report Writer는 많은 Cobol 상점에서 실제로 인기를 얻지 못했습니다.

DRY 원칙의 초기 적용이있었습니다. 반복하지 않도록 단락을 많이 만듭니다. 구조화 된 코딩 기술은 1970 년대에 개발되었으며 Cobol은 1985 년에 언어에 구조화 된 단어 (동사)를 추가했습니다.

일반적으로 새로운 Cobol 프로그램을 작성할 때 오래된 Cobol 프로그램을 복사하고 무고한 사람들을 보호하기 위해 이름을 변경했습니다. 우리는 빈 종이나 빈 화면에서 코볼 프로그램을 거의 코딩하지 않았습니다. 전체 프로그램을 복사하여 붙여 넣을 수있는 큰 디자인 패턴입니다.

Cobol 디자인 패턴이 너무 많아서 Cobol 프로그래머가 모든 것을 배우는 데 몇 년이 걸렸습니다. 이것이 오늘날 코볼 프로그래머들이 여전히 1985 구문을 사용하는 이유 중 하나입니다.

개념이 발명되지 않았기 때문에 소프트웨어의 "디자인 패턴"은 당신이 말하는 시대에 존재하지 않았습니다. 이 날은 경박하지 않을 - 실제로 인 이유; 인식 가능한 이름이라고 부르는 것은 디자인 패턴을 한 형태 또는 다른 형태로 계속 사용하는 코드가 아니라 "디자인 패턴"으로 만드는 것입니다 (예 : "사용하기보다는 정적 클래스의 종류보다는"공장 ") 다양한 생성자 ") 개념 자체도 예외는 아닙니다.

물론 지금은 디자인 패턴과 마찬가지로 실무자들의 작업에서 정확히 같은 역할을 수행 한 것들이있었습니다. 그러나 당신은 그들에 대해 실망 할 것입니다. 당시의 전형적인 "전문가의 속임수"는 현재 우리에게 지루한 일이었습니다. 나중에 구현 세부 사항에 대한 생각을 바꾸는 데 아무런 도움이되지 않는 것 같습니다.

그렇습니다. 현재 우리가 사용하는 언어의 일부 일지라도 당연한 것으로 여겨지는 것들은 경험이 풍부한 코더 들만으로 알려진 고급 개념 (때로는 질투심이 많은 보호 개념)이었습니다. 오늘날 기본 프로그래밍 과정에서 배우는 거의 모든 것이 사소한 것은 아니지만 시대의 실무자에게 "디자인 패턴"과 동등한 수준의 단계를 겪었을 가능성이 있습니다. 소프트웨어 제작은 아직 엄격한 공학 분야는 아니지만 50 년대와 60 년대의 최첨단 기술을 연구 해보면 처음부터 엄청난 방법 이 왔다는 것을 부인할 수는 없습니다 .

이전의 큰 패러다임은 구조화 된 프로그래밍 이었습니다. UML 대신 다양한 다이어그램 (플로우 차트, 데이터 플로우 다이어그램, 구조 차트 등)이있었습니다. 개발은 대부분 하향식이었으며 기능적 분해 과정이 뒤따 랐습니다. 기본 아이디어 중 하나는 프로그램 구조가 다이아몬드와 유사해야한다는 것입니다. 맨 위의 기본 모듈은 하위 레벨 모듈에서 루틴을 호출하는 상위 레벨 제어 모듈로 팬 아웃되었습니다. 이러한 하위 수준 모듈은 여전히 ​​하위 수준의 모듈에 구축되어 있으며 (이론적으로) 결국 소수의 기본 I / O 루틴에 수렴되었습니다. 높은 수준의 모듈은 프로그램 논리를 포함해야했고 낮은 수준의 모듈은 데이터 무결성 및 오류 처리에 더 관심이있었습니다.

이 기간 동안 도입 된 중요한 개념은 정보 숨기기, 모듈성 및 높은 응집력 / 낮음 결합이었습니다. 이 주제에 관한 몇 가지 중요한 논문 은 Dave Parnas 의 작품을 참조하십시오 . Larry Constantine, Tom DeMarco 및 Ed Yourdon의 작품도 확인하십시오.

나는 하나의 큰 것 (구조적 프로그래밍 자체 외에도)이 핸들을 전달하는 개념이라고 생각합니다 .OO에 객체가 있고 상태와 기능이 포함되어 있습니다. OO 이전에는 독립적 인 함수가 많이 있으며, 원하는 경우 쿠키 사이에 핸들을 전달할 수 있습니다. 이를 통해 실제로 OO를 갖지 않고도 OO 원칙을 얻을 수 있습니다.

오래된 Win32 코드 에서이 내용을 많이 볼 수 있으며 Windows 커널에 할당 된 상태를 나타내는 불투명 유형 인 HANDLE을 전달합니다. 이전에 첫 번째 매개 변수로 할당 한 구조체에 포인터를 전달하여 해당 데이터에서 작동하는 함수에 직접 전달할 수 있습니다.

아무도 아직 명백한 것을 언급하지 않았기 때문에 절차 적 시대의 큰 디자인 패턴은 Object였습니다. 이전 (예 : 서브 루틴) 및 이후 (예 : 반복자)와 같은 많은 인기있는 디자인 패턴과 마찬가지로 언어 지원도 받기에 너무 인기가있었습니다.

"유한 상태 머신"은 패턴으로 계산 될 수 있으며, FSM은 사전 OO 언어를 사용하여 (예를 들어 통신 프로토콜을 위해) 작성되었습니다.

또한 "인터럽트 핸들러"와 TSR은 예를 들어 DOS에서 널리 사용되었습니다.

"스파게티 코드"및 "싱글 포인트 포인트"와 같은 용어는 실제로 그 시대로 되돌아갑니다. 요즘 우리는 코드를 "스파게티 코드"를 좋아하지 않지만 실제로는 GOTO 및 JMP와 함께 (심하게) 묶인 코드에 대한 참조입니다.

(오늘 우리는 "라비올리 코드"를 겪고 있는데,이 코드는 라비올리 플레이트와 같이 관련이없고 밀접하게 패키지 된 클래스들과 비슷하지만 일부 OO 전문가들은 "하지만 OO가 무엇을해야하는지 처럼 보입니까? ")

"Single Point of Exit"는 오늘날 실망스러운 리팩토링로드 범프입니다. 내가 이야기하는 많은 개발자들은 그것을 들어 보지 못했고 그것을 설명 할 때 놀라워합니다. 그러나 옛날에는 코드 블록에서 갑자기 스파게티 코드로 뛰어 들지 않아야했습니다. 논리의 끝으로 이동 한 다음 정상적으로 종료하십시오.

내 기억을 뒤로하고, 코드를 프로 시저에 묶는 아이디어는 큰 도약 이었다는 것을 기억하는 것 같습니다. 프로 시저를 상호 운용 가능하고 재사용 가능한 모듈로 패키지화 할 수 있다는 아이디어는 일종의 프로그래밍의 성배였습니다.

편집 : "자체 수정 코드"는 원래 Doom에서 특히 사용 된 패턴이었습니다. 프로그램이 실제로 상태에 따라 더 빠른 명령어로 명령어를 덮어 쓰는 곳입니다. 과학 박물관에서 프로그래밍 과정을 수강하는 과정에서 강사는 "자기 수정 코드를 작성하지 마십시오!"라고 엄밀히 경고했습니다.

편집 편집 : 그러나 인터넷 전에 단어가 훨씬 느리게 이동했습니다. 알고리즘과 데이터 구조를 구현한다는 아이디어는 훨씬 더 큰 거래였습니다. 오늘은 내가 사용하는 정렬을 모른 채 항상 정렬합니다. 그러나 그때 당신은 그것을 직접 코딩해야했습니다. 한 시간이 걸리던 며칠이 걸리던 프로그래밍 문제에 대한 기사가 기억납니다. 정말 유능한 "알고리즘"과 "데이터 구조"프로그래밍은 아마도 오늘날보다 훨씬 더 많은 것들이 될 것입니다.