ความสัมพันธ์ระหว่างการวางแนววัตถุและอัลกอริทึม

เมื่อฉันอ่านหนังสืออัลกอริทึมบางเล่มพวกเขาเต็มไปด้วยกระบวนการที่ชาญฉลาดสำหรับปัญหาบางอย่าง (การเรียงลำดับเส้นทางที่สั้นที่สุด) หรือวิธีการทั่วไปบางอย่าง (อัลกอริทึมแบบเรียกซ้ำแบ่งและพิชิตการเขียนโปรแกรมแบบไดนามิก ... ) ฉันพบร่องรอยการเขียนโปรแกรมเชิงวัตถุน้อย (ทำไมพวกเขาถึงมุ่งเน้นกระบวนการมากขึ้น?)

จากนั้นฉันก็คิดว่า:

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

อันดับแรกให้กำหนดสิ่งที่เราหมายถึงโดย OOP โดย OOP ฉันหมายถึงหลัก:

• การห่อหุ้มและการซ่อนรายละเอียดในชั้นเรียน
• ความแตกต่างของพฤติกรรมผ่านการสืบทอดและวิธีการเสมือน

ตอนนี้เพื่อตอบคำถามของคุณ:

ความสัมพันธ์ระหว่างอัลกอริทึมกับ OOP คืออะไร พวกเขาเป็นสองหัวข้ออิสระ?

ใช่.

มีปัญหาบางอย่างที่สามารถนำเสนอและแก้ไขโดย OOP เท่านั้น?

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

OOP ช่วยอัลกอริทึมได้อย่างไร หรือในทิศทางที่มันสามารถส่งผลกระทบต่อมัน?

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

ความสามารถในการมีพฤติกรรม polymorphic ก็ยอดเยี่ยมเช่นกัน Listถูกกำหนดว่าสามารถเพิ่ม / ลบ / ล้างรายการได้ทุกที่ในคอลเลกชัน แต่มันสามารถนำไปใช้เป็นอาร์เรย์ที่ปรับขนาดได้, double-linked หรือ single-linked, ฯลฯ การมี API เดียวสำหรับการใช้งานที่หลากหลายสามารถช่วยนำมาใช้ซ้ำได้

ทำไมตำราเรียนอัลกอริธึมจึงมุ่งเน้นกระบวนการมากกว่า

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

อัลกอริทึมและOOPเป็นสองคำที่แตกต่างกันซึ่งมีเพียงเหมือนกันว่าพวกเขาเป็นCS -terms ง่ายๆ - อัลกอริทึมเป็นเหมือนสูตรการทำอาหาร : ทำxคุณต้องการส่วนผสมต่อไปนี้และทำขั้นตอน 1,2,3,4,5,6 ... จากนั้นคุณเตรียมอาหารของคุณ

ที่กล่าวว่ามันดูเหมือนว่าธรรมชาติเหมาะสำหรับ algortihms จะอธิบายในขั้นตอนวิธี ขั้นตอนวิธีการอะไรนอกเหนือจาก: ครั้งแรกที่ทำxแล้วทำY

ปัญหาที่พบบ่อยคือ: »จะจัดเรียงชุดของx ได้อย่างไร« วิธีแก้ปัญหาที่เข้าใจง่ายคือbubble-sort:

1. วนซ้ำชุดจากองค์ประกอบสุดท้ายตราบเท่าที่คุณยังไม่ถึงองค์ประกอบแรกและในขณะที่วนซ้ำ
2. เริ่มการทำซ้ำครั้งที่ 2 จากจุดเริ่มต้นไปยังองค์ประกอบปัจจุบันของการทำซ้ำครั้งแรกและ
3. เปรียบเทียบองค์ประกอบปัจจุบันของ (2) กับตัวตายตัวแทน
4. หากมากกว่าให้สลับตำแหน่ง

นั่นคือคำอธิบายขั้นตอน / วาจาของbubblesort-algorithm

นี่คือการใช้โพรซีเดอร์ / pseudocode

bubbleSort(Array A)
  for (n=A.size; n>1; n=n-1){
    for (i=0; i<n-1; i=i+1){
      if (A[i] > A[i+1]){
        A.swap(i, i+1)
    } 
  } 
}

นั่นเป็นเรื่องง่าย

สิ่งนี้ปลดปล่อยOOPอย่างไร คุณสามารถใช้อัลกอริทึมนี้เพื่อจัดการกับคอลเลกชัน (วัตถุเอง) ของวัตถุ :

ตัวอย่างใน Javascript (แม้ว่าจะไม่ทำความสะอาด OO-Lingoแต่ใกล้จะไม่มีหม้อไอน้ำและเข้าใจง่าย)

objects =[{"name":"Peter"}, {"name":"Paul"}, {"name":"Mary"}]

compareObjects=function(x,y){ return x.name>y.name };

sorted = objects.sort(compareObjects)

console.log(sorted)

เรามีก)คอลเลกชันobjects, ข)วิธีการร่วมกันในการเก็บสะสมนี้sortซึ่งมี / abstracts ไปขั้นตอนวิธีการเรียงลำดับและc)วัตถุของเราปีเตอร์ , พอลและแมรี่ ข้อมูลจำเพาะสำหรับการเรียงลำดับที่พบที่นี่

ความสัมพันธ์ระหว่างอัลกอริทึมกับ OOP คืออะไร พวกเขาเป็นสองหัวข้ออิสระ?

จากสิ่งที่กล่าวมาควรมีความชัดเจนคำตอบควรเป็น: ใช่พวกเขาเป็นอิสระ

OOP ช่วยอัลกอริทึมได้อย่างไร หรือในทิศทางที่มันสามารถส่งผลกระทบต่อมัน?

OOP เป็นสไตล์การเขียนโปรแกรมเพียงอย่างเดียว มันไม่สามารถช่วยอะไรได้เลย มิฉะนั้นอัลกอริทึมสามารถนำมาใช้ในภาษา OO เพื่อทำอะไรบางอย่างกับวัตถุ (ดังที่แสดง)

มีปัญหาบางอย่างที่สามารถนำเสนอและแก้ไขโดย OOP เท่านั้น?

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

ทำไมตำราเรียนอัลกอริธึมจึงมุ่งเน้นกระบวนการมากกว่า

ดังที่กล่าวไว้: มันเป็นธรรมชาติมากกว่าเนื่องจากขั้นตอนเป็นตัวละครของอัลกอริทึม

คุณมีปัญหา.

โมเดลโดเมนธุรกิจอธิบายถึงปัญหาของคุณและแนวคิดจากโดเมนปัญหาที่คุณกำลังดำเนินการ

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

กระบวนทัศน์การเขียนโปรแกรมไม่ว่าจะเป็น OOP, Functional, Logical, Procedural หรือแม้แต่ Non-Structured อธิบายว่าคุณจะจัดโครงสร้างโซลูชันของคุณอย่างไรซึ่งจะใช้รูปแบบใดซึ่งคุณจะใช้แนวคิด "วิศวกรรมซอฟต์แวร์" และ " แนวคิดการเขียนโปรแกรมภาษาทฤษฎี "คุณจะจ้าง

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

อัลกอริทึม = บอกเล่าเรื่องราว " วิธี " (เช่นวิธีการจัดการข้อมูลอินพุตโดยใช้โครงสร้างข้อมูลในเวลาที่จะสร้างผลลัพธ์ที่ต้องการ)

OOP = a " ระเบียบวิธี " อำนวยความสะดวกโดย OO-languages ​​ในการเขียนโปรแกรม (= อัลกอริทึม + โครงสร้างข้อมูล) ที่ให้ความปลอดภัยและความจำแก่คุณ

OOP เป็นเพียงกระบวนทัศน์ของการใช้อัลกอริทึม

การเปรียบเทียบที่ดี : ภาพยนตร์

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

แก้ไข: คุณสามารถลองใช้ MOOC คุณภาพดี: https://www.coursera.org/course/algs4partIซึ่งแทรกหัวข้อที่กล่าวถึง (โดยเฉพาะอย่างยิ่งวิธีการของ OOP) และให้สาระสำคัญของสิ่งที่คุณถามที่นี่

Alexander Stepanov เป็นผู้สร้างดั้งเดิมของไลบรารีแม่แบบ C ++ มาตรฐาน (STL) ซึ่งเป็นไลบรารีอัลกอริทึมพื้นฐานสำหรับ C ++ C ++ เป็นภาษาแบบหลายกระบวนทัศน์ที่มีคุณสมบัติ "Object Oriented" แต่ Alexander Stepanov มีสิ่งนี้เพื่อพูดเกี่ยวกับ Object Orientation:

http://www.stlport.org/resources/StepanovUSA.html

STL ไม่ได้มุ่งเน้นวัตถุ ฉันคิดว่าการวางวัตถุนั้นเป็นเรื่องหลอกลวงมากพอ ๆ กับปัญญาประดิษฐ์ ฉันยังไม่เห็นโค้ดที่น่าสนใจที่มาจากคน OO เหล่านี้

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

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

Stepanov แสดงห้องสมุดขั้นตอนวิธีการของเขาไม่ได้อยู่กับวัตถุ แต่มีทั่วไป Iterators

อัลกอริทึมอธิบายสิ่งที่คอมพิวเตอร์ควรทำ โครงสร้างอธิบายวิธีวางอัลกอริทึม [ในซอร์สโค้ด] OOP เป็นรูปแบบของการเขียนโปรแกรมซึ่งใช้ประโยชน์จากโครงสร้าง "เชิงวัตถุ" บางอย่าง

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

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

ตัวอย่างของสิ่งที่ไม่ชัดเจนให้ใช้ Dynamic Programming ในหนังสืออัลกอริทึมคุณจะอธิบายวิธีการใช้ชุดข้อมูลที่เป็นเนื้อเดียวกันในอาร์เรย์และใช้การเขียนโปรแกรมแบบไดนามิกเพื่อให้ได้ผลลัพธ์ ในหนังสือ OOP คุณอาจเจอโครงสร้างเช่น Visitor ซึ่งเป็นวิธีที่จะทำอัลกอริทึมตามอำเภอใจในชุดของวัตถุที่ต่างกัน ตัวอย่างหนังสือ DP นั้นอาจถือว่าเป็นผู้เข้าชมที่ใช้งานง่ายบนวัตถุตามลำดับจากล่างขึ้นบน รูปแบบของผู้เข้าชมอาจถูกมองว่าเป็นโครงกระดูกของปัญหา DP แต่ขาดเนื้อและมันฝรั่ง ในความเป็นจริงคุณจะพบว่าคุณต้องการทั้งสองอย่างด้วยกัน: คุณใช้รูปแบบของผู้เข้าชมเพื่อจัดการกับความหลากหลายของชุดข้อมูลของคุณ (DP ไม่ดีตรงนั้น) และคุณใช้ DP ภายในโครงสร้างของผู้เข้าชมเพื่อจัดระเบียบอัลกอริทึม doesn'

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

มีปัญหาบางอย่างที่สามารถนำเสนอและแก้ไขโดย OOP เท่านั้น?

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

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

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

ฉันไม่เห็น OOP ที่หายไปในอนาคตอันใกล้เนื่องจากวิธีคิดของนักออกแบบอัลกอริทึม จนถึงปัจจุบันรูปแบบปกติคือมีคนออกแบบอัลกอริทึมที่ไม่ใช้ประโยชน์จาก OOP ชุมชน OOP ตระหนักถึงอัลกอริทึมที่ไม่เหมาะสมกับโครงสร้าง OOP และไม่จำเป็นต้องทำดังนั้นพวกเขาจึงห่อหุ้มอัลกอริทึมทั้งหมดในโครงสร้าง OOP และเริ่มใช้มัน boost::shared_ptrพิจารณา อัลกอรึทึมการนับอ้างอิงที่วางอยู่ข้างในshared_ptrนั้นไม่เป็นมิตรกับ OOP อย่างไรก็ตามรูปแบบดังกล่าวไม่ได้รับความนิยมจนกว่าจะshared_ptrมีการสร้างตัวห่อหุ้ม OOP ที่อยู่รอบ ๆ ซึ่งเปิดเผยความสามารถของอัลกอริทึมในรูปแบบที่มีโครงสร้างของ OOP ตอนนี้มันได้รับความนิยมมากจนทำให้มันกลายเป็นข้อมูลจำเพาะล่าสุดของ C ++, C ++ 11

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

นอกเหนือจากคำตอบที่ดีฉันจะพูดถึงความคิดร่วมกันเพิ่มเติมระหว่าง OOP และอัลกอริทึม

ทั้ง OOP และอัลกอริทึมเน้นการใช้เงื่อนไขและ postconditionsเพื่อให้แน่ใจว่าถูกต้องของรหัส

โดยทั่วไปนี่คือมาตรฐานการปฏิบัติในทุกด้านของวิทยาการคอมพิวเตอร์; อย่างไรก็ตามหลักการชี้นำนี้ส่งผลให้เกิดเส้นทางวิวัฒนาการใน OOP ที่ทำให้เกิดประโยชน์ร่วมกันในการใช้อัลกอริทึมในสภาพแวดล้อม OOP

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

อัลกอริทึมคือการดำเนินการตามขั้นตอนที่ใช้ในการคำนวณซึ่งจะใช้เงื่อนไขและสร้าง postcondition

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

ด้วยการใช้อัลกอริทึมใน OOP เราสามารถทำให้ขั้นตอนเล็ก ๆ เหล่านี้สามารถใช้แทนกันได้

สุดท้ายโปรดจำไว้ว่า FP และ OOP ไม่ได้เกิดร่วมกัน สิ่งที่อธิบายข้างต้นสามารถใช้ได้กับ FP เช่นกัน

What is the relation between algorithms and OOP? Are they two independent topics?

อัลกอริทึมเกี่ยวกับวิธีการแก้ปัญหา (วิธีการสร้างผลลัพธ์จากอินพุตที่กำหนด), OOP เป็นวิธีการกำหนดหรือแสดงวิธีแก้ปัญหาของเรา (ขั้นตอนของอัลกอริทึม)

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

bubbleSort(Array A)
  for (n=A.size; n>1; n=n-1){
    for (i=0; i<n-1; i=i+1){
      if (A[i] > A[i+1]){
        A.swap(i, i+1)
    } 
  } 
}

เพื่อซ่อนรายละเอียดswapและเกี่ยวข้องกับAเราใช้ไวยากรณ์และคุณลักษณะของ OOP แล้ว OO จะทำให้อัลกอริทึมใกล้เคียงกับภาษาธรรมชาติและความเข้าใจของเรามากขึ้น

Are there some problems which can only be presented and solved by OOP?

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

How OOP can help algorithms? Or in which direction it can affect it?

มันอาจช่วยในการระบุหรือกำหนดอัลกอริทึมได้ง่ายขึ้นหรือเข้าใจง่ายขึ้น สามารถซ่อนรายละเอียดและให้ภาพรวมของการแก้ปัญหา

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

ในเรื่องนี้ OOP อำนวยความสะดวกในการติดตั้งทดสอบและปรับแต่งอัลกอริทึมของเราบนคอมพิวเตอร์และเขียนลงในคอมพิวเตอร์ในภาษาใกล้เคียงกับภาษาธรรมชาติของเรา