รหัสขั้นตอนเทียบกับรหัส OOP

19

ฉันทำโปรเจ็กต์เสร็จสิ้นด้วย PHP ของ 13000+ บรรทัดในสไตล์โพรซีเดอร์ [เพราะฉันคุ้นเคยกับมันมากแม้ว่าฉันจะรู้จัก OOP] และโครงการก็ทำงานได้อย่างสมบูรณ์แบบ

แต่ฉันควรแปลงเป็น OOP หรือไม่ [ เพราะโลกกำลังยุ่งกับ OOP ]

รหัสของฉันไม่ต้องการคุณสมบัติใด ๆ ของ OOP [การห่อหุ้มการสืบทอดโดยทั่วไป ... ]!

แล้วฉันควรทำอย่างไรดี?

และความช่วยเหลือแบบไหนที่ฉันจะได้รับถ้าฉันแปลงเป็น OOP

programming-languages programming-practices

— Sourav
แหล่งที่มา

21

โปรดแจ้งให้เราทราบหากคุณต้องแก้ไขโครงการนี้ มันจะน่าสนใจที่จะรู้ว่าถ้าคุณดีใจที่คุณตัดสินใจหรือเสียใจ

— JeffO

2

คุณต้องการการห่อหุ้ม OO เป็นวิธีหนึ่งในการรับ บางทีคุณอาจมีอีกวิธีหนึ่งที่เหมาะกับคุณ แต่ไม่ทางใดก็ทางหนึ่งคุณต้องควบคุมการพึ่งพารหัส

— Marcin

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

— Pandincus

ใช่มันคุ้มค่า การเปิดประตูให้นำกลับมาใช้ใหม่ได้นั้นคุ้มค่าเสมอ

— Chani

1

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

— Kamil Tomšík

52

รหัสของฉันไม่ต้องการคุณสมบัติใด ๆ ของ OOP

คุณได้ตอบคำถามของคุณเอง - ถ้าคุณไม่ต้องการ OOP ในกรณีนี้และโครงการของคุณกำลังทำงานอยู่ก็ไม่ต้องแปลง

อย่างไรก็ตามคุณควรดูที่การใช้ OOP สำหรับโครงการถัดไปของคุณ- แต่ถ้าเหมาะสม

ไม่มีอะไรผิดปกติกับการเขียนโปรแกรมขั้นตอน - ตราบใดที่มันถูกใช้ในสถานที่ที่เหมาะสม

— ChrisF
แหล่งที่มา

2

+1 จากการยอมรับ "คุณควรดูที่การใช้ OOP สำหรับโครงการถัดไปของคุณ"

— Cary Chow

11

+1 ใช่ถ้าทำงานถูกต้องจะไม่แก้ไข

— setzamora

4

ฉันจะบอกว่าถ้ามันทำงานได้อย่างถูกต้องตอนนี้อย่าเปลี่ยนมัน แต่คุณไม่มีทางรู้ว่าสิ่งที่ร้องขอคุณสมบัติต่อไปจะเป็นอย่างไร

— JeffO

7

"คุณควรดูที่การใช้ OOP สำหรับโครงการถัดไปของคุณ" แต่อย่าใช้มันหากไม่เหมาะสม บางสิ่งเขียนได้ดีขึ้นในทางปฏิบัติบางอย่างเหมาะสำหรับ OOP ใช้สิ่งที่เหมาะสม

— TMN

@TMN - โดยนัย - ฉันควรทำให้ชัดเจน

— ChrisF

16

ไม่และไม่ใช่เพียงเพราะคุณไม่ต้องการ OOP

หากโปรแกรมของคุณเสร็จสิ้นและทำงานได้อย่างน่าพอใจแล้วกว่า 90% ของเวลามันเป็นเวลาที่เหมาะสมในการเขียนโค้ดที่เสร็จสมบูรณ์แล้วด้วยเหตุผลใดก็ตาม

OOP ไม่ได้มีประสิทธิภาพเลยมีสถานที่มากมายที่ไม่ควรใช้ OOP ดังนั้นอย่าใช้เพียงเพราะ OOP เป็นเทรนด์

— Skeith
แหล่งที่มา

1

โดย "รหัสเสร็จ" คุณหมายถึงมันทำงานอย่างไร

— JeffO

@eff O ใช่ครับ! เป็นที่สมบูรณ์แบบ :)

— 35425 Sourav

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

— Skeith

โปรดอธิบายรายละเอียดเกี่ยวกับ "สถานที่มากมายที่ไม่ควรใช้ OOP"

— เหยี่ยว

3

@ ฟอลคอนไม่ว่ารหัส OOP ของคุณจะออกแบบมาได้ดีเพียงใด แต่ถ้าโดเมนที่มีปัญหานั้นแมปกับโมเดล OO ได้ไม่ดีการออกแบบ OOP ของคุณจะถูกผูกมัดไว้อย่างบ้าคลั่ง มีโหลดของโดเมนปัญหาที่ไม่ควรที่จะแสดงในรูปของ OOP

— SK-logic

8

ทั่วไปของฉันใช้กระบวนทัศน์ (และทำไมไม่มีกระบวนทัศน์หลักสามข้อใดในวิธีที่ถูกต้องหรือเป็นวิธีที่ผิดในการเขียนโปรแกรม):

การเขียนโปรแกรมตามขั้นตอนนั้นดีเมื่อคุณมีปัญหาที่เรียบง่ายในระดับสูง (แม้ว่ามันจะซับซ้อนในระดับต่ำ) และต้องการเขียนโค้ดเชิงเส้นที่เรียบง่ายตามลําดับ มันง่ายกว่าที่จะเขียนและทำความเข้าใจได้ง่ายกว่า OO และฟังก์ชั่นหากปัญหาไม่ต้องการการถอดรหัสที่แข็งแกร่ง ตัวอย่าง: รหัสตัวเลข, เศษเล็ก ๆ ส่วนใหญ่, ปัญหาย่อยเล็ก ๆ ส่วนใหญ่เมื่อคุณแยกย่อยโดยใช้ OO หรือการทำงาน

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

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

— dsimcha
แหล่งที่มา

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

— Kevin Peno

7

รหัสไม่เคย "ต้องการ OOP" มันเป็นโปรแกรมเมอร์ตราบเท่าที่พวกเขาสามารถคิดในโหมดที่แตกต่างกันใครจะจินตนาการว่าปัญหานี้หรือปัญหานั้น "ต้องการ" $ PARADIGM หรือแก้ไขได้ดีที่สุด

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

— Ingo
แหล่งที่มา

5

คุณควรแปลงโครงการของคุณเป็น OOP หากมีข้อบ่งชี้ที่ชัดเจนว่าจำเป็นต้องใช้ OOP สถานการณ์ที่เป็นไปได้ที่สิ่งนี้อาจเกิดขึ้น ได้แก่ :

ขยายโครงการ
เพิ่มนักพัฒนาให้กับทีม

และแม้ในสถานการณ์เหล่านี้คุณอาจไม่จำเป็นต้องแปลงโครงการของคุณเป็น OOP

— Timothy Groote
แหล่งที่มา

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

— Sourav

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

— ทิโมธี Groote

3

นี่คือสิ่งที่อยู่ในใจของฉันเมื่อฉันอ่านคำถาม เขาบอกว่าเขาเขียนโค้ด 13 K บรรทัด ฉันหวังว่ามันจะไม่สูญเปล่าโดยใช้เพียงครั้งเดียว และถ้ามันจะต้องถูกนำมาใช้ซ้ำแล้ว oop จะกลายเป็นต้อง ไม่เช่นนั้นมันจะกลายเป็นฝันร้ายสำหรับนักพัฒนาใหม่

— Chani

4

ทั้งคู่สามารถทำได้ดีทั้งคู่อาจไม่ดี แต่การดัดแปลงให้เป็นแบบที่ดูเหมือนจะไม่ใช่ความคิดที่ดี

— jwenting
แหล่งที่มา

2

หากคุณคิดย้อนกลับไปว่าทำไม OO จึงถูกประดิษฐ์ขึ้นมาคุณจะเห็นว่าคุณไม่ต้องการ OOP เลย แต่บางครั้งก็ทำให้ชีวิตของคุณง่ายขึ้นมาก

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

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

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

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

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

— gbjbaanb
แหล่งที่มา

0

รหัสของฉันไม่ต้องการคุณสมบัติใด ๆ ของ OOP [การห่อหุ้มการสืบทอดโดยทั่วไป ... ]!

คุณรู้ได้อย่างไร?

คุณจำเป็นต้องบำรุงรักษาโครงการนี้หรือไม่? มีฟีเจอร์ใหม่ที่วางแผนไว้หรือไม่? จะมีคนอื่นที่จะพัฒนากับคุณ? คุณทำซ้ำตัวเอง? รหัสยากที่จะเข้าใจหรือไม่?

ถ้าคำตอบคือ "ใช่" คุณอาจเริ่มคิดที่จะตั้งโครงกระดูกของ OOP แล้วทำเช่นนี้

— vihus
แหล่งที่มา