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

หาก Square เป็นรูปแบบสี่เหลี่ยมผืนผ้ากว่าเหตุใด Square จึงไม่สามารถสืบทอดจากสี่เหลี่ยมผืนผ้าได้ หรือทำไมมันถึงออกแบบไม่ดี? ฉันเคยได้ยินคนพูดว่า: หากคุณกำหนดให้ Square ได้รับมาจากสี่เหลี่ยมผืนผ้าดังนั้น Square ควรใช้งานได้ทุกที่ที่คุณคาดว่าสี่เหลี่ยมผืนผ้า ปัญหาคืออะไรที่นี่? และทำไม Square ถึงใช้งานได้ทุกที่ที่คุณคาดหวังสี่เหลี่ยมผืนผ้า? มันจะใช้งานได้เฉพาะเมื่อเราสร้างวัตถุสแควร์และถ้าเราแทนที่วิธี SetWidth และ SetHeight สำหรับสแควร์กว่าทำไมจะมีปัญหาใด ๆ ? ถ้าคุณมีเมธอด SetWidth และ SetHeight บนคลาสพื้นฐานสี่เหลี่ยมผืนผ้าของคุณและถ้าการอ้างอิงสี่เหลี่ยมผืนผ้าของคุณชี้ไปที่สแควร์แล้ว SetWidth และ SetHeight ไม่สมเหตุสมผลเนื่องจากการตั้งค่าอย่างใดอย่างหนึ่งจะเปลี่ยนอีกเพื่อให้ตรงกับมัน ในกรณีนี้สแควร์ล้มเหลวการทดสอบการทดแทน Liskov ด้วยสี่เหลี่ยมผืนผ้าและนามธรรมของการมีการสืบทอดสแควร์จากสี่เหลี่ยมผืนผ้าเป็นสิ่งที่ไม่ดี บางคนสามารถอธิบายข้อโต้แย้งข้างต้นได้หรือไม่ อีกครั้งถ้าเราใช้วิธี SetWidth และ SetHeight มากเกินไปใน Square มันจะไม่แก้ไขปัญหานี้หรือไม่ ฉันเคยได้ยิน / อ่านด้วย: ปัญหาที่แท้จริงคือเราไม่ได้สร้างโมเดลสี่เหลี่ยมผืนผ้า แต่เป็น "สี่เหลี่ยมที่ปรับเปลี่ยนได้" เช่นสี่เหลี่ยมที่มีความกว้างหรือความสูงสามารถปรับเปลี่ยนได้หลังจากการสร้าง …

105 object-oriented-design  inheritance  abstraction  solid 

เมื่อเร็ว ๆ นี้ฉันได้สังเกตเห็นคำถามมากมายเกี่ยวกับเทคนิคที่เป็นนามธรรมที่แตกต่างกันและคำตอบที่บอกโดยทั่วไปว่าเทคนิคในคำถามนั้น "ฉลาดเกินไป" ฉันคิดว่าส่วนหนึ่งของงานของเราในฐานะโปรแกรมเมอร์คือการหาทางออกที่ดีที่สุดสำหรับปัญหาที่เราได้รับในการแก้ปัญหาและความฉลาดก็มีประโยชน์ในการทำเช่นนั้น ดังนั้นคำถามของฉันคือเป็นคนที่คิดว่าเทคนิคนามธรรมบางอย่างจะฉลาดเกินไปตรงข้ามกับความฉลาดต่อ seหรือมีบางเหตุผลอื่น ๆ สำหรับการคัดค้านหรือไม่ แก้ไข: combinator parserนี้เป็นตัวอย่างของสิ่งที่ฉันจะถือว่าเป็นรหัสที่ฉลาด ฉันดาวน์โหลดมันและดูมันประมาณครึ่งชั่วโมง จากนั้นฉันก็ก้าวผ่านการขยายมาโครลงบนกระดาษและเห็นแสง ตอนนี้ฉันเข้าใจแล้วมันดูสง่างามยิ่งกว่าตัวรวมตัวแยกวิเคราะห์ Haskell

89 abstraction 

ฉันเป็นผู้รับจ้างอิสระดังนั้นฉันจึงสัมภาษณ์ 3-4 ครั้งต่อปีเพื่อหากิ๊กใหม่ ๆ ตอนนี้ฉันอยู่ในรอบนั้นและกลับกลายเป็นโอกาสแม้ว่าฉันจะรู้สึกว่าการสัมภาษณ์เป็นไปด้วยดี สิ่งเดียวกันเกิดขึ้นกับฉันสองสามครั้งในปีนี้ ตอนนี้ฉันไม่ได้เป็นคนที่สมบูรณ์แบบและฉันไม่คาดหวังว่าจะเป็นแบบที่ดีสำหรับทุกองค์กร ที่กล่าวว่าแม่นเฉลี่ยของฉันต่ำกว่าปกติดังนั้นฉันถามผู้สัมภาษณ์สุดท้ายของฉันสำหรับข้อเสนอแนะที่สร้างสรรค์และเขาส่ง! สิ่งสำคัญตามที่ผู้สัมภาษณ์กล่าวคือฉันดูเหมือนจะเอนตัวไปสู่การใช้ abstractions (เช่น LINQ) มากกว่าที่จะไปสู่อัลกอริทึมที่ต่ำกว่าและมีการเติบโตแบบออร์แกนิก บนพื้นผิวสิ่งนี้ก็สมเหตุสมผล - ในความเป็นจริงมันทำให้คนอื่นปฏิเสธด้วยเช่นกันเพราะฉันพูดเรื่อง LINQ ในการสัมภาษณ์เหล่านั้นด้วยและดูเหมือนว่าผู้สัมภาษณ์รู้เรื่อง LINQ ไม่มากนัก (แม้ว่าพวกเขาจะเป็น. NET ผู้ชาย) ดังนั้นตอนนี้ฉันเหลือคำถามนี้:ถ้าเราควรจะ "ยืนอยู่บนไหล่ของยักษ์" และใช้ abstractions ที่มีให้เรา (เช่น LINQ) แล้วทำไมบางคนคิดว่ามันต้องห้าม? มันไม่สมเหตุสมผลที่จะดึงรหัส "ปิดชั้นวาง" ถ้ามันบรรลุเป้าหมายเดียวกันโดยไม่มีค่าใช้จ่ายเพิ่มเติมหรือไม่ สำหรับฉันแล้วดูเหมือนว่า LINQ แม้ว่ามันจะเป็นนามธรรม แต่ก็เป็นเพียงนามธรรมของอัลกอริทึมเดียวกันทั้งหมดที่จะเขียนเพื่อให้บรรลุจุดสิ้นสุดเดียวกัน เฉพาะการทดสอบประสิทธิภาพเท่านั้นที่สามารถบอกคุณได้ว่าวิธีการที่กำหนดเองของคุณดีกว่าหรือไม่ แต่ถ้าสิ่งใดที่ LINQ มีคุณสมบัติตรงตามข้อกำหนดทำไมไม่ต้องเขียนชั้นเรียนของคุณเองในตอนแรก ฉันไม่ได้ตั้งใจจะให้ความสำคัญกับ LINQ ที่นี่ ฉันแน่ใจว่าโลกของ JAVA นั้นมีบางสิ่งที่คล้ายคลึงกันฉันแค่อยากจะรู้ว่าทำไมคนบางคนถึงรู้สึกอึดอัดใจกับความคิดที่จะใช้สิ่งที่เป็นนามธรรมที่พวกเขาไม่ได้เขียน UPDATE ตามที่ …

60 algorithms  .net  abstraction  linq 

ในฐานะโปรแกรมเมอร์ฉันรู้สึกว่าเป้าหมายของเราคือการให้ abstractions ที่ดีในรูปแบบโดเมนที่กำหนดและตรรกะทางธุรกิจ แต่สิ่งที่เป็นนามธรรมนี้ควรหยุด วิธีที่จะทำให้การแลกเปลี่ยนระหว่างสิ่งที่เป็นนามธรรมและผลประโยชน์ทั้งหมดของมัน (ความยืดหยุ่นความสะดวกในการเปลี่ยนแปลง ฯลฯ ) และความง่ายในการทำความเข้าใจรหัสและผลประโยชน์ทั้งหมดของมัน ฉันเชื่อว่าฉันมักจะเขียนโค้ดที่เป็นนามธรรมมากเกินไปและฉันก็ไม่รู้ว่ามันดีแค่ไหน ฉันมักจะเขียนมันเหมือนว่ามันเป็นไมโครเฟรมเวิร์กซึ่งประกอบด้วยสองส่วน: โมดูลขนาดเล็กที่ติดอยู่ในกรอบขนาดเล็ก: โมดูลเหล่านี้เข้าใจง่ายพัฒนาและดูแลรักษาเป็นหน่วยเดียว รหัสนี้แสดงถึงรหัสที่ใช้งานได้จริงตามที่อธิบายไว้ในข้อกำหนด กำลังเชื่อมต่อรหัส ตอนนี้ที่นี่ฉันเชื่อว่ายืนปัญหา รหัสนี้มีแนวโน้มที่จะซับซ้อนเพราะบางครั้งก็เป็นนามธรรมและยากที่จะเข้าใจในตอนแรก; สิ่งนี้เกิดขึ้นเนื่องจากความจริงที่ว่ามันเป็นเพียงนามธรรมที่บริสุทธิ์ฐานในความเป็นจริงและตรรกะทางธุรกิจที่ถูกดำเนินการในรหัสที่นำเสนอ 1; จากเหตุผลนี้รหัสนี้ไม่คาดว่าจะมีการเปลี่ยนแปลงเมื่อทดสอบ นี่เป็นวิธีการเขียนโปรแกรมที่ดีหรือไม่? ว่ามันมีการเปลี่ยนรหัสกระจัดกระจายมากในหลายโมดูลและง่ายมากที่จะเข้าใจและไม่เปลี่ยนแปลงรหัสซับซ้อนมากจาก POV นามธรรม? รหัสทั้งหมดควรจะมีความซับซ้อนเหมือนกัน (นั่นคือรหัส 1 ซับซ้อนกว่าและเชื่อมโยงกันและรหัส 2 ง่ายขึ้น) เพื่อให้ทุกคนที่มองผ่านมันสามารถเข้าใจได้ในระยะเวลาที่เหมาะสม แต่การเปลี่ยนแปลงมีราคาแพงหรือวิธีแก้ปัญหาที่นำเสนอข้างต้น "การเปลี่ยนรหัส" นั้นง่ายต่อการเข้าใจดีบั๊กเปลี่ยนและ "การเชื่อมโยงโค้ด" นั้นยาก หมายเหตุ: นี่ไม่เกี่ยวกับการอ่านรหัส! ทั้งโค้ดที่ 1 และ 2 สามารถอ่านได้ แต่โค้ดที่ 2 มาพร้อมกับ abstractions ที่ซับซ้อนมากขึ้นในขณะที่ code 1 …

46 programming-practices  complexity  abstraction 

มีคำจำกัดความที่ตกลงกันโดยทั่วไปสำหรับสิ่งที่เป็นนามธรรมของการเขียนโปรแกรมตามที่ใช้โดยโปรแกรมเมอร์หรือไม่ [หมายเหตุการเขียนโปรแกรมเชิงนามธรรมไม่ต้องสับสนกับคำจำกัดความของพจนานุกรมสำหรับคำว่า "สิ่งที่เป็นนามธรรม"] มีคำจำกัดความที่ชัดเจนหรือแม้แต่ทางคณิตศาสตร์หรือไม่? อะไรคือตัวอย่างที่ชัดเจนของ abstractions?

38 terminology  abstraction 

ฉันกำลังอ่านหนังสือที่เรียกว่า"รหัสสะอาด"ในวันนี้และฉันเจอวรรคหนึ่งที่ผู้เขียนพูดถึงระดับของสิ่งที่เป็นนามธรรมต่อฟังก์ชั่นเขาจำแนกรหัสบางส่วนว่าเป็นนามธรรมระดับต่ำ / ปานกลาง / สูง คำถามของฉันคือเกณฑ์ในการกำหนดระดับของสิ่งที่เป็นนามธรรมคืออะไร? ฉันพูดย่อหน้าจากหนังสือ: เพื่อให้แน่ใจว่าฟังก์ชั่นของเรากำลังทำ“ สิ่งเดียว” เราต้องตรวจสอบให้แน่ใจว่าข้อความในฟังก์ชั่นของเรานั้นอยู่ในระดับเดียวกันของนามธรรม มันง่ายที่จะดูว่ารายการ 3-1 ละเมิดกฎนี้อย่างไร มีแนวคิดที่มีอยู่ในระดับที่สูงมากของนามธรรมเช่น getHtml (); อื่น ๆ ที่อยู่ในระดับปานกลางของ abstraction เช่น: String pagePathName = PathParser.render (pagePath); และยังคงอยู่ในระดับต่ำอย่างน่าทึ่งเช่น:. append ("\ n")

35 abstraction 

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

33 time-management  problem-solving  abstraction 

มันค่อนข้างยากสำหรับฉันที่จะเข้าใจเงื่อนไขเหล่านี้ ฉันค้นหาใน google และอ่านวิกิพีเดียเล็กน้อย แต่ก็ยังไม่แน่ใจ ฉันตัดสินใจแล้วว่า: Abstract Data Typeเป็นคำนิยามของชนิดใหม่อธิบายคุณสมบัติและการดำเนินงานของมัน โครงสร้างข้อมูลเป็นการใช้งาน ADT ADT หลายตัวสามารถนำไปใช้กับโครงสร้างข้อมูลเดียวกันได้ ถ้าฉันคิดว่าถูกต้องอาเรย์เป็น ADT หมายถึงการรวบรวมองค์ประกอบและเป็นโครงสร้างข้อมูลการจัดเก็บในหน่วยความจำ สแต็คคือ ADT ที่มีการดำเนินการแบบพุชและป๊อป แต่เราสามารถพูดเกี่ยวกับโครงสร้างข้อมูลสแต็คได้หรือไม่ถ้าฉันหมายความว่า และทำไมฮีปจึงไม่ใช่ ADT มันสามารถนำมาใช้เป็นต้นไม้หรืออาร์เรย์

32 data-structures  abstraction 

พื้นหลัง ฉันไม่ใช่แฟนตัวยงของสิ่งที่เป็นนามธรรม ฉันจะยอมรับว่าสามารถได้รับประโยชน์จากความสามารถในการปรับตัวความสะดวกในการพกพาและการใช้งานอินเทอร์เฟซอีกครั้ง ฯลฯ มีประโยชน์ที่แท้จริงอยู่ที่นั่นและฉันไม่ต้องการตั้งคำถามนั้น มี "ประโยชน์" ที่สำคัญอื่น ๆ ของสิ่งที่เป็นนามธรรมซึ่งคือการซ่อนตรรกะการใช้งานและรายละเอียดจากผู้ใช้สิ่งที่เป็นนามธรรมนี้ เหตุผลก็คือคุณไม่จำเป็นต้องรู้รายละเอียดและควรให้ความสำคัญกับตรรกะของตนเองในตอนนี้ ทำให้รู้สึกในทางทฤษฎี อย่างไรก็ตามเมื่อใดก็ตามที่ฉันดูแลแอพพลิเคชั่นขององค์กรขนาดใหญ่ฉันจำเป็นต้องทราบรายละเอียดเพิ่มเติมอยู่เสมอ มันกลายเป็นความยุ่งยากครั้งใหญ่ที่ขุดลึกลงไปในสิ่งที่เป็นนามธรรมในทุก ๆ รอบเพื่อที่จะได้รู้ว่าสิ่งใดที่ทำ คือต้องทำ "open declaration" ประมาณ 12 ครั้งก่อนที่จะค้นหาโพรซีเดอร์ที่เก็บไว้ที่ใช้ นี่ 'ซ่อนรายละเอียด' ความคิดดูเหมือนว่าจะได้รับในทาง ฉันต้องการอินเทอร์เฟซที่โปร่งใสมากขึ้นและเป็นนามธรรมน้อยกว่าเสมอ ฉันสามารถอ่านซอร์สโค้ดระดับสูงและรู้ว่ามันทำอะไร แต่ฉันจะไม่มีทางรู้ว่ามันจะทำอย่างไรเมื่อมันเป็นเช่นนั้นคือสิ่งที่ฉันต้องรู้ เกิดอะไรขึ้นที่นี่? ทุกระบบที่ฉันเคยทำงานออกแบบมาไม่ดี (จากมุมมองนี้อย่างน้อย) หรือไม่? ปรัชญาของฉัน เมื่อฉันพัฒนาซอฟต์แวร์ฉันรู้สึกว่าฉันพยายามทำตามปรัชญาที่ฉันรู้สึกว่าเกี่ยวข้องกับปรัชญาของ ArchLinux : Arch Linux ยังคงความซับซ้อนโดยธรรมชาติของระบบ GNU / Linux ในขณะที่ยังคงความเป็นระเบียบและโปร่งใส ผู้พัฒนาและผู้ใช้ Arch Linux เชื่อว่าการพยายามซ่อนความซับซ้อนของระบบจริง ๆ แล้วจะส่งผลให้เกิดระบบที่ซับซ้อนยิ่งขึ้นดังนั้นจึงควรหลีกเลี่ยง ดังนั้นฉันไม่เคยพยายามซ่อนความซับซ้อนของซอฟต์แวร์ไว้เบื้องหลังเลเยอร์สิ่งที่เป็นนามธรรม …

30 object-oriented-design  abstraction 

ฉันจะบอกได้อย่างไรว่าซอฟต์แวร์ของฉันมีสิ่งที่เป็นนามธรรมมากเกินไปและมีรูปแบบการออกแบบมากเกินไปหรือในทางกลับกันฉันจะรู้ได้อย่างไรว่าควรมีซอฟต์แวร์มากกว่านั้น นักพัฒนาที่ฉันทำงานด้วยกำลังเขียนโปรแกรมต่าง ๆ เกี่ยวกับประเด็นเหล่านี้ บางฟังก์ชั่นเป็นนามธรรมทุกฟังก์ชั่นเล็กน้อยใช้รูปแบบการออกแบบทุกที่ที่เป็นไปได้ คนอื่นรวมถึงฉันพยายามที่จะใช้ประโยชน์ได้มากขึ้นและเขียนโค้ดที่ไม่เหมาะกับทุกรูปแบบการออกแบบ แต่เป็นวิธีที่เข้าใจได้เร็วขึ้นเพราะใช้นามธรรมน้อยกว่า ฉันรู้ว่านี่เป็นการแลกเปลี่ยน ฉันจะบอกได้อย่างไรว่ามีสิ่งที่เป็นนามธรรมเพียงพอในโครงการและฉันจะรู้ได้อย่างไรว่ามันต้องการมาก ตัวอย่างเมื่อเลเยอร์แคชทั่วไปถูกเขียนโดยใช้ Memcache เราจำเป็นต้องจริงๆMemcache, MemcacheAdapter, MemcacheInterface, AbstractCache, CacheFactory, CacheConnector... หรือคือง่ายต่อการรักษาและยังคงรหัสที่ดีเมื่อใช้เพียงครึ่งหนึ่งของชั้นเรียนเหล่านั้นหรือไม่ พบสิ่งนี้ใน Twitter: ( https://twitter.com/rawkode/status/875318003306565633 )

29 design-patterns  architecture  clean-code  abstraction  architectural-patterns 

ปิด คำถามนี้เป็นคำถามความคิดเห็นตาม ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้สามารถตอบข้อเท็จจริงและการอ้างอิงได้โดยแก้ไขโพสต์นี้ ปิดให้บริการใน5 ปีที่ผ่านมา ฉันเขียนโปรแกรมมาไม่ถึงปีแล้วและมีประสบการณ์ในการเขียนแอปพลิเคชันระบบเว็บแอพและสคริปต์สำหรับธุรกิจ / องค์กร อย่างไรก็ตามสิ่งหนึ่งที่ฉันไม่เคยทำมาก่อนคือทำงานกับกรอบอย่าง Django, Rails หรือ Zend เมื่อมองไปที่กรอบของ Django ฉันรู้สึกผิดหวังเล็กน้อยกับกรอบในใจ ฉันเข้าใจถึงเป้าหมายหลักของ DRY และโค้ดน้อยที่สุด แต่บางส่วนของการพึ่งพาโมดูลที่แตกต่างกันและสิ่งที่เป็นนามธรรมที่สำคัญของฟังก์ชั่นหลักรู้สึกว่ามัน: ทำให้โปรแกรมลงวันที่เร็วมากเนื่องจากลักษณะที่เปลี่ยนแปลงตลอดเวลาของโมดูล / กรอบงาน ทำให้โค้ดยากที่จะเข้าใจเนื่องจากมีกรอบและโมดูลที่พร้อมใช้งานและไอเดียของพวกเขาทั้งหมด ทำให้โค้ดน้อยลงยกเว้นว่าคุณอ่านเอกสารทั้งหมด; นั่นคือฉันสามารถอ่านรายการความเข้าใจและตรรกะตามเงื่อนไขและหาว่าโปรแกรมกำลังทำอะไร แต่เมื่อคุณเห็นฟังก์ชั่นที่ต้องการส่งผ่านสตริงและพจนานุกรมตามอำเภอใจ โมดูลที่กำหนด; และ: ทำให้การสลับระหว่างเฟรมเวิร์กเป็นเรื่องยากและน่าเบื่อ การสลับไปมาระหว่างภาษาเป็นเรื่องที่ท้าทายอยู่แล้ว แต่สามารถจัดการได้หากคุณมีความเข้าใจที่เพียงพอเกี่ยวกับฟังก์ชั่นหลัก / ปรัชญา การสลับระหว่างเฟรมเวิร์กดูเหมือนจะเป็นเรื่องของการท่องจำมากกว่าซึ่งในบางวิธีดูเหมือนจะส่งเสริมความไร้ประสิทธิภาพอย่างมากเฟรมเวิร์กเหล่านี้ถูกออกแบบมาเพื่อกำจัด เราจำเป็นต้องใส่สิ่งที่เป็นนามธรรมมากกว่า 50 เลเยอร์ไว้บนสิ่งที่เรียบง่ายเหมือนกับการสืบค้น MySQL หรือไม่? ทำไมไม่ใช้บางอย่างเช่นอินเทอร์เฟซ PDO ของ PHP ที่จัดการคำสั่ง / การทดสอบอินพุตที่เตรียมไว้ แต่เคียวรี …

24 web-development  python  frameworks  abstraction 

ฉันได้อ่านบทความจำนวนมากเมื่อเร็ว ๆ นี้ที่อธิบายครอบงำจิตใจดั้งเดิมเป็นกลิ่นรหัส มีประโยชน์สองประการในการหลีกเลี่ยงความหลงใหลดั้งเดิม: ทำให้โมเดลโดเมนชัดเจนยิ่งขึ้น ตัวอย่างเช่นฉันสามารถพูดคุยกับนักวิเคราะห์ธุรกิจเกี่ยวกับรหัสไปรษณีย์แทนที่จะเป็นสตริงที่มีรหัสไปรษณีย์ การตรวจสอบทั้งหมดอยู่ในที่เดียวแทนที่จะใช้ข้ามแอปพลิเคชัน มีบทความมากมายที่อธิบายเมื่อมันเป็นกลิ่นรหัส ตัวอย่างเช่นฉันสามารถเห็นประโยชน์ของการลบความหลงใหลดั้งเดิมสำหรับรหัสโพสต์เช่นนี้: public class Address { public ZipCode ZipCode { get; set; } } นี่คือตัวสร้างของรหัสไปรษณีย์: public ZipCode(string value) { // Perform regex matching to verify XXXXX or XXXXX-XXXX format _value = value; } คุณจะทำลายหลักการDRYโดยวางตรรกะการตรวจสอบความถูกต้องทุกที่ที่ใช้รหัสไปรษณีย์ อย่างไรก็ตามสิ่งที่เกี่ยวกับวัตถุต่อไปนี้: วันเดือนปีเกิด: ตรวจสอบว่ามากเกินใจและน้อยกว่าวันนี้วันที่ เงินเดือน: ตรวจสอบว่ามากกว่าหรือเท่ากับศูนย์ คุณจะสร้างวัตถุ DateOfBirth และวัตถุเงินเดือนหรือไม่ ประโยชน์คือคุณสามารถพูดคุยเกี่ยวกับพวกเขาเมื่ออธิบายรูปแบบโดเมน …

22 c#  domain-driven-design  domain-model  abstraction  modeling 

มีเหตุผลทางทฤษฎีบ้างไหม (เช่นว่าการตรวจสอบชนิดหรือการอนุมานประเภทจะไม่สามารถตัดสินใจได้) หรือเหตุผลเชิงปฏิบัติ (ยากเกินกว่าที่จะใช้อย่างถูกต้อง) ปัจจุบันเราสามารถห่อสิ่งต่างๆให้เป็นnewtypeเช่นนั้นได้ newtype Pair a = Pair (a, a) แล้วมี Pair :: * -> * λ(a:*). (a,a)แต่เราไม่สามารถทำสิ่งที่ชอบ (มีบางภาษาที่มีพวกเขาตัวอย่างเช่นScala ทำ )

22 haskell  abstraction  type-systems  lambda 

ฉันกำลังใช้บอต IRC ที่ได้รับข้อความและฉันกำลังตรวจสอบข้อความนั้นเพื่อพิจารณาว่าจะเรียกใช้ฟังก์ชันใด มีวิธีที่ฉลาดกว่านี้ในการทำเช่นนี้? ดูเหมือนว่ามันจะออกจากมือได้อย่างรวดเร็วหลังจากที่ฉันได้รับคำสั่งถึง 20 คำสั่ง บางทีอาจมีวิธีที่ดีกว่าที่จะสรุปสิ่งนี้ใช่ไหม public void onMessage(String channel, String sender, String login, String hostname, String message){ if (message.equalsIgnoreCase(".np")){ // TODO: Use Last.fm API to find the now playing } else if (message.toLowerCase().startsWith(".register")) { cmd.registerLastNick(channel, sender, message); } else if (message.toLowerCase().startsWith("give us a countdown")) { cmd.countdown(channel, message); …

20 java  design  abstraction 

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

19 object-oriented  inheritance  abstraction  liskov-substitution