Các mẫu thiết kế của thời đại lập trình thủ tục là gì? [đóng cửa]

Tương tự: Làm thế nào được lập trình 20 năm trước?

OOP ngày nay khá thời trang, có nguồn gốc từ Simula 67 vào những năm 1960, và sau đó được phổ biến bởi Smalltalk và C ++ . Chúng tôi có DRY, RẮN, nhiều cuốn sách về các mẫu thiết kế trong thế giới hướng đối tượng.

Nhưng các nguyên tắc chính trong lập trình trước khi áp dụng mô hình OOP là gì? Và các mẫu thiết kế chính là gì?

Tôi là một nhà phát triển Cobol trước khi tôi học Java. Tôi đã phát triển được hơn 35 năm.

Quay trở lại thời của ngôn ngữ thủ tục, hầu hết việc xử lý được thực hiện theo đợt. Quay trở lại đủ xa trong lịch sử, và thậm chí việc biên soạn chương trình đã được thực hiện với một loạt các thẻ đục lỗ theo đợt.

Trái ngược với khẳng định của Kilian Foth , chúng tôi đã có các mẫu thiết kế từ những năm 1970 và 1980. Có một cách nhất định để mã hóa kết hợp / kết hợp nhiều tệp trong Cobol. Có một cách nhất định để mã thêm các giao dịch vào tệp chính (băng) trong Cobol. Có một cách nhất định để tạo mã báo cáo trong Cobol. Đó là lý do tại sao Báo cáo của IBM không bao giờ thực sự đạt được sức hút trong nhiều cửa hàng Cobol.

Có một ứng dụng sớm của nguyên tắc DRY. Tạo nhiều đoạn văn để bạn không lặp lại chính mình. Các kỹ thuật mã hóa có cấu trúc đã được phát triển vào những năm 1970 và Cobol đã thêm các từ có cấu trúc (động từ) vào ngôn ngữ vào năm 1985.

Nói chung, khi chúng tôi viết một chương trình Cobol mới, chúng tôi đã sao chép một chương trình Cobol cũ và thay đổi tên để bảo vệ người vô tội. Chúng tôi gần như không bao giờ mã hóa chương trình Cobol từ một tờ giấy trắng hoặc màn hình trống. Đó là một mẫu thiết kế lớn khi bạn có thể sao chép và dán toàn bộ chương trình.

Có rất nhiều mẫu thiết kế Cobol mà phải mất nhiều năm để một lập trình viên Cobol tìm hiểu tất cả. Đó là một lý do mà các lập trình viên Cobol ngày nay, phần lớn, vẫn sử dụng cú pháp 1985.

"Các mẫu thiết kế" trong phần mềm không tồn tại trong thời đại mà bạn nói đến, vì khái niệm này chưa được phát minh. Đây không phải là tôi thiếu sót - nó thực sự là lý do; được gọi là một tên dễ nhận biết là điều làm cho mẫu Thiết kế trở thành "Mẫu thiết kế" thay vì chỉ là mã mà bạn tiếp tục sử dụng ở dạng này hay dạng khác (ví dụ: "Factory" chứ không phải là "loại lớp tĩnh mà tôi muốn sử dụng thay vì một loại các nhà xây dựng ") và bản thân khái niệm này cũng không ngoại lệ.

Điều đó nói rằng, tất nhiên có những thứ hoàn thành chính xác vai trò tương tự trong công việc của các học viên như các mẫu thiết kế hiện nay. Nhưng bạn sẽ thất vọng khi nghe về chúng: "mánh khóe" điển hình trong những ngày đó là những thứ khá nhàm chán đối với chúng ta bây giờ - ví dụ như các danh sách liên kết đơn lẻ, các vòng lặp được điều khiển bởi một chỉ số tăng trên mỗi lần lặp, truy cập "thông minh" "Các phương pháp dường như không làm gì ngoài việc giúp bạn thay đổi suy nghĩ về các chi tiết triển khai sau này.

Điều đó đúng, những điều mà hiện nay chúng ta coi là - đôi khi thậm chí là một phần của ngôn ngữ chúng ta sử dụng - từng là khái niệm tiên tiến (và đôi khi được bảo vệ ghen tị) chỉ được biết đến bởi các lập trình viên có kinh nghiệm hơn. Rất có thể, hầu như mọi thứ không hoàn toàn tầm thường mà bạn học trong một khóa học lập trình cơ bản ngày nay đã trải qua giai đoạn mà nó tương đương với một "mẫu thiết kế" cho các học viên thời đại. Xây dựng phần mềm có thể chưa phải là một ngành kỹ thuật nghiêm ngặt, nhưng nếu bạn nghiên cứu về nghệ thuật của thập niên 50 và 60, bạn không thể phủ nhận rằng nó đã đi một cách rất lớn kể từ khi bắt đầu.

Mô hình lớn trước đây là lập trình có cấu trúc . Thay vì UML, có nhiều loại sơ đồ khác nhau (biểu đồ luồng, sơ đồ luồng dữ liệu, biểu đồ cấu trúc, v.v.). Sự phát triển chủ yếu là từ trên xuống và theo một quá trình phân rã chức năng. Một trong những ý tưởng cơ bản là cấu trúc chương trình của bạn phải giống với một viên kim cương: Mô-đun chính ở trên cùng, nhô ra thành các mô-đun điều khiển cấp cao, gọi các thói quen trong các mô-đun cấp thấp hơn. Các mô-đun cấp thấp hơn được xây dựng trên các mô-đun cấp thấp hơn, tất cả chúng (về mặt lý thuyết) cuối cùng đã hội tụ trên một số ít các thói quen I / O cơ bản. Các mô-đun cấp cao được cho là chứa logic chương trình, các mô-đun cấp thấp quan tâm nhiều hơn đến tính toàn vẹn dữ liệu và xử lý lỗi.

Các khái niệm quan trọng được giới thiệu trong thời gian này là ẩn thông tin, mô đun hóa và độ gắn kết cao / khớp nối thấp. Xem các tác phẩm của Dave Parnas cho một số bài báo chuyên đề về các chủ đề này. Ngoài ra hãy xem công việc của Larry Constantine, Tom DeMarco và Ed Yourdon.

Tôi cho rằng một cái lớn (bên cạnh chính lập trình có cấu trúc) là khái niệm truyền tay cầm xung quanh - trong OO bạn có một đối tượng và nó chứa trạng thái và chức năng. Quay trở lại trước OO, bạn sẽ có vô số chức năng độc lập và bạn sẽ chuyển giao một số trạng thái giữa chúng - một cookie nếu bạn muốn. Điều này đã cho bạn các nguyên tắc OO mà không thực sự có OO.

Bạn có thể thấy điều này rất nhiều trong mã Win32 cũ, bạn sẽ chuyển qua một TAY, đây sẽ là một loại mờ thể hiện một số trạng thái được phân bổ trong nhân Windows. Bạn có thể tự mình bằng cách chuyển một con trỏ tới một cấu trúc mà trước đây bạn đã phân bổ làm tham số đầu tiên cho các hàm hoạt động trên dữ liệu đó.

Vì chưa ai đề cập đến một điều hiển nhiên: một mẫu thiết kế lớn trong kỷ nguyên thủ tục là Object. Giống như nhiều mẫu thiết kế phổ biến trước đây (ví dụ Subroutine) và sau (ví dụ Iterator), nó trở nên phổ biến đến mức nó thậm chí còn được hỗ trợ ngôn ngữ.

"Máy trạng thái hữu hạn" có thể được tính là Mẫu và các FSM đã được viết (ví dụ: đối với các giao thức truyền thông) sử dụng các ngôn ngữ tiền OO.

Ngoài ra "trình xử lý ngắt" và TSR được sử dụng phổ biến, ví dụ như trên DOS.

Các thuật ngữ như "Mã Spaghetti" và "Điểm thoát duy nhất" thực sự là những trở ngại cho thời đại đó. Ngày nay, chúng ta gọi mã chúng ta không thích "mã spaghetti", nhưng thực sự đó là một tham chiếu đến mã gắn liền với nhau (rất tệ) với GOTO và JMP.

(Hôm nay chúng ta phải chịu "mã ravioli", trong đó mã giống như một nhóm các lớp không liên quan, được đóng gói chặt chẽ, giống như một đĩa ravioli. nhìn?")

"Điểm duy nhất của lối ra" ngày hôm nay chỉ là một sự tái cấu trúc bực bội. Rất nhiều nhà phát triển mà tôi nói chuyện thậm chí chưa từng nghe về nó, và kinh ngạc khi tôi giải thích nó. Nhưng vào thời xưa, điều đó có nghĩa là đừng đột nhiên nhảy ra khỏi khối mã & thành mã spaghetti. Nhảy về phía trước đến cuối logic, sau đó thoát ra một cách duyên dáng.

Trải dài trí nhớ, cách trở lại, tôi dường như nhớ rằng ý tưởng bó mã vào các thủ tục là một bước tiến lớn. Ý tưởng rằng bạn có thể đóng gói các thủ tục thành các Mô-đun có thể tái sử dụng, có thể hoạt động được là loại Chén Thánh lập trình.

EDIT: "Mã tự sửa đổi" cũng là một mẫu được sử dụng đáng chú ý trên Doom gốc. Đó là nơi chương trình thực sự sẽ ghi đè lên các hướng dẫn của nó bằng các hướng dẫn nhanh hơn dựa trên trạng thái của nó. Khi tôi là một ông trùm tham gia khóa học lập trình tại Bảo tàng Khoa học, người hướng dẫn của tôi đã cảnh báo chúng tôi một cách nghiêm khắc, "Đừng viết mã tự sửa đổi!"

EDIT EDIT: Tuy nhiên, trước khi có Internet, từ ngữ đi chậm hơn rất nhiều. Ý tưởng thực hiện các thuật toán và cấu trúc dữ liệu từng là một vấn đề lớn hơn nhiều. Hôm nay tôi sắp xếp mọi lúc mà không biết tôi đang sử dụng loại nào. Nhưng sau đó bạn phải tự viết mã lên. Tôi nhớ một bài báo nói về những thách thức lập trình đã từng mất nhiều ngày mà hôm nay chúng tôi hạ gục trong nửa giờ, hoặc ít hơn. Vì vậy, chương trình "thuật toán" và "cấu trúc dữ liệu" thực sự thú vị có lẽ sẽ nằm trong danh sách, nhiều hơn so với ngày nay.