กระบวนทัศน์ที่ไม่ใช่ OOP สนับสนุนแนวคิดเช่นการห่อหุ้มหรือไม่?

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

มันทำให้ฉันคิดว่าสิ่งที่เกี่ยวกับการห่อหุ้มและหลักการ OOP อื่น ๆ ? พวกเขาผิดหรือเปล่า?

มีการใช้ OOP ผิดหรือไม่ ตัวอย่างเช่น Alan Kay ถูกกล่าวถึงในการกล่าวคำปราศรัย OOPSLA'97: "ฉันคิดค้นคำว่า object-oriented และฉันสามารถบอกคุณได้ว่าฉันไม่มี C ++ ในใจ"

Joe Armstrong - "วัตถุผูกฟังก์ชั่นและโครงสร้างข้อมูลร่วมกันในหน่วยแบ่งแยกฉันคิดว่านี่เป็นข้อผิดพลาดพื้นฐานเนื่องจากฟังก์ชั่นและโครงสร้างข้อมูลอยู่ในโลกที่แตกต่างกันโดยสิ้นเชิง"

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

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

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

มีการใช้ OOP ผิดหรือไม่

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

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

อย่างไรก็ตามเมื่อไม่นานมานี้โลกของซอฟต์แวร์ดูเหมือนจะเอียงไปทางกระบวนทัศน์อื่น ๆ เช่นการเขียนโปรแกรมการทำงาน

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

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

มันทำให้ฉันคิดว่าสิ่งที่เกี่ยวกับการห่อหุ้มและหลักการ OOP อื่น ๆ ? พวกเขาผิดหรือเปล่า?

Encapsulation มีรสชาติที่แตกต่างมากมาย ฟังก์ชั่นการเขียนโปรแกรมภาษาและสร้างภาษาให้รูปแบบบางอย่างของการห่อหุ้มวัตถุอื่น ๆ ที่มุ่งเน้น หากคุณกำลังมองหาตัวอย่างของการห่อหุ้มด้วยวิธีการทำงานเริ่มต้นด้วยการปิด

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

มีการใช้ OOP ผิดหรือไม่ ตัวอย่างเช่น Alan Kay ถูกกล่าวถึงในการกล่าวคำปราศรัย OOPSLA'97: "ฉันคิดค้นคำว่า object-oriented และฉันสามารถบอกคุณได้ว่าฉันไม่มี C ++ ในใจ"

OOP นั้นมักถูกใช้อย่างผิด ๆ กับหลาย ๆ คน แต่ฉันแน่ใจว่าเป็นเช่นเดียวกันสำหรับ FP และฉันจะประหลาดใจถ้า John Mc Carthy (ผู้ออกแบบ Lisp) มีบางอย่างที่เหมือนกับจาวาสคริปต์ในใจเมื่อเขากำลังคิดเกี่ยวกับการเขียนโปรแกรมที่ใช้งานได้ (ความเมตตาต่อฉันไม่ได้ทำให้ฉันมากเกินไปสำหรับการเปรียบเทียบนั้น ;-)

Joe Armstrong - "วัตถุผูกฟังก์ชั่นและโครงสร้างข้อมูลร่วมกันในหน่วยแบ่งแยกฉันคิดว่านี่เป็นข้อผิดพลาดพื้นฐานเนื่องจากฟังก์ชั่นและโครงสร้างข้อมูลอยู่ในโลกที่แตกต่างกันโดยสิ้นเชิง"

ฉันเดาว่านักประดิษฐ์ของ Erlang มีข้อโต้แย้งที่ดีบ้าง แต่เขาก็มีมุมมองของเขาเองดังนั้นให้เขาแสดงความคิดเห็นและสร้างของคุณเอง มีผู้เชี่ยวชาญอื่น ๆ อีกมากมายที่มีความคิดแตกต่างจากเรื่องนี้

แน่นอน:

struct Foo
{
    string bar;
    int bux;
}

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

โปรแกรมเมอร์จาวาสคริปต์ห่อหุ้มสถานะและพฤติกรรมในฟังก์ชั่นและการปิดเป็นประจำไม่ใช่คลาส

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

คำจำกัดความแรกที่คุณจะพบคือ

Encapsulation เป็นแนวคิดที่เชื่อมโยงข้อมูลและฟังก์ชันเข้าด้วยกันที่จัดการข้อมูล ...

หากนี่เป็นคำจำกัดความของคุณภาษาส่วนใหญ่จะมีวิธีจัดกลุ่มข้อมูลและฟังก์ชั่นที่ทำงานกับข้อมูลนั้นลงในคลาสโมดูลห้องสมุดเนมสเปซ ฯลฯ

แต่ฉันจะยืนยันว่าไม่ใช่จุดประสงค์หลักของการห่อหุ้มเนื่องจากคำจำกัดความดังกล่าวยังคงดำเนินต่อไป:

... และนั่นทำให้ทั้งคู่ปลอดภัยจากการรบกวนจากภายนอกและการใช้ในทางที่ผิด

Wikipedia เห็นด้วยกับสิ่งต่อไปนี้:

กลไกภาษาสำหรับ จำกัด การเข้าถึงโดยตรงไปยังองค์ประกอบบางส่วนของวัตถุ

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

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

แต่สิ่งที่เกี่ยวกับภาษาที่ไม่เปลี่ยนรูป? ไม่มีปัญหาในการกลายพันธุ์ของตัวแปร นี่คือที่มาของปัญหาที่สอง: ฟังก์ชันการเชื่อมโยงและข้อมูลอนุญาตให้เก็บข้อมูลนั้นในสถานะที่ถูกต้อง Emailลองนึกภาพคุณมีโครงสร้างไม่เปลี่ยนรูปสำหรับ โครงสร้างนี้มีstringฟิลด์เดียว เรามีข้อกำหนดว่าถ้าคุณมีค่าประเภทEmailแล้วฟิลด์นั้นมีที่อยู่ที่ถูกต้อง ในการห่อหุ้มของ OOP สิ่งนี้ทำได้ง่ายโดยการประกาศฟิลด์privateนั้นโดยให้Getวิธีการและมีเท่านั้นconstructor methodที่ประสบความสำเร็จก็ต่อเมื่อผ่านในสตริงเป็นที่อยู่ที่ถูกต้อง สิ่งที่คล้ายกันกับการปิด ตอนนี้สำหรับภาษาที่ไม่เปลี่ยนรูปแบบก็จะต้องมีวิธีบอกว่าโครงสร้างสามารถเริ่มต้นได้ผ่านฟังก์ชั่นเฉพาะและฟังก์ชั่นดังกล่าวสามารถล้มเหลว และฉันไม่ได้ตระหนักถึงภาษาใด ๆ ที่จะตรงกับเกณฑ์นั้น (บางทีใครบางคนในความคิดเห็นสามารถสอนฉัน)

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