OOP ง่ายขึ้นหรือยากขึ้นหรือไม่ [ปิด]

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

Stock stock = new Stock();
stock.addItem(item);
stock.removeItem(item);

นั่นง่ายกว่าที่จะเข้าใจด้วยชื่อที่อธิบายตนเอง

แต่ตอนนี้ OOP ที่มีรูปแบบเช่น Data Transfer Objects, Value Objects, Repository, Dependency Injection เป็นต้นนั้นมีความซับซ้อนมากขึ้น เพื่อให้บรรลุถึงข้างต้นคุณอาจต้องสร้างหลายคลาส (เช่น abstract, factory, DAO เป็นต้น) และใช้อินเทอร์เฟซหลายตัว

หมายเหตุ: ฉันไม่ขัดกับแนวปฏิบัติที่ดีที่สุดที่ทำให้การทำงานร่วมกันการทดสอบและการรวมระบบง่ายขึ้น

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

เหตุใดคุณจึงรับรู้ว่า OOP ในวันนี้มีความซับซ้อนมากกว่าเมื่อคุณเริ่มใช้งาน

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

อีกเหตุผลหนึ่งอาจเป็นได้ว่าในขณะที่กระบวนทัศน์ความซับซ้อนไม่เปลี่ยนแปลงขนาดและความซับซ้อนของโครงการซอฟต์แวร์โดยเฉลี่ยอาจมี ด้วยพลังการประมวลผลที่มีอยู่ในโทรศัพท์มือถือของลูกค้าระดับที่จะเป็นความฝันที่เปียกชื้นของนักพัฒนาบนเซิร์ฟเวอร์น้อยกว่าสองทศวรรษที่ผ่านมาประชาชนทั่วไปคาดหวัง GUI เคลื่อนไหวที่ลื่นไหลสำหรับแอพที่ถูกที่สุดและพีซีระดับเริ่มต้น กว่าซูเปอร์คอมพิวเตอร์ในปี 1980 มันเป็นเรื่องธรรมดาที่บาร์ได้รับการเลี้ยงดูมาตั้งแต่สมัยแรก ๆ ของ Smalltalk และ C ++

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

ด้วยเหตุนี้ภาษา OOP ที่ทันสมัยส่วนใหญ่จึงรวมคุณสมบัติจากกระบวนทัศน์อื่น ๆ ซึ่งทำให้พวกเขาแสดงออกและมีประสิทธิภาพมากขึ้น แต่ก็มีความซับซ้อนมากขึ้น C # เป็นตัวอย่างที่ดีสำหรับเรื่องนี้: มันมีราก OOP ที่เห็นได้ชัด แต่คุณสมบัติเช่นผู้ได้รับมอบหมายเหตุการณ์การอนุมานประเภทชนิดข้อมูลตัวแปรคุณลักษณะฟังก์ชั่นที่ไม่ระบุชื่อนิพจน์แลมบ์ดา generics ฯลฯ มาจากกระบวนทัศน์อื่น ๆ .

ไม่มันกลายเป็นเรื่องของวิศวกรรมมากไป และคุณถูกต้องในการแชท SO C ++ เรามักพูดตลกเกี่ยวกับ AbstractSingletonFactoryProxyBeanBridgeAdapterManagers ที่เราเห็นในโค้ด Java

แต่รหัสที่ดีจะไม่แสดงคุณสมบัตินี้ ในรหัสที่ดีคุณยังสามารถพูดได้

std::stack<int> s;
s.push(5);
s.pop();

ฉันจะบอกว่าปัญหาเกี่ยวกับ "ความซับซ้อน" ที่คุณพูดถึงไม่มีส่วนเกี่ยวข้องกับ OOP มันมีมากขึ้นเกี่ยวกับการแยกข้อกังวล

หลายปีที่ผ่านมาฉันทำงานในระบบที่ระดับโดเมนมีความรับผิดชอบในการโหลดตัวเองจากฐานข้อมูลเช่น

var userId = Request.QueryString["UserID"].ToInt();
var user = new User(userId);
user.Name = ...;
...
user.Save();

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

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

ดังนั้นถ้าเรากลับไปที่ตัวอย่างที่คุณเขียนคุณจะทำอะไรกับหุ้นหลังจากที่คุณสร้างมันขึ้นมา? บันทึกไว้ในฐานข้อมูล

Stock stock = new Stock();
stock.addItem(item);
stock.removeItem(item);
this.StockRepository.Add(stock);

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

หากคุณไม่คุ้นเคยกับรูปแบบเหล่านี้คุณอาจต้องเรียนรู้รูปแบบการเขียนโปรแกรมใหม่ แต่รูปแบบการเขียนโปรแกรมนั้นไม่ยากไปกว่าการเขียนโปรแกรม OOP แบบเก่า

ทั้ง ปัญหาของเราไม่ได้เปลี่ยนไปจริงๆ แถบสำหรับโค้ดที่ยอมรับได้ถูกยกขึ้น

เพื่อให้บรรลุถึงข้างต้นคุณอาจต้องสร้างหลายคลาส (เช่น abstract, factory, DAO เป็นต้น) และใช้อินเทอร์เฟซหลายตัว

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

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

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

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

รูปแบบที่คุณอ้างถึงเป็นเพียงแค่นั้น พวกเขาควรจะทำให้ชีวิตของคุณง่ายขึ้น แต่มันก็ขึ้นอยู่กับคุณที่จะยอมรับและปรับมัน ความจริงที่ว่าต้องมีงานมากขึ้นเป็นเพียงเพราะคุณได้รับผลประโยชน์มากขึ้น มันก็เหมือนกับการจ่ายเงินมากขึ้นสำหรับ Ferrari หากคุณต้องการความพิเศษที่คุณจ่ายไป ดังนั้นหากคุณตัดสินใจที่จะสร้างโซลูชัน N-Tier ที่ปรับขนาดได้ที่สามารถทำงานบนเซิร์ฟเวอร์หลายเครื่องและฐานข้อมูลส่วนหลังที่แตกต่างกันจะมีค่าใช้จ่าย หากแอปพลิเคชันของคุณไม่ต้องการความซับซ้อนนี้ให้ข้ามส่วนพิเศษและถอยกลับไปยังโซลูชันที่ง่ายที่สุดที่ครอบคลุมความต้องการของคุณ (KISS & YAGNI)

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

คำตอบสั้น ๆ : ใช่เพราะคุณจัดการกับปัญหาที่ยากขึ้น

คำตอบยาว (เอนเอียงอย่างยิ่ง) : สำหรับฉันรูปแบบการออกแบบมักจะระบุว่ากระบวนทัศน์บางอย่างมีปัญหาในพื้นที่ที่กำหนด รูปแบบ OOP จัดการกับปัญหาของ OOP (ในระดับที่ต่ำกว่ารูปแบบ Java จัดการกับปัญหาของ Java), รูปแบบ FP จัดการกับปัญหาของ FP ฯลฯ

ระหว่างการเขียนโปรแกรมคุณอาจมีลำดับความสำคัญแตกต่างกัน คุณอาจต้องการโปรแกรมที่ถูกต้องคุณอาจต้องการเวลาที่สั้นลงสู่ตลาดโปรแกรมที่เร็วที่สุดการบำรุงรักษาระยะยาวหรือการบำรุงรักษาแบบทันทีด้วยการจ้างงานใหม่ คุณจะมีความแตกต่างกันอย่างมาก - หากคุณเป็นผู้ควบคุมการเขียนโปรแกรมของโรงไฟฟ้าที่คุณต้องการทำในครั้งแรกและไม่ใช่การแก้ไขข้อผิดพลาดทุกครั้งในขณะนี้และจากนั้น ("การล่มสลายเกิดขึ้นทุกครั้งที่กดCtrl+Alt+Del?") ถ้าคุณอยู่ใน HPC ลอจิกสามารถทำได้ง่าย แต่คุณต้องการที่จะดำเนินการให้เร็วที่สุดเท่าที่จะเป็นไปได้เป็นต้นนอกจากนี้กระบวนทัศน์บางอย่างยังเหมาะกับปัญหาบางอย่างที่ดีกว่า (พูด AI และการเขียนโปรแกรมเชิงตรรกะข้อมูลและฐานข้อมูลเชิงสัมพันธ์)

OOP คือบางส่วนขยาย 'ดีเกินไป' ในกรณีที่เรียบง่ายและเป็นเรื่อง "การสร้างแบบจำลองการแสดงสดจริง" ยกตัวอย่างเช่นในหนังสือเล่มแรกเกี่ยวกับ OOP ผมอ่านมีชั้นเรียนPerson, EmployeeและManagerมีis-aความสัมพันธ์ จนถึงตอนนี้ดีมาก แต่ถ้าพนักงานได้รับการเลื่อนตำแหน่งเป็นผู้จัดการ?

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

PS ใช่ - คำตอบนั้นเอนเอียงกับ OOP และฉันยอมรับว่าบางคนขยายมันว่า 'อยู่ในปฏิกิริยา' กับ OOP OOP มีประโยชน์ แต่ก็ไม่ใช่ทางออกเดียวที่ดีที่สุดในความคิดของฉัน

PPS ใช่ - ใช้รูปแบบการออกแบบ - ทำให้การเขียนโปรแกรม OOP ง่ายขึ้นในที่สุด

PPPS ฉันใช้ OOP เป็นคำพ้องความหมายของโปรแกรม OOP ที่จำเป็น

ฉันคิดว่ามันเป็นเรื่องของเอกสารและตัวอย่างที่เป็นจริงมากขึ้น

หนังสือ OOP เริ่มแรก (โดยเฉพาะหนังสือ Java ช่วงต้น) นำเสนอมุมมองที่เรียบง่ายไร้เหตุผลของการเขียนโปรแกรมประยุกต์ ตัวอย่าง "หักบัญชีธนาคารที่มีโปรแกรม Java 10 บรรทัด" มักจะน่ารำคาญเป็นพิเศษเพราะฉันได้เห็นตัวอย่างชีวิตจริงของงานง่าย ๆ นี้ที่ทำงานได้ถึง 6,000 บรรทัดของโค้ดภาษาโคบอล เป็นไปไม่ได้!)

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

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