คำถามติดแท็ก paradigms

รูปแบบพื้นฐานของการเขียนโปรแกรมคอมพิวเตอร์

4
ความแตกต่างระหว่างการเขียนโปรแกรมที่จำเป็นขั้นตอนและมีโครงสร้างคืออะไร?
จากการค้นคว้าข้อมูล (หนังสือ, Wikipedia, คำถามที่คล้ายกันใน SE และอื่น ๆ ) ฉันมาทำความเข้าใจว่าการเขียนโปรแกรมที่จำเป็นเป็นหนึ่งในกระบวนทัศน์การเขียนโปรแกรมที่สำคัญซึ่งคุณอธิบายชุดคำสั่ง (หรือคำสั่ง) เพื่อให้คอมพิวเตอร์ทำงานได้ มากเพื่อที่จะดำเนินการเฉพาะดังนั้นชื่อ "จำเป็น") จนถึงตอนนี้ดีมาก ในทางกลับกันการเขียนโปรแกรมตามขั้นตอนเป็นประเภทเฉพาะ (หรือชุดย่อย) ของการโปรแกรมเชิงซ้อนซึ่งคุณใช้ขั้นตอน (เช่นฟังก์ชั่น) เพื่ออธิบายคำสั่งที่คอมพิวเตอร์ควรทำ คำถามแรก : มีภาษาโปรแกรมที่จำเป็นซึ่งไม่ได้เป็นขั้นตอนหรือไม่? กล่าวอีกนัยหนึ่งคุณสามารถตั้งโปรแกรมที่จำเป็นโดยไม่ต้องดำเนินการได้หรือไม่? ปรับปรุง : คำถามแรกนี้ดูเหมือนว่าจะตอบ ภาษามีความจำเป็นโดยไม่ต้องมีขั้นตอนหรือโครงสร้าง ตัวอย่างคือภาษาแอสเซมบลีบริสุทธิ์ จากนั้นคุณก็มีโปรแกรมแบบมีโครงสร้างซึ่งน่าจะเป็นประเภทอื่น (หรือส่วนย่อย) ของการโปรแกรมแบบไม่มีความจำเป็นซึ่งเกิดขึ้นเพื่อลบการเชื่อมั่นในคำสั่ง GOTO คำถามที่สอง : ความแตกต่างระหว่างการเขียนโปรแกรมแบบขั้นตอนและแบบโครงสร้างคืออะไร คุณสามารถมีหนึ่งโดยไม่มีอื่น ๆ และในทางกลับกัน? เราสามารถพูดได้หรือไม่ว่าการเขียนโปรแกรมเชิงกระบวนงานเป็นส่วนหนึ่งของการเขียนโปรแกรมเชิงโครงสร้างเช่นเดียวกับในภาพ

3
เหตุใดโมเดลโดเมน anemic จึงถือว่าไม่ดีใน C # / OOP แต่สำคัญมากใน F # / FP
ในโพสต์บล็อกใน F # เพื่อความสนุกสนานและผลกำไรกล่าวว่า: ในการออกแบบฟังก์ชั่นมันสำคัญมากที่จะแยกพฤติกรรมออกจากข้อมูล ชนิดข้อมูลนั้นง่ายและ "โง่" จากนั้นคุณก็มีฟังก์ชั่นหลายอย่างที่ทำงานกับชนิดข้อมูลเหล่านั้น สิ่งนี้เป็นสิ่งที่ตรงกันข้ามกับการออกแบบเชิงวัตถุที่มีการรวมพฤติกรรมและข้อมูลเข้าด้วยกัน ท้ายที่สุดแล้วนั่นคือสิ่งที่ชั้นเรียน ในความเป็นจริงการออกแบบเชิงวัตถุในความเป็นจริงคุณไม่ควรมี แต่พฤติกรรม - ข้อมูลเป็นส่วนตัวและสามารถเข้าถึงได้ผ่านวิธีการ ในความเป็นจริงอู๊ดไม่ได้มีพฤติกรรมพอรอบประเภทข้อมูลถือเป็นสิ่งที่ไม่ดีและยังมีชื่อ: ความ " รูปแบบโดเมนโลหิตจาง " ระบุว่าใน C # เราดูเหมือนจะยืมต่อจาก F # และพยายามเขียนโค้ดสไตล์การทำงานมากขึ้น ทำไมเราไม่ยืมความคิดในการแยกข้อมูล / พฤติกรรมและคิดว่ามันไม่ดี? มันเป็นเพียงแค่ว่าคำจำกัดความไม่ได้มาพร้อมกับ OOP หรือมีเหตุผลที่เป็นรูปธรรมว่ามันไม่ดีใน C # ที่ด้วยเหตุผลบางอย่างไม่ได้ใช้ใน F # (และในความเป็นจริงจะกลับรายการ)? (หมายเหตุ: ฉันสนใจเป็นพิเศษในความแตกต่างใน C # / F # ที่สามารถเปลี่ยนความคิดเห็นของสิ่งที่ดี / ไม่ดีแทนที่จะเป็นบุคคลที่อาจไม่เห็นด้วยกับความเห็นทั้งในโพสต์บล็อก)

7
Haskell AND Lisp vs. Haskell หรือ Lisp [ปิด]
ปัจจุบันฉันใช้รหัสกับ C, C ++ และ Python ฉันต้องการรับภาษาโปรแกรมที่ใช้งานได้และตอนนี้ฉันกำลังโน้มตัวไปหา Haskell ฉันไม่ต้องการเริ่มสงคราม "Haskell vs Lisp" ที่นี่; สิ่งที่ฉันต้องการรู้คือ: ถ้าฉันเรียนรู้ Haskell เป็นหลักสำหรับการเปิดรับฟังก์ชั่นการเขียนโปรแกรมฉันจะได้ประโยชน์อะไรจากการเรียนรู้ Lisp ในภายหลัง

9
ฉันจะเอาชนะอัมพาตโดยการวิเคราะห์ได้อย่างไรเมื่อเขียนโค้ด?
เมื่อฉันเริ่มโครงการใหม่ฉันมักจะเริ่มคิดเกี่ยวกับรายละเอียดของการดำเนินการทันที "ฉันจะวาง DataBaseHandler ไว้ที่ไหนฉันควรใช้มันอย่างไรคลาสที่ต้องการใช้มันขยายจาก Abstractclass superclass บางส่วน .. ฉันควรใช้อินเทอร์เฟซหรือไม่ฉันจะใช้อินเทอร์เฟซในระดับใด วิธีในการส่งคำขอและการแยกวิเคราะห์ข้อมูล " ฉันสิ้นสุดการถ่วงเวลานานเพราะฉันต้องการรหัสสำหรับความสามารถในการขยายและการนำกลับมาใช้ใหม่ แต่ฉันรู้สึกว่าแทบจะเป็นไปไม่ได้เลยที่จะคิดถึงอดีตเกี่ยวกับวิธีการนำไปใช้อย่างสมบูรณ์ แล้วถ้าฉันพยายามจะพูดว่า "ขันมันให้เสร็จแล้ว!" ฉันก็ชนกำแพงอิฐอย่างรวดเร็วเพราะรหัสของฉันไม่ได้จัดระเบียบฉันผสมระดับนามธรรมต่าง ๆ เป็นต้น คุณมีเทคนิค / วิธีการอะไรบ้างในการเปิดตัวโครงการใหม่ในขณะที่ตั้งค่าโครงสร้างแบบลอจิคัล / แบบแยกส่วนที่จะขยายได้ดี - -แก้ไข - - นี่เป็นประเภทของคำถามที่ตอบรับยากแล้ว แต่ต้องการได้รับคำติชมเพิ่มเติมดูว่ามีฉันทามติบ้างไหม TDD ฟังดูเจ๋งจริงๆและตรงไปตรงมาฉันหมายถึงการเพิ่มความเร็วในการใช้ JUnit ฯลฯ ในเวลาเดียวกันแฟน ๆ ของ TDD คิดอย่างไรเกี่ยวกับความจริงที่ว่าจุดที่ถูกต้องตามกฎหมายที่เกี่ยวข้องกับการแก้ไข TDD ของฉัน ปัญหาเฉพาะคือ TDD ไม่ได้ตอบคำถามการออกแบบ แน่นอนว่าฉันเห็นด้วยกับ TDD จะช่วยฉันกำหนดสิ่งที่ฉันต้องการจะทำและจากนั้นฉันสามารถค่อยๆทำตามวิธีได้ แต่มีรูปแบบ / โครงสร้างการออกแบบโดยรวมที่แตกต่างกันมากมายที่ทุกคนสามารถผ่านการทดสอบหน่วยได้ นั่นเป็นเพียงแค่มันทดสอบหน่วยเดียว …

1
การเขียนโปรแกรมแบบตารางคืออะไร
การเขียนโปรแกรมภาษาเหยี่ยวประกาศตัวเองเป็นสนับสนุนการเขียนโปรแกรมแบบตาราง: ฟอลคอนมีกระบวนทัศน์การโปรแกรมมิงแบบรวมหก: ขั้นตอน, เชิงวัตถุ, ต้นแบบเชิง, หน้าที่, ตารางและข้อความ และคุณไม่จำเป็นต้องควบคุมพวกเขาทั้งหมด คุณเพียงแค่ต้องเลือกส่วนผสมที่คุณต้องการและปล่อยให้รหัสติดตามแรงบันดาลใจของคุณ เอกสารขยายบิตเกี่ยวกับวิธีรสชาติของภาษาในการเขียนโปรแกรมตารางทำงาน แต่มุ่งเน้นไปที่ภาษาของเค้าเองและไวยากรณ์และไม่ได้จริงๆอธิบายประโยชน์ของกระบวนทัศน์ (ยกเว้นของหลักสูตรที่จะเห็นได้ชัดจากตัวอย่างง่าย ๆ ) . ฉันบิตสับสนเกี่ยวกับวิธีการสิ่งที่ทั้งทำงานภายในจากสิ่งที่ฉันเข้าใจเหยี่ยวTableเป็นโครงสร้างพื้นเมืองที่ผลงานมากหรือน้อยเป็นตารางสัมพันธ์และสามารถอธิบายได้ (ใน OO พื้นถิ่น) เป็นพื้นเมืองตั้งค่าการบันทึกที่มีความสามารถสอบถามเชิงสัมพันธ์ . ฉันรู้รายละเอียดที่น่ากลัว (ตำหนิ OO รากเหง้าของฉันและโทษของเตกีล่าหลายปี) คุณช่วยให้ฉันได้ความคิดที่ดีขึ้นเกี่ยวกับการเขียนโปรแกรมแบบตารางคืออะไรเกี่ยวกับและมันทำงานอย่างไรภายใน? ชี้แจง:ฉันกำลังไม่ได้ถามเกี่ยวกับตารางแบบการเขียนโปรแกรม
34 paradigms 

3
ข้อผิดพลาดในการพิจารณาการจัดการ
ปัญหา: ตั้งแต่เวลานานฉันกังวลเกี่ยวกับexceptionsกลไกเพราะฉันรู้สึกว่ามันไม่ได้แก้ไขสิ่งที่ควร เคลม: มีการถกเถียงกันนานเกี่ยวกับหัวข้อนี้และพวกเขาส่วนใหญ่มักจะพยายามเปรียบเทียบexceptionsและส่งกลับรหัสข้อผิดพลาด นี่ไม่ใช่หัวข้อที่แน่นอน พยายามกำหนดข้อผิดพลาดฉันจะเห็นด้วยกับ CppCoreGuidelines จาก Bjarne Stroustrup & Herb Sutter ข้อผิดพลาดหมายความว่าฟังก์ชันไม่สามารถบรรลุวัตถุประสงค์ที่โฆษณาไว้ การเรียกร้อง: exceptionกลไกคือ semantic ภาษาสำหรับการจัดการข้อผิดพลาด การเรียกร้อง: สำหรับฉันมี "ไม่มีข้อแก้ตัว" สำหรับฟังก์ชั่นที่ไม่ได้งาน: เพราะเรากำหนดเงื่อนไขล่วงหน้า / โพสต์ผิดดังนั้นฟังก์ชันไม่สามารถรับประกันผลลัพธ์ได้หรือกรณีพิเศษบางกรณีไม่ถือว่าสำคัญพอสำหรับการใช้เวลาในการพัฒนา ทางออก เมื่อพิจารณาแล้ว IMO ความแตกต่างระหว่างการจัดการรหัสปกติและรหัสข้อผิดพลาดคือ (ก่อนการติดตั้ง) บรรทัดที่เป็นอัตนัย การเรียกร้อง: การใช้ข้อยกเว้นเพื่อระบุว่าเมื่อใดที่ไม่ได้รักษาเงื่อนไขก่อนหรือหลังการโพสต์ไว้เป็นอีกจุดประสงค์หนึ่งของexceptionกลไก ฉันไม่ได้กำหนดเป้าหมายการใช้งานของexceptionsที่นี่ ในหนังสือหลายบทช่วยสอนและแหล่งข้อมูลอื่น ๆ พวกเขามักจะแสดงการจัดการข้อผิดพลาดเป็นศาสตร์ที่ค่อนข้างมีวัตถุประสงค์ซึ่งแก้ไขได้ด้วยexceptionsและคุณเพียงแค่ต้องการให้catchพวกเขามีซอฟต์แวร์ที่แข็งแกร่งสามารถกู้คืนจากสถานการณ์ใด ๆ แต่เป็นเวลาหลายปีในฐานะนักพัฒนาทำให้ฉันเห็นปัญหาจากแนวทางที่แตกต่าง: โปรแกรมเมอร์มีแนวโน้มที่จะทำให้งานของพวกเขาง่ายขึ้นโดยการโยนข้อยกเว้นเมื่อกรณีที่เฉพาะเจาะจงดูยากเกินกว่าที่จะดำเนินการอย่างระมัดระวัง กรณีทั่วไปนี้คือ: ปัญหาหน่วยความจำไม่เพียงพอ, ปัญหาเต็มรูปแบบดิสก์, ปัญหาไฟล์ที่เสียหายเป็นต้นซึ่งอาจเพียงพอ แต่ไม่สามารถตัดสินใจได้เสมอจากระดับสถาปัตยกรรม โปรแกรมเมอร์ไม่อ่านเอกสารอย่างละเอียดเกี่ยวกับข้อยกเว้นในไลบรารีและมักจะไม่ทราบว่าเมื่อใดและเมื่อใด นอกจากนี้แม้ว่าพวกเขารู้ว่าพวกเขาไม่ได้จัดการพวกเขาจริงๆ โปรแกรมเมอร์มักจะไม่ได้รับข้อยกเว้นเร็วพอและเมื่อพวกเขาทำมันส่วนใหญ่จะเข้าสู่ระบบและโยนต่อไป (อ้างถึงจุดแรก) สิ่งนี้มีสองผล: …

5
การโปรแกรมในปรัชญา UNIX เหมือนกับการเขียนโปรแกรมเชิงหน้าที่หรือไม่?
สภาพแวดล้อมการเขียนโปรแกรม UNIX (ข้อความคลาสสิก) ระบุว่าวิธี UNIX ในการเขียนโปรแกรมคือการสร้างเครื่องมือขนาดเล็กที่กำหนดอย่างดีซึ่งสามารถรวมกันเพื่อแก้ไขปัญหาที่ซับซ้อนมากขึ้น ในการเรียนรู้ C และ Bash shell ฉันพบว่านี่เป็นแนวคิดที่ทรงพลังที่สามารถใช้เพื่อจัดการกับปัญหาการเขียนโปรแกรมที่หลากหลาย เพียงแค่ใช้แพลตฟอร์ม Linux แนวคิดนั้นค่อนข้างชัดเจนและใช้งานได้ตลอดเวลา การแสดงออกใด ๆ ที่เกิดขึ้นในบรรทัดคำสั่งที่เปลี่ยนเส้นทาง I / O, การเชื่อมโยงเครื่องมือระบบเช่น ls, grep, อื่น ๆ และอื่น ๆ แสดงให้เห็นว่าแนวคิดนี้มีประสิทธิภาพเพียงใด สิ่งที่ทำให้ฉันสับสนคือหลายโปรแกรมเหล่านี้เขียนด้วยภาษา C โดยใช้รูปแบบการเขียนโปรแกรมที่จำเป็น / ขั้นตอน แต่วิธีที่พวกเขาใช้และเชื่อมต่อเข้าด้วยกันในบรรทัดคำสั่งนั้นดูเหมือนโปรแกรมการทำงานกับฉันมากขึ้น ฟังก์ชั่นแยกที่ไม่ได้ขึ้นอยู่กับสถานะของโปรแกรมอื่น ๆ ที่มันอาจจะเข้าร่วม สิ่งนี้ถูกต้องหรือไม่การเข้าใจปรัชญาการเขียนโปรแกรมของ UNIX นั้นคือการเขียนโปรแกรมที่ใช้งานได้โดยใช้เครื่องมือที่อาจสร้างขึ้นโดยใช้รูปแบบการเขียนโปรแกรมที่จำเป็น?

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

13
ความเห็นที่ดีที่สุดของคุณกับการเขียนโปรแกรมการทำงานคืออะไร? [ปิด]
ตามที่เป็นอยู่ในปัจจุบันคำถามนี้ไม่เหมาะสำหรับรูปแบบคำถาม & คำตอบของเรา เราคาดหวังคำตอบที่จะได้รับการสนับสนุนจากข้อเท็จจริงการอ้างอิงหรือความเชี่ยวชาญ แต่คำถามนี้อาจเรียกร้องให้มีการถกเถียงอภิปรายโต้แย้งหรือการอภิปรายเพิ่มเติม หากคุณรู้สึกว่าคำถามนี้สามารถปรับปรุงและเปิดใหม่ได้โปรดไปที่ศูนย์ช่วยเหลือเพื่อขอคำแนะนำ ปิดให้บริการใน8 ปีที่ผ่านมา ฟังก์ชั่นการเขียนโปรแกรมเป็นหนึ่งในกระบวนทัศน์การเขียนโปรแกรมที่เก่าแก่ที่สุด อย่างไรก็ตามมันไม่ได้ใช้มากในอุตสาหกรรมเมื่อเทียบกับกระบวนทัศน์ที่เป็นที่นิยมมากขึ้น แต่ส่วนใหญ่จะเน้นในด้านวิชาการ ความเห็นที่ดีที่สุดของคุณกับการเขียนโปรแกรมฟังก์ชั่นคืออะไร?

5
การเรียนรู้ภาษาการเขียนโปรแกรมแต่ละประเภท
ฉันเคยได้ยินหลายครั้งว่าโปรแกรมเมอร์ทุกคนควรเรียนรู้ภาษาใดภาษาหนึ่งในแต่ละประเภท ตอนนี้มันไม่จำเป็นจริง แต่ฉันเชื่อว่ามันเป็นความคิดที่ดี ฉันได้เรียนรู้ภาษาขั้นตอน (Perl) แต่มีประเภทอื่นคืออะไร อะไรคือความแตกต่างระหว่างพวกเขาและสิ่งที่เป็นตัวอย่างของแต่ละคน?

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

11
OOP เป็นรูปแบบการเขียนโปรแกรมที่โดดเด่นในโลกแห่งความจริงหรือไม่
วัตถุไม่เคย? ดีแทบจะไม่เคย ในส่วน VIEWPOINT ของ Communications of The ACM ฉันพบบทความที่น่าสนใจเรื่อง " Objects Never? Well, Hardly Ever " มันเป็นมุมมองที่แตกต่างอย่างสิ้นเชิงจากวัตถุแรกหรือวัตถุช้า เขาแนะนำ "ไม่เคยมีวัตถุ" หรืออาจเป็น "โรงเรียนที่สำเร็จการศึกษาจากวัตถุ" ผู้เขียนพูดคุยเกี่ยวกับ OOP และตั้งคำถามเกี่ยวกับวิธีการใช้ OOP ในสภาพแวดล้อมการเขียนโปรแกรมในโลกแห่งความเป็นจริง เขาคิดว่า OOP ไม่ใช่รูปแบบการเขียนโปรแกรมที่โดดเด่น ตัวอย่างเช่นเขาอ้างว่า 70% ของการเขียนโปรแกรมเสร็จแล้วสำหรับระบบสมองกลฝังตัวที่ OOP ไม่เหมาะจริง ๆ เมื่ออาจารย์ในมหาวิทยาลัยต้องการพูดคุยเกี่ยวกับประโยชน์ของ OOP พวกเขาจะพูดถึงการใช้รหัสซ้ำ อีกตัวอย่างเขาอ้างว่านี่ไม่ใช่กรณีจริงในโลกแห่งความเป็นจริง การใช้ซ้ำรหัสนั้นยากกว่าสิ่งที่อ้างในมหาวิทยาลัย: ฉันอ้างว่าการใช้ OOP นั้นไม่เป็นที่แพร่หลายเหมือนที่คนส่วนใหญ่เชื่อว่ามันไม่ประสบความสำเร็จเท่าที่ผู้เสนอเรียกร้องและดังนั้นที่กลางของมันในหลักสูตร CS ไม่ได้เป็นธรรม เป็นเรื่องที่น่าสนใจสำหรับฉันที่จะรู้ว่าผู้คนในกองซ้อนกันคิดอย่างไรกับเรื่องนี้? OOP เป็นรูปแบบการเขียนโปรแกรมที่โดดเด่นจากมุมมองของโปรแกรมเมอร์หรือไม่? ถ้าฉันควรเลือก …

6
เป็นความคิดที่ดีหรือไม่ที่จะทำ UI 100% ใน Javascript และให้ข้อมูลผ่าน API
งานวันหลักของฉันคือการสร้างแอปพลิเคชัน HTML เมื่อฉันหมายถึงแอปพลิเคชันประเภท CRUD ที่ใช้ภายในซึ่งมี Gridviews ที่สามารถแก้ไขได้จำนวนมากกล่องข้อความดร็อปดาวน์และอื่น ๆ เรากำลังใช้เว็บฟอร์ม ASP.NET ซึ่งทำให้งานเสร็จ แต่ประสิทธิภาพส่วนใหญ่ค่อนข้างแย่และบ่อยครั้งที่คุณ ต้องกระโดดผ่านห่วงเพื่อให้ได้สิ่งที่คุณต้องการ ห่วงที่ห้อยลงมาจากเพดานและติดไฟ ดังนั้นฉันสงสัยว่ามันอาจจะเป็นความคิดที่ดีที่จะย้าย UI ทั้งหมดไปยังด้าน JavaScript พัฒนาชุดการควบคุมที่สามารถนำกลับมาใช้ใหม่ได้ซึ่งปรับให้เหมาะกับความต้องการของเราโดยเฉพาะและแลกเปลี่ยนข้อมูลกับเซิร์ฟเวอร์เท่านั้น ใช่ฉันชอบกระบวนทัศน์ "ควบคุม" (aka "วิดเจ็ต") ซึ่งค่อนข้างเหมาะกับแอปพลิเคชันดังกล่าว ดังนั้นในฝั่งเซิร์ฟเวอร์เรายังคงมีรูปแบบพื้นฐานไปยังมาร์กอัป ASPX ปัจจุบันของเรา แต่จากนั้นจะถูกส่งไปยังลูกค้าเพียงครั้งเดียวและส่วน Javascript จะดูแลการปรับปรุง UI ต่อไปทั้งหมด ปัญหาคือฉันไม่เคยทำแบบนี้มาก่อนและฉันไม่เคยเห็นใครทำแบบนี้มาก่อนเลยไม่รู้ว่าปัญหาจะเป็นอย่างไร โดยเฉพาะอย่างยิ่งฉันกังวลเกี่ยวกับ: ประสิทธิภาพยังคง การเปรียบเทียบแสดงให้เห็นว่าในปัจจุบันความล่าช้าหลักอยู่ที่ฝั่งไคลเอ็นต์เมื่อเบราว์เซอร์พยายามที่จะแสดงผลหน้าส่วนใหญ่อีกครั้งหลังจากการอัพเดต AJAX มาร์กอัป ASP.NET webforms ที่สร้างขึ้นให้ความหมายใหม่กับคำว่า "เว็บ" และตัวควบคุม Devexpress ที่หลากหลายเพิ่มเลเยอร์ Javascript ที่ซับซ้อนของตัวเอง แต่จะเร็วกว่าที่จะคำนวณการเปลี่ยนแปลงที่จำเป็นทั้งหมดในด้าน Javascript แล้วอัปเดตเฉพาะสิ่งที่จำเป็นต้องได้รับการปรับปรุง …

7
สำหรับปัญหาอะไรคือการเขียนโปรแกรมเชิงวัตถุไม่ใช่ทางเลือกที่ดี? [ปิด]
ปิด คำถามนี้จะต้องมีมากขึ้นมุ่งเน้น ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้มุ่งเน้นที่ปัญหาเดียวโดยแก้ไขโพสต์นี้ ปิดให้บริการใน2 ปีที่ผ่านมา อะไรเป็นแรงบันดาลใจจากคำถามนี้: สำหรับปัญหาที่พบบ่อยคือการตั้งโปรแกรมการทำงานที่ไม่เหมาะสม - แต่อย่างไรก็ตามคำถามที่ฉันต้องการเสมอ แต่ก็กลัวที่จะถาม ฉันอยู่ใน ... ดีมาเรียกมันว่าการพัฒนาซอฟต์แวร์ทางวิศวกรรมเกือบตลอดชีวิตของฉันและในช่วงเวลานั้นถึงแม้ว่า OO จะอยู่ที่นั่นเสมอ ( ส่วนใหญ่แล้ว) ฉันไม่เคยต้องการใช้ "วิธีการของมัน" หรือเรียนรู้กระบวนทัศน์นั้น เราใช้โครงสร้างของโปรแกรมที่ค่อนข้างง่ายรูทีน / ฟังก์ชั่น / โมดูลและตรงข้ามกับแนวปฏิบัติที่ดีที่สุดของวันนี้ในการจัดการโปรแกรมเหล่านั้น (โปรแกรมที่มีความยาวไม่เกิน 300k LOC ไม่มีอะไรใหญ่เกินไป) ไม่เคยพิสูจน์ว่าเป็นเรื่องยาก ดังนั้นฉันอยากถามคุณว่าอะไรคือปัญหาการเรียงลำดับที่กระบวนทัศน์เชิงวัตถุจะไม่เป็นทางเลือกที่ดี? ในการเปรียบเทียบกับการเขียนโปรแกรมขั้นตอน?
19 paradigms 

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

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.