คำถามติดแท็ก interfaces

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

243 design-patterns  coding-standards  interfaces 

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

166 interfaces  debugging  coupling  errors 

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

158 interfaces 

ฉันมักจะอ่านองค์ประกอบที่เป็นที่ต้องการมากกว่าการสืบทอด บล็อกโพสต์เมื่อวันที่แตกต่างจากชนิดตัวอย่างเช่นสนับสนุนการใช้องค์ประกอบมรดก แต่ฉันไม่สามารถดูวิธีการแตกต่างคือความสำเร็จ แต่ฉันมีความรู้สึกว่าเมื่อผู้คนพูดว่าชอบการแต่งเพลงพวกเขาหมายถึงการผสมผสานระหว่างการผสมผสานกับการใช้อินเตอร์เฟส คุณจะได้รับความหลากหลายโดยไม่มีการสืบทอดได้อย่างไร นี่คือตัวอย่างที่เป็นรูปธรรมที่ฉันใช้การสืบทอด สิ่งนี้จะถูกเปลี่ยนเป็นใช้การเรียงลำดับอย่างไร Class Shape { string name; public: void getName(); virtual void draw()=0; } Class Circle: public Shape { void draw(/*draw circle*/); }

109 interfaces  inheritance  composition 

ใน Java 8 อินเทอร์เฟซสามารถมีวิธีการใช้งานวิธีการแบบคงที่และวิธีการที่เรียกว่า "เริ่มต้น" (ซึ่งชั้นเรียนการดำเนินการไม่จำเป็นต้องแทนที่) ในมุมมองของฉัน (อาจไร้เดียงสา) ไม่จำเป็นต้องละเมิดส่วนต่อประสานเช่นนี้ การเชื่อมต่อเป็นสัญญาที่คุณต้องปฏิบัติตามเสมอและนี่คือแนวคิดที่เรียบง่ายและบริสุทธิ์ ตอนนี้มันเป็นการผสมผสานของหลายสิ่งหลายอย่าง ในความเห็นของฉัน: วิธีการคงที่ไม่ได้เป็นของอินเตอร์เฟซ พวกมันอยู่ในคลาสยูทิลิตี้ ไม่ควรอนุญาตวิธีการ "เริ่มต้น" ในอินเทอร์เฟซเลย คุณสามารถใช้คลาสนามธรรมสำหรับวัตถุประสงค์นี้ได้เสมอ ในระยะสั้น: ก่อน Java 8: คุณสามารถใช้คลาสนามธรรมและคลาสปกติเพื่อจัดเตรียมเมธอด static และ default บทบาทของอินเตอร์เฟสชัดเจน วิธีการทั้งหมดในอินเทอร์เฟซควรจะ overriden โดยการใช้คลาส คุณไม่สามารถเพิ่มวิธีการใหม่ในอินเทอร์เฟซโดยไม่ต้องปรับเปลี่ยนการใช้งานทั้งหมด แต่นี่เป็นสิ่งที่ดีจริงๆ หลังจาก Java 8: ไม่มีความแตกต่างระหว่างอินเทอร์เฟซและคลาสนามธรรม (นอกเหนือจากมรดกหลายรายการ) ในความเป็นจริงคุณสามารถเลียนแบบคลาสปกติด้วยอินเทอร์เฟซ เมื่อตั้งโปรแกรมการใช้งานโปรแกรมเมอร์อาจลืมแทนที่วิธีการเริ่มต้น มีข้อผิดพลาดในการคอมไพล์ถ้าคลาสพยายามใช้อินเตอร์เฟสสองอินเตอร์เฟสขึ้นไปที่มีเมธอดดีฟอลต์ที่มีลายเซ็นเดียวกัน โดยการเพิ่มวิธีการเริ่มต้นให้กับส่วนติดต่อทุกชั้นใช้งานโดยอัตโนมัติสืบทอดพฤติกรรมนี้ คลาสเหล่านี้บางคลาสอาจไม่ได้รับการออกแบบโดยคำนึงถึงฟังก์ชันการทำงานใหม่และอาจทำให้เกิดปัญหาได้ ตัวอย่างเช่นถ้ามีคนเพิ่มวิธีการเริ่มต้นใหม่default void foo()ให้กับอินเทอร์เฟซIxจากนั้นชั้นเรียนCxดำเนินการIxและมีfooวิธีการส่วนตัวที่มีลายเซ็นเดียวกันจะไม่รวบรวม อะไรคือสาเหตุหลักที่ทำให้เกิดการเปลี่ยนแปลงครั้งใหญ่และพวกเขาจะได้ประโยชน์อะไรบ้าง (ถ้ามี)

99 java  programming-languages  interfaces  java8 

มีการถกเถียงกันในทีมของเราในขณะนี้ว่าการปรับเปลี่ยนการออกแบบรหัสเพื่อให้การทดสอบหน่วยเป็นกลิ่นรหัสหรือในระดับที่สามารถทำได้โดยไม่ต้องมีกลิ่นรหัส สิ่งนี้เกิดขึ้นเพราะเราเพิ่งเริ่มวางแนวทางปฏิบัติที่มีอยู่ใน บริษัท พัฒนาซอฟต์แวร์อื่น ๆ โดยเฉพาะเราจะมีบริการ Web API ที่จะบางมาก ความรับผิดชอบหลักของมันคือการจัดการคำขอ / ตอบกลับเว็บและเรียก API พื้นฐานที่มีตรรกะทางธุรกิจ ตัวอย่างหนึ่งคือเราวางแผนที่จะสร้างโรงงานที่จะคืนค่าประเภทวิธีการตรวจสอบสิทธิ์ เราไม่จำเป็นต้องให้อินเทอร์เฟซสืบทอดเนื่องจากเราไม่ได้คาดหวังว่ามันจะเป็นสิ่งอื่นนอกเหนือจากรูปแบบที่เป็นรูปธรรม อย่างไรก็ตามหากต้องการทดสอบบริการ Web API เราจะต้องจำลองโรงงานนี้ นี่หมายถึงว่าเราออกแบบคลาสคอนโทรลเลอร์ API ของเว็บเพื่อยอมรับ DI (ผ่าน Constructor หรือ Setter) ซึ่งหมายความว่าเราออกแบบส่วนของคอนโทรลเลอร์เพียงเพื่อให้ DI และใช้อินเตอร์เฟสที่เราไม่ต้องการหรือเราใช้ เฟรมเวิร์กของบุคคลที่สามอย่าง Ninject เพื่อหลีกเลี่ยงการออกแบบคอนโทรลเลอร์ในลักษณะนี้ แต่เราจะต้องสร้างอินเทอร์เฟซ บางคนในทีมดูเหมือนไม่เต็มใจที่จะออกแบบรหัสเพื่อการทดสอบ ดูเหมือนว่าฉันจะต้องมีการประนีประนอมบางอย่างถ้าคุณหวังว่าจะทดสอบหน่วย แต่ฉันไม่แน่ใจว่าบรรเทาความกังวลของพวกเขาอย่างไร เพื่อให้ชัดเจนนี่คือโครงการใหม่ล่าสุดดังนั้นจึงไม่ได้เกี่ยวกับการแก้ไขโค้ดเพื่อเปิดใช้งานการทดสอบหน่วย มันเกี่ยวกับการออกแบบโค้ดที่เราจะเขียนให้ทดสอบได้

91 unit-testing  interfaces  web-api  asp.net-core 

การเรียนหลักสูตรผู้เริ่มต้นบนอินเทอร์เฟซฮาร์ดแวร์ / ซอฟต์แวร์และระบบปฏิบัติการมักจะเกิดหัวข้อว่าจะเป็นการดีกว่าถ้าจะแทนที่ส่วนฮาร์ดแวร์บางส่วนด้วยซอฟต์แวร์และในทางกลับกัน ฉันไม่สามารถเชื่อมต่อได้

90 interfaces  operating-systems  software  hardware 

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

73 naming  interfaces  coding-standards 

"คลาสนามธรรม" และ "อินเทอร์เฟซ" เป็นแนวคิดที่คล้ายกันโดยอินเทอร์เฟซเป็นนามธรรมของทั้งสอง ปัจจัยที่แตกต่างอย่างหนึ่งคือคลาสนามธรรมจะจัดเตรียมวิธีการใช้งานสำหรับคลาสที่ได้รับเมื่อต้องการ อย่างไรก็ตามใน C # ปัจจัยที่มีความแตกต่างนี้ได้รับการลดลงโดยการแนะนำวิธีการขยายล่าสุดซึ่งช่วยให้การใช้งานมีไว้สำหรับวิธีการอินเทอร์เฟซ ปัจจัยที่มีความแตกต่างอีกอย่างหนึ่งคือคลาสสามารถสืบทอดคลาสนามธรรมเพียงคลาสเดียวเท่านั้น (กล่าวคือไม่มีการสืบทอดหลายคลาส) แต่สามารถใช้หลายอินเตอร์เฟสได้ ทำให้ส่วนต่อประสานที่ จำกัด น้อยลงและมีความยืดหยุ่นมากขึ้น ดังนั้นใน C # เราควรใช้คลาสนามธรรมแทนอินเทอร์เฟซกับวิธีการส่วนขยายหรือไม่ ตัวอย่างที่น่าสังเกตของโมเดลวิธีส่วนต่อประสาน + ส่วนต่อขยายคือ LINQ โดยที่ฟังก์ชันการสืบค้นมีให้สำหรับประเภทใดก็ตามที่ใช้IEnumerableวิธีการขยายจำนวนมาก

70 c#  design  interfaces  inheritance  abstract-class 

ดีกว่าอะไรและเพราะอะไร (จากมุมมองของการออกแบบอินเตอร์เฟส): a) มีสองShow()และHide()ฟังก์ชั่น b) การมีSetVisible(bool visible)ฟังก์ชั่นเดียว แก้ไข: ตัวอย่างเช่นวัตถุบางอย่างมีสถานะการมองเห็นและฟังก์ชั่นนี้จะใช้ในการเปลี่ยนแปลง ค) มีทั้งสามShow(), Hide(), SetVisible(bool visible)ฟังก์ชั่น

59 java  c++  interfaces 

ใน C # รหัสต่อไปนี้ถูกต้อง interface I{ int property{get;set;} } ซึ่งไม่สมเหตุสมผลเลยสำหรับฉัน สิ่งนี้ดูเหมือนจะทำลายหนึ่งในหลักการที่สำคัญที่สุดของอินเทอร์เฟซ: ขาดสถานะ (กล่าวอีกนัยหนึ่งไม่มีฟิลด์) สถานที่ให้บริการไม่ได้สร้างเขตข้อมูลส่วนตัวโดยนัย? นั่นจะไม่เลวสำหรับอินเทอร์เฟซหรือไม่

47 c#  interfaces  properties 

ฉันมีเพื่อนร่วมงานนั่งถัดจากฉันที่ออกแบบอินเทอร์เฟซเช่นนี้: public interface IEventGetter { public List<FooType> getFooList(String fooName, Date start, Date end) throws Exception; .... } ปัญหาคือตอนนี้เราไม่ได้ใช้พารามิเตอร์ "สิ้นสุด" ที่ใดก็ได้ในรหัสของเรามันอยู่ที่นั่นเพราะเราอาจจะต้องใช้มันในอนาคต เรากำลังพยายามโน้มน้าวเขาว่าเป็นความคิดที่ดีที่จะใส่พารามิเตอร์ไว้ในส่วนต่อประสานที่ไม่ได้ใช้งานในตอนนี้ แต่เขายืนยันอย่างต่อเนื่องว่างานจำนวนมากจะต้องทำถ้าเราใช้วันที่ "สิ้นสุด" ในบางครั้ง ในภายหลังและต้องปรับรหัสทั้งหมดแล้ว ตอนนี้คำถามของฉันคือมีแหล่งที่จัดการหัวข้อเช่นนี้ของปรมาจารย์การเข้ารหัส "เคารพ" ที่เราสามารถเชื่อมโยงเขาไป?

42 java  object-oriented-design  interfaces 

ในคำปราศรัยการประชุม goto ในการประชุมระดมความคิดที่กระตุ้นความคิดของ " มูลค่าของคุณค่า " ในเวลา 29 นาทีที่เขาพูดถึงค่าใช้จ่ายในภาษาจาวาและทำให้คำสั่งเช่น เขาหมายถึงอะไร มันเป็นเรื่องจริงเหรอ? ในการค้นหาคำตอบของฉันฉันเจอ: หลักการของความรู้น้อยที่สุด AKA กฎหมายของ Demeterซึ่งสนับสนุนการเชื่อมต่อ API แบบสุญญากาศ Wikipedia ยังแสดงข้อเสียบางประการ วิกฤตเสื้อผ้าของ Kevlin Henney ซึ่งระบุว่าการใช้ไม่ใช่การใช้ซ้ำเป็นเป้าหมายที่เหมาะสม การพูดคุยเรื่อง " Stop Writing Classes " ของ Jack Diederich ซึ่งขัดแย้งกับเรื่องวิศวกรรมโดยทั่วไป เห็นได้ชัดว่าสิ่งใดที่เขียนไม่ดีพอจะไร้ประโยชน์ แต่อินเทอร์เฟซของ API ที่เขียนดีจะป้องกันไม่ให้ใช้รหัสนั้นได้อย่างไร มีตัวอย่างตลอดประวัติศาสตร์ของบางสิ่งบางอย่างที่ทำขึ้นเพื่อจุดประสงค์เดียวที่ถูกใช้เพื่อสิ่งอื่นมากกว่า แต่ในโลกของซอฟต์แวร์ถ้าคุณใช้บางอย่างเพื่อจุดประสงค์ที่ไม่ได้มีไว้สำหรับมันก็มักจะแตก ฉันกำลังมองหาหนึ่งตัวอย่างที่ดีของอินเทอร์เฟซที่ดีที่ป้องกันไม่ให้ใช้รหัสบางอย่างถูกต้อง มีอยู่จริงเหรอ? ฉันไม่สามารถจินตนาการได้

41 java  interfaces  code-reuse  clojure 

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

40 programming-practices  coding-style  interfaces 

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

37 object-oriented  architecture  inheritance  interfaces