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

ฉันเพิ่งออกแบบแอปพลิเคชันของฉันและฉันไม่แน่ใจว่าฉันเข้าใจ SOLID และ OOP ถูกต้องหรือไม่ คลาสควรทำ 1 สิ่งและทำได้ดี แต่ในทางกลับกันพวกเขาควรเป็นตัวแทนวัตถุจริงที่เราทำงานด้วย ในกรณีของฉันฉันทำการแยกฟีเจอร์บนชุดข้อมูลจากนั้นฉันทำการวิเคราะห์การเรียนรู้ของเครื่อง ฉันคิดว่าฉันสามารถสร้างสามคลาส FeatureExtractor ชุดข้อมูล วิเคราะห์ แต่คลาส FeatureExtractor ไม่ได้แสดงอะไรเลยมันทำสิ่งที่ทำให้มันเป็นกิจวัตรมากกว่าคลาส มันจะมีเพียงหนึ่งฟังก์ชั่นที่จะใช้: extract_features () ถูกต้องหรือไม่ที่จะสร้างคลาสที่ไม่ได้เป็นตัวแทนของสิ่งหนึ่ง แต่ทำสิ่งใดสิ่งหนึ่ง แก้ไข: ไม่แน่ใจว่ามันสำคัญ แต่ฉันใช้ Python และถ้า extract_features () จะมีลักษณะเช่นนั้น: มันคุ้มค่าไหมที่จะสร้างคลาสพิเศษเพื่อเก็บเมธอดนั้น def extract_features(df): extr = PhrasesExtractor() extr.build_vocabulary(df["Text"].tolist()) sent = SentimentAnalyser() sent.load() df = add_features(df, extr.features) df = mark_features(df, extr.extract_features) df …

42 object-oriented  object-oriented-design  solid 

ฉันสงสัยอยู่ตลอดว่าจะใช้กริยาที่ถูกต้องตามคำนามใน OOP หรือไม่ ฉันเจอบทความที่ยอดเยี่ยมนี้แต่ฉันก็ยังไม่เห็นด้วยกับประเด็นที่ทำ เพื่ออธิบายปัญหาที่เกิดขึ้นอีกเล็กน้อยรัฐบทความที่ว่ามีไม่ควรจะเป็นตัวอย่างเช่นFileWriterชั้น แต่เนื่องจากการเขียนคือการกระทำที่มันควรจะเป็นวิธีการFileของการเรียน คุณจะได้รับรู้ว่ามันมักจะขึ้นอยู่กับภาษาเนื่องจากโปรแกรมเมอร์ Ruby อาจต่อต้านการใช้FileWriterคลาส (Ruby ใช้วิธีFile.openการเข้าถึงไฟล์) ในขณะที่โปรแกรมเมอร์ Java ไม่ต้องการ มุมมองส่วนบุคคลของฉัน (และใช่ต่ำต้อยมาก) คือการทำเช่นนั้นจะทำลายหลักการความรับผิดชอบเดี่ยว เมื่อฉันตั้งโปรแกรมใน PHP (เพราะเห็นได้ชัดว่า PHP เป็นภาษาที่ดีที่สุดสำหรับ OOP ใช่มั้ย) ฉันมักจะใช้เฟรมเวิร์กประเภทนี้: <?php // This is just an example that I just made on the fly, may contain errors class User extends Record { protected $name; public …

42 object-oriented  solid  single-responsibility 

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

41 functional-programming  solid 

ตามเอกสารของ Microsoft บทความ Wikipedia SOLID principe หรือสถาปนิกด้านไอทีส่วนใหญ่เราต้องตรวจสอบให้แน่ใจว่าแต่ละชั้นมีหน้าที่รับผิดชอบเพียงอย่างเดียว ฉันอยากจะรู้ว่าทำไมเพราะถ้าทุกคนดูเหมือนจะเห็นด้วยกับกฎนี้ดูเหมือนจะไม่มีใครเห็นด้วยกับเหตุผลของกฎนี้ บางคนกล่าวถึงการบำรุงรักษาที่ดีกว่าบางคนบอกว่าเป็นการทดสอบที่ง่ายหรือทำให้ชั้นเรียนมีความแข็งแกร่งมากขึ้นหรือมีความปลอดภัย อะไรถูกและจริงหมายถึงอะไร ทำไมจึงทำให้การบำรุงรักษาดีขึ้นการทดสอบง่ายขึ้นหรือรหัสมีเสถียรภาพมากขึ้น?

37 design-patterns  architecture  solid  single-responsibility 

ฉันพบว่าหลักการของ SOLIDค่อนข้างมีประโยชน์เมื่อคิดถึงการออกแบบเชิงวัตถุ มีหลักการเกี่ยวกับภาษาที่ไม่เชื่อเรื่องพระเจ้า / ชุดที่คล้ายกันเหมาะสำหรับการเขียนโปรแกรมการทำงานหรือไม่?

35 design-patterns  functional-programming  solid 

ในแอปพลิเคชันขนาดใหญ่ส่วนใหญ่ของเราเรามักจะมีเพียงไม่กี่ตำแหน่งสำหรับ "ค่าคงที่": หนึ่งคลาสสำหรับ GUI และค่าคงที่ภายใน (ชื่อแท็บหน้า, ชื่อกลุ่มกล่อง, ปัจจัยการคำนวณ, การแจกแจง) หนึ่งคลาสสำหรับตารางและคอลัมน์ฐานข้อมูล (ส่วนนี้เป็นรหัสที่สร้างขึ้น) พร้อมชื่อที่อ่านได้สำหรับพวกเขา (กำหนดด้วยตนเอง) คลาสหนึ่งสำหรับข้อความแอปพลิเคชัน (การบันทึกกล่องข้อความ ฯลฯ ) ค่าคงที่มักจะถูกแยกออกเป็นส่วนต่าง ๆ ในคลาสเหล่านั้น ในแอปพลิเคชัน C ++ ของเราค่าคงที่จะถูกกำหนดเฉพาะในไฟล์. h และค่าจะถูกกำหนดในไฟล์. cpp ข้อดีอย่างหนึ่งก็คือสตริงทั้งหมด ฯลฯ อยู่ในจุดศูนย์กลางเดียวและทุกคนรู้ว่าจะต้องค้นหาสิ่งใดเมื่อต้องมีการเปลี่ยนแปลง นี่เป็นสิ่งที่ผู้จัดการโครงการดูเหมือนจะเป็นอย่างที่ผู้คนเข้ามาและด้วยวิธีนี้ทุกคนสามารถเปลี่ยนแปลงสิ่งเล็ก ๆ น้อย ๆ ได้โดยไม่ต้องขุดเข้าไปในโครงสร้างของแอปพลิเคชัน นอกจากนี้คุณสามารถเปลี่ยนชื่อของกลุ่มกล่อง / หน้าแท็บที่คล้ายกันได้อย่างง่ายดายในครั้งเดียว อีกแง่มุมหนึ่งคือคุณสามารถพิมพ์คลาสนั้นและมอบให้กับผู้ที่ไม่ใช่โปรแกรมเมอร์ซึ่งสามารถตรวจสอบคำอธิบายภาพว่าใช้งานง่ายหรือไม่และข้อความที่ส่งถึงผู้ใช้นั้นละเอียดเกินไปหรือสับสนเกินไป อย่างไรก็ตามฉันเห็นข้อเสียบางอย่าง: ทุกชั้นเรียนจะถูกผนวกเข้ากับชั้นเรียนอย่างต่อเนื่อง การเพิ่ม / ลบ / เปลี่ยนชื่อ / ย้ายค่าคงที่ต้องมีการคอมไพล์ใหม่อย่างน้อย 90% ของแอปพลิเคชัน …

34 architecture  development-process  solid  coupling 

บริบท ในClean Codeหน้า 35 บอกไว้ นี่ก็หมายความว่าบล็อกภายในถ้าคำสั่งคำสั่งอื่นในขณะที่คำสั่งและอื่น ๆ ควรมีความยาวหนึ่งบรรทัด อาจเป็นไปได้ว่าสายควรจะเรียกฟังก์ชั่น สิ่งนี้ไม่เพียงทำให้ฟังก์ชั่นการปิดล้อมมีขนาดเล็ก แต่ยังเพิ่มมูลค่าเอกสารเพราะฟังก์ชั่นที่เรียกว่าภายในบล็อกสามารถมีชื่อที่สื่อความหมายได้ดี ฉันเห็นด้วยอย่างสมบูรณ์ซึ่งทำให้รู้สึกมาก ต่อมาในหน้า 40 มันพูดเกี่ยวกับข้อโต้แย้งฟังก์ชั่น จำนวนอาร์กิวเมนต์ที่เหมาะสมที่สุดสำหรับฟังก์ชันคือศูนย์ (niladic) ถัดมาคือหนึ่ง (monadic) ตามมาด้วยสอง (dyadic) ควรหลีกเลี่ยงการโต้แย้งสามครั้ง (triadic) หากเป็นไปได้ มากกว่าสาม (polyadic) ต้องมีเหตุผลพิเศษมาก - จากนั้นไม่ควรใช้ต่อไป การโต้แย้งยาก พวกเขาใช้พลังความคิดมากมาย ฉันเห็นด้วยอย่างสมบูรณ์ซึ่งทำให้รู้สึกมาก ปัญหา อย่างไรก็ตามบ่อยครั้งที่ฉันพบว่าตัวเองกำลังสร้างรายการจากรายการอื่นและฉันจะต้องอยู่กับหนึ่งในสองความชั่วร้าย ฉันใช้สองบรรทัดในบล็อกหนึ่งรายการสำหรับสร้างสิ่งหนึ่งสำหรับเพิ่มไปยังผลลัพธ์: public List<Flurp> CreateFlurps(List<BadaBoom> badaBooms) { List<Flurp> flurps = new List<Flurp>(); foreach (BadaBoom badaBoom in badaBooms) …

33 clean-code  solid 

Userสมมติว่าสำหรับตัวอย่างเช่นคุณมีการประยุกต์ใช้กับการเรียนร่วมกันอย่างกว้างขวางเรียกว่า คลาสนี้จะเปิดเผยข้อมูลทั้งหมดเกี่ยวกับผู้ใช้ ID ชื่อระดับการเข้าถึงแต่ละโมดูลเขตเวลา ฯลฯ ข้อมูลผู้ใช้นั้นถูกอ้างอิงอย่างกว้างขวางทั่วทั้งระบบ แต่ไม่ว่าจะด้วยเหตุผลใดก็ตามระบบได้รับการตั้งค่าเพื่อให้แทนที่จะส่งผู้ใช้วัตถุนี้ไปยังคลาสที่ขึ้นอยู่กับว่าเรากำลังส่งผ่านคุณสมบัติของแต่ละบุคคล คลาสที่ต้องการ ID ผู้ใช้เพียงแค่ต้องการ GUID userIdเป็นพารามิเตอร์บางครั้งเราอาจต้องการชื่อผู้ใช้ด้วยดังนั้นจะถูกส่งผ่านเป็นพารามิเตอร์แยกต่างหาก ในบางกรณีสิ่งนี้จะถูกส่งไปยังแต่ละวิธีดังนั้นค่าจะไม่ถูกเก็บไว้ที่ระดับชั้นเลย ทุกครั้งที่ฉันต้องการเข้าถึงข้อมูลที่แตกต่างจากคลาสผู้ใช้ฉันต้องทำการเปลี่ยนแปลงโดยการเพิ่มพารามิเตอร์และเมื่อการเพิ่มโอเวอร์โหลดใหม่ไม่เหมาะสมฉันต้องเปลี่ยนการอ้างอิงถึงเมธอดหรือตัวสร้างคลาสทุกครั้ง ผู้ใช้เป็นเพียงตัวอย่างเดียว นี่คือการฝึกฝนอย่างกว้างขวางในรหัสของเรา ฉันคิดถูกไหมว่านี่เป็นการละเมิดหลักการเปิด / ปิด? ไม่ใช่แค่การเปลี่ยนคลาสที่มีอยู่ แต่ตั้งค่าไว้ตั้งแต่แรกเพื่อให้การเปลี่ยนแปลงอย่างกว้างขวางมีความเป็นไปได้สูงที่จะเป็นสิ่งจำเป็นในอนาคต? ถ้าเราเพิ่งผ่านไปใน Userวัตถุฉันสามารถเปลี่ยนแปลงชั้นเรียนเล็ก ๆ ที่ฉันทำงานด้วยได้ ถ้าฉันต้องเพิ่มพารามิเตอร์ฉันอาจต้องทำการเปลี่ยนแปลงหลายสิบครั้งเพื่ออ้างอิงไปยังคลาส มีหลักการอื่นใดที่ผิดไปจากการฝึกฝนนี้หรือไม่? การผกผันของการพึ่งพาอาจจะ? แม้ว่าเราจะไม่ได้อ้างถึงสิ่งที่เป็นนามธรรม แต่ก็มีผู้ใช้เพียงประเภทเดียวดังนั้นจึงไม่จำเป็นต้องมีอินเทอร์เฟซผู้ใช้ มีการละเมิดหลักการอื่น ๆ ที่ไม่ใช่แบบแข็งเช่นหลักการตั้งโปรแกรมการป้องกันขั้นพื้นฐานหรือไม่? ตัวสร้างของฉันควรมีลักษณะเช่นนี้: MyConstructor(GUID userid, String username) หรือสิ่งนี้: MyConstructor(User theUser) โพสต์แก้ไข: มีคนแนะนำว่าคำถามนั้นตอบใน "รหัสผ่านหรือวัตถุ?" สิ่งนี้ไม่ได้ตอบคำถามว่าการตัดสินใจไปทางใดมีผลต่อความพยายามในการปฏิบัติตามหลักการของ SOLID ซึ่งเป็นหัวใจหลักของคำถามนี้

30 java  c#  design  solid 

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

28 object-oriented  anti-patterns  solid 

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

27 object-oriented  object-oriented-design  solid  design-principles  liskov-substitution 

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

27 language-agnostic  solid  static-access 

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

27 design  object-oriented  solid 

ฉันเพิ่งได้พูดคุยกับเพื่อนของฉันเกี่ยวกับ OOP ในการพัฒนาวิดีโอเกม ฉันอธิบายสถาปัตยกรรมของหนึ่งในเกมของฉันซึ่งทำให้เพื่อนของฉันประหลาดใจมีชั้นเรียนขนาดเล็กจำนวนมากและเลเยอร์สิ่งที่เป็นนามธรรมหลายชั้น ฉันเป็นที่ถกเถียงกันอยู่ว่านี่เป็นผลมาจากการที่ฉันมุ่งเน้นไปที่การให้ความรับผิดชอบทุกอย่างเดียวและยังช่วยลดการเชื่อมต่อระหว่างส่วนประกอบ ความกังวลของเขาคือจำนวนชั้นเรียนจำนวนมากจะแปลฝันร้ายบำรุงรักษา มุมมองของฉันคือว่ามันจะมีผลตรงกันข้ามที่แน่นอน เราดำเนินการหารือเกี่ยวกับเรื่องนี้สำหรับสิ่งที่ดูเหมือนว่าหลายศตวรรษในที่สุดก็ตกลงที่จะไม่เห็นด้วยบอกว่าอาจมีบางกรณีที่หลักการที่เป็นของแข็งและ OOP ที่เหมาะสมไม่จริงผสมกันได้ดี แม้แต่รายการ Wikipediaเกี่ยวกับหลักการ SOLID ก็ระบุว่าเป็นแนวทางที่ช่วยในการเขียนโค้ดที่สามารถบำรุงรักษาได้และเป็นส่วนหนึ่งของกลยุทธ์โดยรวมของการเขียนโปรแกรมแบบคล่องตัวและปรับตัว ดังนั้นคำถามของฉันคือ: มีกรณีใน OOP ที่หลักการ SOLID บางส่วนหรือทั้งหมดไม่ได้ยืมตัวเองเพื่อทำความสะอาดรหัสหรือไม่? ฉันสามารถจินตนาการได้ทันทีว่าหลักการทดแทน Liskov อาจขัดแย้งกับการรับมรดกที่ปลอดภัยอีกรสชาติหนึ่ง กล่าวคือหากมีใครคิดรูปแบบที่มีประโยชน์อื่น ๆ ที่นำมาใช้ผ่านการสืบทอดมันค่อนข้างเป็นไปได้ที่ LSP อาจขัดแย้งโดยตรงกับมัน มีคนอื่นไหม? บางทีโครงการบางประเภทหรือแพลตฟอร์มเป้าหมายบางอย่างอาจทำงานได้ดีขึ้นด้วยวิธี SOLID ที่น้อยลง? แก้ไข: ฉันแค่ต้องการระบุว่าฉันไม่ได้ถามวิธีการปรับปรุงรหัสของฉัน;) เหตุผลเดียวที่ฉันพูดถึงโครงการในคำถามนี้คือการให้บริบทเล็กน้อย คำถามของฉันเป็นเรื่องเกี่ยวกับหลักการ OOP และการออกแบบทั่วไป หากคุณอยากรู้เกี่ยวกับโครงการของฉันให้ดูนี้ แก้ไข 2: ฉันจินตนาการว่าคำถามนี้จะตอบในหนึ่งใน 3 วิธี: ใช่มีหลักการออกแบบของ OOP ที่ขัดแย้งกับ SOLID บางส่วน ใช่มีหลักการออกแบบของ …

26 object-oriented  solid 

ฉันทำงานเป็นเวลาสองปีในวาณิชธนกิจที่ยิ่งใหญ่ ฉันทำโครงการด้านเทคนิคบางอย่างด้วยความปรารถนาที่จะสร้างโค้ดที่มีประสิทธิภาพสูงสุดโดยคำนึงถึงรูปแบบการออกแบบที่ดีที่ปรับได้หลักการ SOLID กฎหมายของ demeter และหลีกเลี่ยงรหัสที่ซ้ำกันทุกประเภท ... เมื่อส่งมอบในการผลิต => ศูนย์ข้อบกพร่องทั้งหมดเกิดขึ้นตามที่คาดไว้ แต่นักพัฒนาส่วนใหญ่มาหาฉันเพื่อที่จะแม่นยำว่ารหัสของฉันทั้งหมดนั้นซับซ้อนเกินไปสำหรับการอ่านเพื่อความเข้าใจ ฉันฟังตัวอย่างเช่น: "ทำบางอย่างถ้าและอินสแตนซ์ของลืมความหลากหลายเพื่อที่จะแก้ไขข้อบกพร่องการผลิตฉุกเฉินได้อย่างง่ายดาย" ฉันไม่ชอบตอบ ...... การรู้ว่านักพัฒนาเหล่านี้ไม่อยากรู้อยากเห็นเลยปฏิเสธความพยายามที่จะเข้าใจการออกแบบที่ดี (ตัวอย่างเช่น 90% ของผู้พัฒนาไม่รู้ว่าอะไรคือรูปแบบกลยุทธ์และสร้างรหัสขั้นตอนและไม่เคยออกแบบเพราะพวกเขาต้องการ ) ผู้จัดการโครงการของฉันบอกว่าฉันผิดจริง ๆ และเป็นนักอุดมคติในโลกของธนาคาร คุณจะแนะนำอะไรให้ฉัน ฉันควรรักษาความปรารถนาของรหัสที่ดีจริง ๆ หรือปรับให้ฉันเป็นนักพัฒนาส่วนใหญ่ที่ฉันทำซ้ำไม่น่าสนใจจริงๆโดยการออกแบบรหัสตามที่ฉันความงามทั้งหมดของงานนักพัฒนาของเรา หรือในทางตรงกันข้ามพวกเขาควรเรียนรู้หลักการ OO ขั้นพื้นฐานและแนวปฏิบัติที่ดีที่สุดเพื่อปรับตัวให้เข้ากับรหัสของฉันหรือไม่?

23 java  design  design-patterns  solid 

สมมติว่าฉันมีอินเทอร์เฟซFooInterfaceที่มีลายเซ็นต่อไปนี้: interface FooInterface { public function doSomething(SomethingInterface something); } และคลาสรูปธรรมConcreteFooที่ใช้ส่วนต่อประสานนั้น: class ConcreteFoo implements FooInterface { public function doSomething(SomethingInterface something) { } } ฉันต้องการConcreteFoo::doSomething()ทำสิ่งที่ไม่ซ้ำกันหากผ่านSomethingInterfaceวัตถุชนิดพิเศษ(สมมติว่ามันถูกเรียกว่าSpecialSomething) มันเป็นการละเมิด LSP อย่างแน่นอนถ้าฉันเพิ่มเงื่อนไขของวิธีการหรือสร้างข้อยกเว้นใหม่ แต่มันจะเป็นการละเมิด LSP หรือไม่ถ้าฉันใส่SpecialSomethingวัตถุพิเศษในขณะที่ให้ทางเลือกสำหรับSomethingInterfaceวัตถุทั่วไป? สิ่งที่ต้องการ: class ConcreteFoo implements FooInterface { public function doSomething(SomethingInterface something) { if (something instanceof SpecialSomething) { // Do SpecialSomething magic } …

20 object-oriented  solid  liskov-substitution