รูปแบบการออกแบบของยุคการเขียนโปรแกรมขั้นตอนคืออะไร [ปิด]

ที่คล้ายกัน: การเขียนโปรแกรมทำได้อย่างไรเมื่อ 20 ปีที่แล้ว?

OOPเป็นแฟชั่นค่อนข้างปัจจุบันมีรากในSimula 67ในปี 1960 และต่อมาได้รับความนิยมจากสมอลล์ทอล์คและC ++ เรามีหนังสือแห้งหนังสือหลายเล่มเกี่ยวกับรูปแบบการออกแบบในโลกแห่งวัตถุ

แต่สิ่งที่เป็นหลักการสำคัญในการเขียนโปรแกรมก่อนที่จะนำ OOP กระบวนทัศน์ที่กว้าง? และรูปแบบการออกแบบที่สำคัญคืออะไร

ฉันเป็นนักพัฒนา Cobol ก่อนที่ฉันจะเรียนรู้ Java ฉันพัฒนามานานกว่า 35 ปี

ย้อนกลับไปในสมัยของภาษาเชิงโพรเซสซิงส่วนใหญ่ดำเนินการเป็นชุด ย้อนกลับไปไกลพอในประวัติศาสตร์และแม้แต่การคอมไพล์โปรแกรมก็ทำได้โดยใช้การ์ดเจาะเป็นชุด

ตรงกันข้ามกับการยืนยันของ Kilian Foth เรามีรูปแบบการออกแบบย้อนกลับไปในปี 1970 และ 1980 มีวิธีการบางอย่างในการเขียนโค้ดการจับคู่ / รวมหลายไฟล์ใน Cobol มีวิธีการบางอย่างในการเพิ่มโค้ดธุรกรรมลงในไฟล์ master (เทป) ใน Cobol มีวิธีการบางอย่างในการสร้างรหัสรายงานใน Cobol นั่นเป็นเหตุผลที่ Report Writer ของ IBM ไม่เคยได้รับแรงฉุดในร้านค้า Cobol มากมาย

มีการนำหลักการ DRY ไปใช้ก่อนกำหนด สร้างย่อหน้าจำนวนมากเพื่อที่คุณจะได้ไม่ต้องทำซ้ำ เทคนิคการเข้ารหัสแบบโครงสร้างได้รับการพัฒนาในปี 1970 และ Cobol ได้เพิ่มคำที่มีโครงสร้าง (คำกริยา) เข้ากับภาษาในปี 1985

โดยทั่วไปเมื่อเราเขียนโปรแกรม Cobol ใหม่เราคัดลอกโปรแกรม Cobol เก่าและเปลี่ยนชื่อเพื่อปกป้องผู้บริสุทธิ์ เราแทบไม่เคยเขียนโปรแกรม Cobol จากหน้ากระดาษเปล่าหรือหน้าจอเปล่า นั่นเป็นรูปแบบการออกแบบขนาดใหญ่เมื่อคุณสามารถคัดลอกและวางโปรแกรมทั้งหมด

มีรูปแบบการออกแบบ Cobol มากมายที่ต้องใช้เวลาหลายปีสำหรับโปรแกรมเมอร์ Cobol เพื่อเรียนรู้พวกเขาทั้งหมด นั่นเป็นเหตุผลหนึ่งที่โปรแกรมเมอร์ของ Cobol ในปัจจุบันส่วนใหญ่ยังคงใช้ไวยากรณ์ในปี 1985

"รูปแบบการออกแบบ" ในซอฟต์แวร์ไม่มีอยู่ในยุคที่คุณพูดถึงเพราะแนวคิดไม่ได้ถูกคิดค้นขึ้นมา นี่ไม่ใช่ฉันกำลังทะลึ่ง - อันที่จริงมันคือเหตุผล; การถูกเรียกว่าชื่อที่จดจำได้คือสิ่งที่ทำให้รูปแบบการออกแบบเป็น "รูปแบบการออกแบบ" แทนที่จะเป็นรหัสที่คุณใช้ในรูปแบบเดียวหรืออีกรูปแบบหนึ่ง (เช่น "โรงงาน" แทนที่จะเป็น "คลาสแบบคงที่ที่ฉันชอบใช้มากกว่า การจัดประเภทของคอนสตรัคเตอร์ ") และแนวคิดไม่มีข้อยกเว้น

ที่กล่าวว่าแน่นอนว่ามีสิ่งต่าง ๆ ที่เติมเต็มบทบาทเดียวกันในการทำงานของผู้ปฏิบัติงานตามรูปแบบการออกแบบในขณะนี้ แต่คุณจะผิดหวังในการได้ยินเกี่ยวกับพวกเขา: "ปรมาจารย์ของปรมาจารย์" โดยทั่วไปในสมัยนั้นเป็นสิ่งที่น่าเบื่อสำหรับเราในตอนนี้ - เช่นรายการที่เชื่อมโยงโดยลำพังลูปควบคุมโดยดัชนีที่เพิ่มขึ้นในการทำซ้ำแต่ละครั้ง "วิธีการที่ดูเหมือนจะไม่ทำอะไรเลยนอกจากให้คุณเปลี่ยนใจเกี่ยวกับรายละเอียดการใช้งานในภายหลัง

ถูกต้องสิ่งที่เรารับตอนนี้ - บางครั้งก็เป็นส่วนหนึ่งของภาษาที่เราใช้ - เคยเป็นแนวคิดขั้นสูง (และบางครั้งก็มีการป้องกันอย่างหึงหวง) ที่รู้จักกันโดยนักเขียนโค้ดที่มีประสบการณ์มากกว่าเท่านั้น โอกาสที่เกือบทุกอย่างที่คุณไม่ได้เรียนรู้ในหลักสูตรการเขียนโปรแกรมขั้นพื้นฐานทุกวันนี้ต้องผ่านช่วงเวลาที่มีคุณธรรมเทียบเท่ากับ "รูปแบบการออกแบบ" แก่ผู้ปฏิบัติงานในยุคนั้น การสร้างซอฟต์แวร์อาจยังไม่เป็นระเบียบวินัยทางวิศวกรรมที่เข้มงวด แต่ถ้าคุณศึกษาสถานะของยุค 50 และยุค 60 คุณไม่สามารถปฏิเสธได้ว่ามันมีมาอย่างมากมายตั้งแต่เริ่มต้น

กระบวนทัศน์ใหญ่ก่อนหน้านี้ที่มีโครงสร้างการเขียนโปรแกรม แทนที่จะเป็น UML ก็มีไดอะแกรมต่าง ๆ มากมาย (แผนผังลำดับงาน, ไดอะแกรมการไหลของข้อมูล, แผนภูมิโครงสร้าง ฯลฯ ) การพัฒนาส่วนใหญ่จากบนลงล่างและติดตามกระบวนการสลายตัวที่ใช้งานได้ หนึ่งในแนวคิดพื้นฐานคือโครงสร้างของโปรแกรมของคุณควรมีลักษณะคล้ายเพชร: โมดูลหลักที่ด้านบนขยายออกเป็นโมดูลควบคุมระดับสูงซึ่งเรียกใช้รูทีนในโมดูลระดับล่าง โมดูลระดับล่างเหล่านี้สร้างขึ้นจากโมดูลระดับล่างซึ่งทั้งหมดนี้ (ในทางทฤษฎี) ในที่สุดก็มาบรรจบกับกิจวัตร I / O พื้นฐานจำนวนหนึ่ง โมดูลระดับสูงควรประกอบด้วยตรรกะของโปรแกรมส่วนโมดูลระดับล่างนั้นเกี่ยวข้องกับความสมบูรณ์ของข้อมูลและการจัดการข้อผิดพลาดมากกว่า

แนวคิดที่สำคัญที่นำมาใช้ในช่วงเวลานี้คือการซ่อนข้อมูลแบบแยกส่วนและการเชื่อมโยงสูง / การมีเพศสัมพันธ์ต่ำ ดูผลงานของDave Parnasสำหรับงานเอกสารบางเรื่องในหัวข้อเหล่านี้ ตรวจสอบงานของ Larry Constantine, Tom DeMarco และ Ed Yourdon

ฉันคิดว่าหนึ่งที่มีขนาดใหญ่ (นอกเหนือจากการเขียนโปรแกรมที่มีโครงสร้างตัวเอง) เป็นแนวคิดของการผ่านการจัดการรอบ - ใน OO คุณมีวัตถุและมันมีสถานะและการทำงาน ย้อนกลับไปก่อน OO คุณจะมีฟังก์ชั่นอิสระมากมายและคุณจะผ่านการจัดการไปยังสถานะระหว่างพวกเขา - คุกกี้หากคุณต้องการ สิ่งนี้ทำให้คุณมีหลักการ OO โดยไม่ต้องมี OO จริงๆ

คุณสามารถเห็นสิ่งนี้ได้มากมายในรหัส Win32 เก่าคุณจะต้องผ่านใน HANDLE ซึ่งจะเป็นประเภททึบแสงที่แสดงถึงสถานะบางอย่างที่จัดสรรในเคอร์เนลของ Windows คุณสามารถทำได้ด้วยการส่งตัวชี้ไปที่ struct ที่คุณเคยจัดสรรไว้ก่อนหน้านี้เป็นพารามิเตอร์แรกให้กับฟังก์ชันที่ทำงานกับข้อมูลนั้น

เนื่องจากยังไม่มีใครพูดถึงสิ่งที่ชัดเจน: รูปแบบการออกแบบที่ยิ่งใหญ่หนึ่งอย่างในยุคกระบวนการคือ Object เช่นรูปแบบการออกแบบที่ได้รับความนิยมมาก่อน (เช่น Subroutine) และหลังจาก (เช่น Iterator) มันก็กลายเป็นที่นิยมมากจนได้รับการสนับสนุนทางภาษา

"เครื่องสถานะ จำกัด " อาจนับเป็นรูปแบบและ FSM ถูกเขียนขึ้น (เช่นสำหรับโปรโตคอลการสื่อสาร) โดยใช้ภาษาก่อน OO

นอกจากนี้ "ตัวจัดการขัดจังหวะ" และTSR ก็เคยเป็นที่นิยมเช่นใน DOS

คำเช่น "Spaghetti Code" และ "Single Point of Exit" เป็นข้อผิดพลาดในยุคนั้น ทุกวันนี้เราเรียกรหัสว่าเราไม่ชอบ "รหัสสปาเก็ตตี้" แต่จริงๆแล้วเป็นการอ้างอิงถึงรหัสที่ผูกติดกัน (ไม่ดี) กับ GOTO และ JMPs

(วันนี้เราประสบกับ "รหัสราวีโอลี่" ซึ่งเป็นรหัสของคลาสที่ไม่เกี่ยวข้องและแพ็คแน่นคลาสเหมือนราวีโอลี่อย่างไรก็ตามผู้เชี่ยวชาญ OO บางคนถามอย่างสมเหตุสมผล "แต่ไม่ใช่ว่า OO ควรจะทำอะไร ดูเหมือน?")

"Single Point of Exit" ในวันนี้เป็นเพียงแผนการซ่อมบำรุงที่น่าผิดหวัง Devs จำนวนมากที่ฉันคุยด้วยยังไม่เคยได้ยินเลยและรู้สึกประหลาดใจเมื่อฉันอธิบาย แต่ในสมัยก่อนมันหมายถึงอย่ากระโดดออกจากบล็อครหัสในทันที & เป็นสปาเก็ตตี้โค้ด ข้ามไปยังจุดสิ้นสุดของตรรกะจากนั้นออกอย่างงดงาม

การยืดหน่วยความจำของฉันกลับไปฉันดูเหมือนจะจำได้ว่าความคิดในการรวมรหัสเข้าสู่ขั้นตอนนั้นเป็นการก้าวกระโดดครั้งใหญ่ แนวคิดที่ว่าคุณสามารถจัดทำแพ็กเกจลงในโมดูลที่ทำงานร่วมกันได้และนำกลับมาใช้ใหม่ได้นั้นเป็นจอกศักดิ์สิทธิ์ของโปรแกรม

แก้ไข: "รหัสแก้ไขตัวเอง" ก็เป็นรูปแบบที่ใช้โดยเฉพาะอย่างยิ่งใน Doom เดิม นั่นคือสิ่งที่โปรแกรมจะเขียนทับคำสั่งจริงด้วยคำสั่งที่เร็วขึ้นโดยอ้างอิงจากสถานะของมัน เมื่อฉันเป็นคนทีกำลังเรียนหลักสูตรการเขียนโปรแกรมที่พิพิธภัณฑ์วิทยาศาสตร์ผู้สอนของฉันเตือนเราอย่างเข้มงวดว่า "อย่าเขียนรหัสที่แก้ไขเองได้!"

แก้ไขแก้ไข: อย่างไรก็ตามก่อนที่คำว่าอินเทอร์เน็ตจะเดินทางช้ากว่านี้มาก แนวคิดของการใช้อัลกอริทึมและโครงสร้างข้อมูลเคยเป็นข้อตกลงที่ใหญ่กว่ามาก วันนี้ฉันจะเรียงลำดับตลอดเวลาโดยไม่ได้รู้ว่าฉันกำลังเรียงลำดับอะไร แต่ก่อนหน้านี้คุณต้องเขียนโค้ดเอง ฉันจำได้ว่ามีบทความหนึ่งที่พูดถึงความท้าทายในการเขียนโปรแกรมที่เคยใช้เวลาหลายวันในวันนี้เราทำให้ล้มลงในครึ่งชั่วโมงหรือน้อยกว่านั้น ดังนั้นการเขียนโปรแกรม "อัลกอริทึม" และ "โครงสร้างข้อมูล" ที่รัดกุมจริงๆอาจอยู่ในรายการมากกว่าวันนี้