Rich Hickey หมายความว่าอย่างไรเมื่อเขาพูดว่า“ ความพิเศษเฉพาะทั้งหมดของอินเทอร์เฟซ / คลาส / ประเภท] ฆ่าการใช้ซ้ำของคุณ!”

ในคำปราศรัยการประชุม goto ในการประชุมระดมความคิดที่กระตุ้นความคิดของ " มูลค่าของคุณค่า " ในเวลา 29 นาทีที่เขาพูดถึงค่าใช้จ่ายในภาษาจาวาและทำให้คำสั่งเช่น เขาหมายถึงอะไร มันเป็นเรื่องจริงเหรอ?

ในการค้นหาคำตอบของฉันฉันเจอ:

• หลักการของความรู้น้อยที่สุด AKA กฎหมายของ Demeterซึ่งสนับสนุนการเชื่อมต่อ API แบบสุญญากาศ Wikipedia ยังแสดงข้อเสียบางประการ

• วิกฤตเสื้อผ้าของ Kevlin Henney ซึ่งระบุว่าการใช้ไม่ใช่การใช้ซ้ำเป็นเป้าหมายที่เหมาะสม

• การพูดคุยเรื่อง " Stop Writing Classes " ของ Jack Diederich ซึ่งขัดแย้งกับเรื่องวิศวกรรมโดยทั่วไป

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

ฉันกำลังมองหาหนึ่งตัวอย่างที่ดีของอินเทอร์เฟซที่ดีที่ป้องกันไม่ให้ใช้รหัสบางอย่างถูกต้อง มีอยู่จริงเหรอ? ฉันไม่สามารถจินตนาการได้

ยังไม่ได้ดูงานนำเสนอ Rich Hickey เต็มรูปแบบ แต่ถ้าฉันเข้าใจเขาอย่างถูกต้องและตัดสินจากสิ่งที่เขาพูดเกี่ยวกับเครื่องหมาย 29 นาทีดูเหมือนว่าเขาจะเถียงกันเกี่ยวกับการฆ่าซ้ำประเภท เขาใช้คำว่า "interface" อย่างหลวม ๆ เป็นคำพ้องสำหรับ "named type" ซึ่งเหมาะสมแล้ว

หากคุณมี{ "name":"John" }ประเภทเอนทิตีสองประเภทPersonและ{ "name": "Rover" }ประเภทDogใน Java-land พวกเขาอาจไม่สามารถทำงานร่วมกันได้เว้นแต่พวกเขาจะแบ่งปันอินเทอร์เฟซหรือบรรพบุรุษร่วมกัน (เช่นMammalซึ่งหมายถึงการเขียนรหัสเพิ่มเติม) ดังนั้นการเชื่อมต่อ / ประเภทที่นี่จะ "ฆ่านำมาใช้ใหม่ของคุณ": แม้ว่าPersonและDogมีลักษณะเดียวกันหนึ่งไม่สามารถใช้สลับกันกับคนอื่น ๆ ถ้าคุณเขียนโค้ดเพิ่มเติมเพื่อสนับสนุนว่า หมายเหตุ Hickey ยังตลกเกี่ยวกับโปรเจ็กต์ใน Java ที่ต้องการคลาสจำนวนมาก ("ใครที่นี่เขียนแอปพลิเคชัน Java โดยใช้เพียง 20 คลาส?") ซึ่งดูเหมือนว่าเป็นผลมาจากข้างต้น

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

สรุปแล้วทั้งหมดนี้ดูเหมือนจะเป็นอะไรบางอย่างเกี่ยวกับความเสมอภาคของโครงสร้างเทียบกับความชัดเจนของประเภท / ส่วนต่อประสานที่ชัดเจน ถ้าฉันไม่ได้รับอะไรบางอย่างจากส่วนของวิดีโอที่ฉันยังไม่ได้ดู :)

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

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

เป็นเหมือนกรอบ GUI ที่มีIWindowส่วนต่อประสานกับกล่องโต้ตอบจากนั้นคุณสามารถเพิ่มIButtonส่วนต่อประสานสำหรับตัวควบคุมได้ ยกเว้นพวกเขาไม่เคยให้คุณดีคลาสที่ใช้Button IButtonดังนั้นคุณเหลือที่จะสร้างของคุณเอง

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

นักพัฒนา Java เริ่มทำสิ่งนี้ที่ชั้น API interfacesของพวกเขาสัมผัสเท่านั้น คุณสามารถใช้อินเทอร์เฟซเหล่านั้นได้ แต่คุณไม่สามารถใช้คลาสซ้ำจากนักพัฒนาที่ใช้อินเทอร์เฟซเหล่านั้นได้ มันเหมือนกับการพัฒนา API แบบปิดบังและกริช

ฉันคิดว่าสไลด์ 13 ในการนำเสนอของเขา ( ค่านิยม ) ช่วยให้เข้าใจสิ่งนี้:

ค่า

• ไม่ต้องการวิธีการ
  • ฉันสามารถส่งค่าโดยไม่มีรหัส
    และคุณก็สบาย

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

    MyValue = Double(YourValue)

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

ทีนี้มันจะเป็นอย่างไรในภาษาที่มีวัตถุและส่วนต่อประสาน?

    Doublable MyValue = YourValue.Double()

โอ้เดี๋ยวก่อน! สิ่งที่ถ้าYourValueไม่ใช้Doublable? ไม่ว่ามันจะไม่เป็นสองเท่า แต่มันอาจเป็นไปได้อย่างสมบูรณ์แบบ แต่ ... จะเกิดอะไรขึ้นถ้าไม่มีวิธี Double ? (เกิดอะไรขึ้นถ้ามีวิธีที่เรียกว่าพูดTwiceAsMuch?)

เอ่อโอ้เรามีปัญหา YourValue.Doubleจะไม่ทำงานมันไม่สามารถใช้ซ้ำได้อีก ตามที่ฉันได้อ่านสไลด์ด้านบนนี่เป็นสิ่งที่ Hickey หมายถึงเมื่อเขาพูดว่า

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

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

หมายเหตุด้าน: ความคิดในการส่งค่าที่ไม่ใช้โค้ดช่วยเตือนฉันถึงรูปแบบ Flyweightใน OOP

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

การใช้งานแบบ Flyweight ที่ฉันเคยเห็นมักใช้วิธีการเดียวกันในการลอกรหัส (วิธีการ, อินเทอร์เฟซ) จากวัตถุและส่งผ่านสิ่งต่าง ๆ รอบ ๆ ด้วยค่าที่ไม่ต้องใช้โค้ดคาดหวังว่าการรับรหัสมีความจำเป็น

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

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

ตอนนี้เป็นเวทีที่ Rich Hickey พอใจที่จะโยนลูกน้อยออกไปพร้อมกับอาบน้ำแล้วบอกว่าพวกเราทุกคนควรจะมีชีวิตอยู่ในดินแดนแห่งค่านิยม ฉันคิดว่าในมือที่ OOP สามารถและส่งเสริมการใช้ซ้ำ (และการค้นพบที่สำคัญซึ่งฉันพบว่าขาดในการเขียนโปรแกรมการทำงาน) เมื่อใช้อย่างรอบคอบ หากคุณกำลังมองหาหลักการ OOP ที่จับความตึงเครียดนี้ได้ดีที่สุดฉันคิดว่ามันอาจเป็นhttp://c2.com/cgi/wiki?TellDontAsk (ซึ่งแน่นอนว่าเป็นลูกพี่ลูกน้องของ Demeter)