17

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

object-oriented code-reuse

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

4

ฉันไม่เคยได้ยินใครพูดว่า ...

— TheLQ

2

@ ฉันไม่เชื่อว่าจริง ๆ แล้วฉันได้ยินใครบอกว่ามัน แต่ฉันได้อ่าน

— George Marian

การใช้งานซ้ำไม่ได้เป็นข้อได้เปรียบเพียงอย่างเดียวของ OOP

— ไม่มีใคร

2

"มีการส่งมอบวัตถุในแง่ของการใช้รหัสซ้ำหรือไม่" -> เฉพาะในกรณีที่คุณเชื่อพนักงานขาย OOP ตั้งแต่วันนั้น (นั่นคือยุค 60 ใช่มั้ยฉันลืม)

— Steven Evers

คำตอบของฉันสำหรับคำถามที่คล้ายกัน: programmers.stackexchange.com/questions/53521/…

— kevin cline

18

ไม่ไม่จำเป็น

ออบเจกต์ให้ความหมายที่ดีกว่าการจัดระเบียบโค้ด / ฟังก์ชันการทำงานและอาจจะใช้งานง่าย

ไลบรารีที่ได้รับการออกแบบมาอย่างดีจะมอบสัญญาการใช้รหัสซ้ำไม่ใช่วัตถุต่อหนึ่งรายการ

— George Marian
แหล่งที่มา

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

— จูลส์

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

— George Marian

7

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

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

— ฮอบส์
แหล่งที่มา

การใช้รหัสซ้ำเป็นสิ่งที่แน่นอนเมื่อคุณสามารถหลีกเลี่ยงการเสียสละคุณภาพของรหัส

— Casebash

1

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

— Andy

5

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

OO เป็นสิ่งที่เป็นนามธรรมสำหรับปัญหามากมาย แต่ต้องระวัง hype '80s-'90s: มันไม่ได้แก้ปัญหาพื้นฐานของการค้าของเราได้อย่างน่าอัศจรรย์มากไปกว่ามันทำให้วาฟเฟิลสำหรับคุณในขณะที่คุณหลับ

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

5

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

คุณเคยได้ยินบ้างไหมว่า OO ไม่สามารถใช้งานซ้ำได้? และอะไรคือเหตุผล บางทีการออกแบบวัตถุของพวกเขาบังคับให้พวกเขาตกอยู่ในสถานการณ์นั้น ...

— วอลเตอร์
แหล่งที่มา

4

บทความต่าง ๆ และจากประสบการณ์ส่วนตัวการทำให้วัตถุนำมาใช้ซ้ำได้นั้นไม่ใช่เรื่องง่ายเลย

— Casebash

3

โปรแกรมเมอร์บางคนจะคัดลอกและวางในภาษาและสไตล์ใด ๆ

โปรแกรมเมอร์ที่ดีจริง ๆ สามารถหลีกเลี่ยงการคัดลอกและวางเกือบทุกภาษา

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

นอกจากนี้ในกรณีที่เราใช้รูปแบบที่ไม่ใช่ oo หรือ oo anti-patters เช่น setters / getters, switch statement, คลาสภายในที่ไม่ระบุชื่อ, ฟังก์ชั่นขนาดใหญ่และอย่างที่ฉันเคยเห็นรหัสนำมาใช้ซ้ำลงและสำเร็จรูปมากขึ้น ...

PS ฉันรู้ว่าผู้คนจะมีปัญหากับย่อหน้าก่อนหน้าดังนั้นฉันจะอธิบายเล็กน้อย

Setters และ getters ทำให้เกิดปัญหา OO เนื่องจากอนุญาตให้คุณทำงานกับสมาชิกของวัตถุ (วัตถุควรจัดการกับสมาชิกของ OWN) สิ่งนี้แจกจ่ายรหัสที่ทำงานในชั้นเรียนของคุณในคลาสอื่น ๆ ที่คุณต้องคัดลอกฟังก์ชันการทำงานรอบ setter / getter . สิ่งนี้ใช้กับคุณสมบัติเช่นกัน - เพียงเพราะคุณสมบัติง่ายขึ้นไม่ได้ทำให้ "ดี" ในทุกสถานการณ์

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

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

— บิลเค
แหล่งที่มา

2

วัตถุไม่มีความสามารถในการส่งรหัสที่นำกลับมาใช้มากกว่าอุปกรณ์บันไดหรืออุปกรณ์ออกกำลังกายอื่น ๆ ที่สามารถลดน้ำหนักได้ นักพัฒนาจะต้องมีแรงจูงใจในการใช้เครื่องมืออย่างเหมาะสม

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

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

2

ใช่

OOP ให้วิธีเพิ่มเติมแก่คุณในการนำรหัสมาใช้ซ้ำ

ไม่

ไม่มีกระสุนเงิน

มันขึ้นอยู่กับ

ในสิ่งที่คุณใส่เข้าไปและสิ่งที่คุณคาดหวังตอบแทน!

— สตีเวนเอ. โลว์
แหล่งที่มา

1

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

ฉันขอยืนยันว่าประโยชน์หลักของ OOP คือการแยกส่วนและปรับเปลี่ยนได้แทนที่จะนำมาใช้ซ้ำ แต่นั่นเป็นคำถามอีกข้อ

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

4

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

— Casebash

2

@casebase +1 อย่างไรก็ตามฉันจะบอกว่าการทำให้วัตถุที่ใช้ซ้ำได้นั้นหมายถึงการอธิบายสถานการณ์ (วัตถุ) มากเกินไป

— George Marian

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

— Fishtoaster

2

@ Fishtoaster: คุณอาจจะบอกว่าการเคลื่อนย้ายรถของคุณเป็นสิ่งที่จำเป็นสำหรับการทำงานและทางลาดเอียงก็เป็นเช่นนั้น มันเป็นความจริงทางเทคนิค แต่ไม่น่าจะสร้างความแตกต่างจากกรณีขอบ: ถ้าคุณต้องการและต้องการใช้ซ้ำคุณจะได้มัน OO หรือไม่; หากคุณไม่ทำเช่นนั้นการมีข้อกำหนดเบื้องต้นจะไม่ทำให้เกิดขึ้นโดยไม่ตั้งใจ

— Shog9

@นาย. C- ฉันไม่แน่ใจว่าฉันทำตามจุดของคุณ ฉันแค่บอกว่าสิ่งต่าง ๆ ที่ OOP สนับสนุน (เป็นโมดูลเป็นต้น) ทำให้ง่ายต่อการทำสิ่งต่าง ๆ เช่นห้องสมุด มีวิธีการมากมายที่จะทำให้สามารถนำโค้ดกลับมาใช้ใหม่ได้โดยแยกข้อกังวลออก ฯลฯ OOP คือหนึ่งการออกแบบวิธีการที่ดีเป็นอีกวิธีหนึ่ง

— Fishtoaster

1

วัตถุที่เปิดใช้งานรหัส re-sue แต่เป็นเช่นนี้ไม่ใช่เทคนิคที่มากที่สุดสำหรับการที่ ฉันคิดว่าการใช้โค้ดซ้ำนั้นได้รับการส่งเสริมผ่านเทคนิคที่เกี่ยวข้องกับวัตถุเช่นการสืบทอดการพหุสัณฐานการบรรทุกเกินพิกัดและเทมเพลต

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

1

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

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

0

หากพวกเขาได้ส่งมอบสัญญาของพวกเขาของการใช้ซ้ำรหัสจนถึง? ใช่ถ้าโปรแกรมที่เขียนด้วย OOP อยู่ในใจใช้รูปแบบการออกแบบอย่างชาญฉลาด มิฉะนั้นส่วนใหญ่ไม่มี แต่เมื่อพิจารณาถึงความนิยมของโปรแกรมที่ไม่สำคัญขนาดใหญ่ที่ระบบ Adobe, Google และเช่นเขียนด้วย C ++ หรือ Java หรือภาษา OOP อื่น ๆ ฉันจะบอกว่า OOP มีทางยาวไปก่อนที่จะสิ้นสุดลง เวลานั้นจะเหมาะกว่าที่จะถามคำถามนี้และสามารถช่วยจัดเตรียมงานดินสำหรับกระบวนทัศน์ใหม่

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

มีการส่งมอบวัตถุในรูปแบบของการใช้รหัสซ้ำหรือไม่

ใช่

ไม่

มันขึ้นอยู่กับ