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

ปิด คำถามนี้จะต้องมีมากขึ้นมุ่งเน้น ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้มุ่งเน้นที่ปัญหาเดียวโดยแก้ไขโพสต์นี้ ปิดให้บริการใน4 ปีที่แล้ว เนื่องจากภาษาเครื่อง (เช่น0110101000110101) ภาษาคอมพิวเตอร์มีวิวัฒนาการโดยทั่วไปในรูปแบบที่เป็นนามธรรมสูงกว่าโดยทั่วไปทำให้ง่ายต่อการเข้าใจรหัสเมื่อมันถูกนำไปใช้กับปัญหา แอสเซมเบลอร์เป็นนามธรรมผ่านรหัสเครื่อง C เป็นนามธรรมเหนือแอสเซมเบลอร์ ฯลฯ การออกแบบเชิงวัตถุดูเหมือนว่าจะดีมากที่ช่วยให้เราสามารถจำลองปัญหาในแง่ของวัตถุเช่นปัญหาของระบบการลงทะเบียนหลักสูตรมหาวิทยาลัยสามารถทำแบบจำลองกับCourseชั้นStudentเรียนคลาส ฯลฯ จากนั้นเมื่อเราเขียนวิธีการแก้ปัญหา ในภาษา OO เรามีคลาสที่คล้ายกันซึ่งได้รับความรับผิดชอบและโดยทั่วไปมีประโยชน์สำหรับการออกแบบโดยเฉพาะอย่างยิ่งสำหรับการทำให้โค้ดเป็นโมดูล ถ้าฉันให้ปัญหานี้แก่ทีมอิสระ 10 คนที่แก้ปัญหาด้วยวิธี OO โดยทั่วไป 10 วิธีแก้ปัญหาจะมีชั้นเรียนที่เกี่ยวข้องกับปัญหาที่เหมือนกัน อาจมีความแตกต่างมากมายเมื่อคุณเริ่มมีเพศสัมพันธ์และการโต้ตอบของคลาสเหล่านั้นดังนั้นจึงไม่มีสิ่งเช่น "ศูนย์ช่องว่างการเป็นตัวแทน" ประสบการณ์การใช้งานฟังก์ชั่นการเขียนโปรแกรมของฉันมี จำกัด มาก (ไม่มีการใช้งานจริงในโลกมีเพียงโปรแกรมประเภท Hello World) ฉันล้มเหลวในการดูว่าภาษาดังกล่าวอนุญาตให้ทำแผนที่โซลูชั่น FP ได้อย่างง่ายดายเพื่อแก้ไขปัญหา (ด้วยช่องว่างที่เป็นตัวแทนต่ำ) ในแบบที่ภาษา OO ทำอย่างไร ฉันเข้าใจถึงข้อดีของ FP ที่เกี่ยวกับการเขียนโปรแกรมพร้อมกัน แต่ฉันขาดอะไรไปหรือ FP ไม่ได้ลดช่องว่างในการเป็นตัวแทน (ทำให้การแก้ปัญหาเข้าใจง่ายขึ้น)? อีกวิธีที่จะถามสิ่งนี้: …

18 object-oriented  object-oriented-design  functional-programming  abstraction 

ฉันสะดุดกับคำพูดของเกร็กยัง7 เหตุผลที่โครงการ DDD ล้มเหลวซึ่งเขาพูดถึงบางสิ่งที่เขาเรียกว่า DDD-Lite เวลา 7:20 โดยสรุปเขากล่าวโดยทั่วไปว่าบางคนใช้ DDD เป็นภาษารูปแบบ (เอนทิตี, ที่เก็บ, อ็อบเจ็กต์ค่า, การบริการและอื่น ๆ ) โดยไม่ต้องทำสิ่งอื่นใดที่เกี่ยวข้องกับ DDD เขาอ้างถึงโดเมนแบบจำลอง 60% ขึ้นไปใน. Net คือ DDD-Lite เขาคิดว่า DDD-Lite นั้นกำลังสร้างภาษาเกี่ยวกับการฉีดพึ่งพาซึ่งเป็นสิ่งที่คุณไม่จำเป็นต้องทำ เขาบอกว่าทำ DDD ทั้งหมดหรือทำสิ่งที่ง่ายกว่า ไม่อย่างนั้นเขาก็อ้างว่าคน ๆ หนึ่งกำลังนำผลงานทั้งหมดนี้มาสร้างนามธรรมที่ดี แต่ไม่มีผลประโยชน์ที่แท้จริง ฉันต้องยอมรับว่าฉันไม่รู้จัก DDD มากเท่าที่ฉันต้องการและยังไม่ได้ลองใช้ ฉันยังไม่ได้อ่านหนังสือของ Eric Evan เช่นกัน ฉันกำลังมากขึ้นที่สนใจในการพึ่งพาการฉีดและหลายหนังสือหลายเล่มและบล็อกในแง่นี้การใช้งานภายใต้แนวความคิดและการอ้างอิงจากเอริคอีแวนส์หนังสือ DDD นี่คือที่ฉันได้สัมผัสกับแนวคิด DDD หนังสือที่ฉันอ่านมาเล่มนี้ประกอบด้วย: การพึ่งพาการฉีดใน. NET Microsoft .Net: …

17 .net  dependency-injection  domain-driven-design  abstraction 

ฉันพยายามที่จะเข้าใจความหมายของ 'abstraction' ใน OOP ฉันได้เจอคำจำกัดความหลักสองสามข้อ พวกเขาทั้งหมดถูกต้องหรือไม่ เป็นหนึ่งในพวกเขาผิดหรือเปล่า? ฉันสับสน (ฉันเขียนคำจำกัดความใหม่ด้วยคำพูดของตัวเอง) คำจำกัดความ 1: สิ่งที่เป็นนามธรรมเป็นแนวคิดของการหยิบวัตถุบางอย่างจากโลกแห่งความเป็นจริงและแปลงเป็นเงื่อนไขการเขียนโปรแกรม เช่นการสร้างHumanการเรียนและให้มันint health, int age, String nameฯลฯ คุณสมบัติและeat()วิธีการอื่น ๆ คำจำกัดความ 2: คำจำกัดความทั่วไปมากขึ้น Abstraction เป็นแนวคิดที่เกิดขึ้นได้ทุกที่ในระบบซอฟต์แวร์ที่เกี่ยวข้องกับ'การทำให้สิ่งต่าง ๆเป็นเรื่องธรรมดา/ ง่ายขึ้น / เป็นนามธรรม' ตัวอย่างบางส่วน: ลำดับชั้นการสืบทอดที่คลาสที่สูงกว่าง่ายกว่าหรือทั่วไปกว่าและกำหนดการใช้งานทั่วไปและนามธรรมมากขึ้น ในขณะที่คลาสที่ต่ำกว่าในลำดับชั้นนั้นเป็นรูปธรรมมากขึ้นและกำหนดการใช้งานที่มีรายละเอียดมากขึ้น การใช้การห่อหุ้มเพื่อซ่อนรายละเอียดของการใช้คลาสจากคลาสอื่น ๆ จึงทำให้คลาส 'นามธรรม' (ง่ายกว่า) สู่โลกของซอฟต์แวร์ภายนอก คำจำกัดความ 3 นิยามทั่วไปอีกประการหนึ่ง: Abstraction เป็นแนวคิดของการย้ายโฟกัสจากรายละเอียดและการใช้สิ่งต่าง ๆ อย่างเป็นรูปธรรมกับประเภทของสิ่งต่าง ๆ (เช่นคลาส) การดำเนินการที่มีอยู่ (เช่นวิธีการ) ฯลฯ …

16 object-oriented  abstraction 

วันนี้ฉันได้มีการถกเถียงกันอย่างดุเดือดกับนักพัฒนาคนอื่นในองค์กรของฉันเกี่ยวกับสถานที่และวิธีการเพิ่มวิธีในคลาสที่แมปฐานข้อมูล เราใช้sqlalchemyและส่วนสำคัญของฐานรหัสที่มีอยู่ในโมเดลฐานข้อมูลของเรานั้นเป็นเพียงเล็กน้อยของคุณสมบัติที่แมปด้วยชื่อคลาสการแปลเชิงกลจากตารางฐานข้อมูลไปยังวัตถุหลาม ในการโต้แย้งตำแหน่งของฉันคือว่าค่าหลักของการใช้ ORM คือคุณสามารถแนบพฤติกรรมและอัลกอริทึมในระดับต่ำกับคลาสที่แมป โมเดลเป็นคลาสแรกและถาวรเป็นอันดับที่สอง (อาจคงอยู่โดยใช้ xml ในระบบไฟล์คุณไม่จำเป็นต้องสนใจ) มุมมองของเขาคือพฤติกรรมใด ๆ ที่เป็น "ตรรกะทางธุรกิจ" และจำเป็นต้องเป็นของทุกที่ แต่ในรูปแบบถาวรซึ่งจะใช้สำหรับการคงอยู่ของฐานข้อมูลเท่านั้น ฉันคิดว่าแน่นอนว่ามีความแตกต่างระหว่างตรรกะทางธุรกิจคืออะไรและควรแยกออกจากกันเนื่องจากมีการแยกจากระดับล่างของวิธีการใช้งานและตรรกะโดเมนซึ่งฉันเชื่อว่าเป็นนามธรรมที่จัดทำโดยคลาสโมเดล เป็นที่ถกเถียงกันในย่อหน้าก่อนหน้า แต่ฉันมีเวลายากที่จะวางนิ้วลงบนสิ่งที่เป็น ฉันมีความรู้สึกที่ดีขึ้นเกี่ยวกับสิ่งที่อาจเป็น API (ซึ่งในกรณีของเราคือ HTTP "ReSTful") ผู้ใช้จะเรียกใช้ API กับสิ่งที่พวกเขาต้องการทำแตกต่างจากสิ่งที่พวกเขาได้รับอนุญาตให้ทำ เสร็จแล้ว tl; dr: ประเภทใดที่สามารถหรือควรไปในวิธีการในคลาสที่แมปเมื่อใช้ ORM และสิ่งที่ควรจะออกไปอยู่ในอีกชั้นหนึ่งของสิ่งที่เป็นนามธรรม?

16 orm  abstraction  business-logic 

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

15 programming-practices  abstraction  strategy  low-level  high-level 

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

15 programming-languages  object-oriented  language-agnostic  abstraction 

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

15 programming-languages  hardware  abstraction  industry  computer-architecture 

คำว่า "wrapper" และ "shim" มีความหมายเหมือนกันมากหรือน้อยหรือมีความแตกต่างซึ่งอาจเป็นความหมายแฝง

15 abstraction  terminology 

ก่อนอื่นฉันเป็นโปรแกรมเมอร์ระดับต้น ในความเป็นจริงฉันกำลังจบระดับ AS ด้วยโปรเจ็กต์สุดท้ายของฤดูร้อน ในงานใหม่ของฉันเมื่อไม่มีโครงการให้ฉันทำ (พวกเขากำลังรอที่จะเติมทีมด้วยการจ้างงานใหม่) ฉันได้รับหนังสือให้อ่านและเรียนรู้จากในขณะที่ฉันรอ - ตำราบางเล่มอื่น ๆ ไม่มาก (เช่น Code Complete) หลังจากอ่านหนังสือเหล่านี้ฉันได้หันไปใช้อินเทอร์เน็ตเพื่อเรียนรู้ให้มากที่สุดและเริ่มเรียนรู้เกี่ยวกับ SOLID และ DI (เราได้พูดถึงหลักการทดแทนของ Liskov แต่ไม่ได้มีแนวคิด SOLID อื่น) เพื่อที่ฉันจะได้เรียนรู้ฉันนั่งลงเพื่อเรียนรู้ให้ดีขึ้นและเริ่มเขียนโค้ดเพื่อใช้ DI ด้วยมือ (ไม่มีกรอบ DI บนคอมพิวเตอร์การพัฒนา) สิ่งที่ฉันทำมันฉันสังเกตเห็นว่ามันรู้สึกคุ้นเคย ... และดูเหมือนว่ามันเป็นเหมือนงานที่ฉันเคยทำในอดีตโดยใช้องค์ประกอบของคลาสนามธรรมโดยใช้ polymorphism ฉันคิดถึงภาพที่ใหญ่กว่านี้หรือไม่? มีบางอย่างเกี่ยวกับ DI (อย่างน้อยด้วยมือ) ที่ไปได้หรือไม่? ฉันเข้าใจถึงความเป็นไปได้ของการกำหนดค่าที่ไม่ได้อยู่ในรหัสของกรอบงาน DI บางอันที่มีประโยชน์มากพอ ๆ กับการเปลี่ยนแปลงสิ่งต่าง ๆ โดยไม่ต้องคอมไพล์ใหม่ แต่เมื่อทำด้วยมือฉันไม่แน่ใจว่ามันแตกต่างจากที่ระบุข้างต้น ... ข้อมูลเชิงลึกเกี่ยวกับเรื่องนี้จะมีประโยชน์มาก!

13 dependency-injection  abstraction  polymorphism  composition 

ฉันมีวิธีการอินเทอร์เฟซที่ระบุไว้ในเอกสารมันจะโยนประเภทของข้อยกเว้นเฉพาะ การใช้วิธีการนั้นใช้สิ่งที่ส่งข้อยกเว้น มีการตรวจสอบข้อยกเว้นภายในและข้อยกเว้นที่ประกาศโดยสัญญาส่วนต่อประสาน นี่คือตัวอย่างรหัสเล็กน้อยที่จะอธิบายได้ดีขึ้น มันเขียนใน PHP แต่ค่อนข้างง่ายที่จะติดตาม // in the interface /** * @return This method returns a doohickey to use when you need to foo * @throws DoohickeyDisasterException */ public function getThatDoohickey(); // in the implementation public function getThatDoohickey() { try { $SomethingInTheClass->doSomethingThatThrowsAnException(); } catch (Exception $Exc) { throw …

12 exceptions  abstraction 

นี่เป็นคำถามที่ค่อนข้างคลุมเครือ แต่เป็นสิ่งที่ฉันไม่เคยรู้สึกว่าได้รับคำตอบอย่างน่าพอใจเมื่ออ่านเกี่ยวกับการออกแบบที่เหมาะสม โดยทั่วไปเมื่อเรียนรู้เกี่ยวกับการเขียนโปรแกรมเชิงวัตถุ, นามธรรม, แยกตัวประกอบ ฯลฯ จอกศักดิ์สิทธิ์ของการออกแบบ - และเหตุผลที่พวกเขาอ้างเสมอว่าคุณใช้เทคนิคการพัฒนาที่เป็นปัญหา - คือมันจะทำให้โปรแกรมของคุณ "ง่ายต่อการเปลี่ยนแปลง" , "maintainable", "ยืดหยุ่น" หรือคำพ้องความหมายใด ๆ ที่ใช้เพื่อแสดงแนวคิดเกี่ยวกับการผลิตที่ทำให้เกิดเสียงดังกล่าว ด้วยการทำเครื่องหมายส่วนตัวของ ivars ให้แยกรหัสออกเป็นวิธีเล็ก ๆ ที่มีอยู่ในตัวเองทำให้อินเตอร์เฟสทั่วไปทำให้คุณสามารถปรับเปลี่ยนโปรแกรมของคุณได้อย่างง่ายดาย สำหรับการเปลี่ยนแปลงที่ค่อนข้างเล็กสิ่งนี้ใช้ได้ดีสำหรับฉัน การเปลี่ยนแปลงโครงสร้างข้อมูลภายในที่ใช้โดยคลาสเพื่อเพิ่มประสิทธิภาพไม่เคยมีความยุ่งยากที่สำคัญและไม่มีการเปลี่ยนแปลงส่วนท้ายของส่วนต่อประสานผู้ใช้ที่เป็นอิสระจาก API เช่นการออกแบบระบบป้อนข้อความใหม่หรือปรับปรุงกราฟิกสำหรับองค์ประกอบการเล่นเกม . การเปลี่ยนแปลงทั้งหมดเหล่านี้ดูเหมือนมีอยู่ในตัวเองโดยเนื้อแท้ ไม่มีสิ่งใดที่เกี่ยวข้องกับการเปลี่ยนแปลงพฤติกรรมหรือการออกแบบองค์ประกอบของโปรแกรมของคุณที่ได้รับการแก้ไขตราบใดที่รหัสภายนอกเกี่ยวข้อง ไม่ว่าคุณจะเขียนขั้นตอนหรือในสไตล์ OO ที่มีฟังก์ชั่นขนาดใหญ่หรือขนาดเล็กการเปลี่ยนแปลงเหล่านี้ง่ายต่อการเปลี่ยนแปลงแม้ว่าคุณจะมีการออกแบบที่ดีพอสมควรก็ตาม อย่างไรก็ตามเมื่อใดก็ตามที่การเปลี่ยนแปลงมีขนาดใหญ่และมีขนฟูนั่นคือการเปลี่ยนแปลง API - ไม่มีรูปแบบ "อันมีค่า" ของฉันเลยที่จะช่วยเหลือ การเปลี่ยนแปลงครั้งใหญ่ยังคงใหญ่รหัสที่ได้รับผลกระทบยังคงได้รับผลกระทบและงานการวางไข่หลายชั่วโมงอยู่ข้างหน้าฉัน ดังนั้นคำถามของฉันคือสิ่งนี้ การออกแบบที่เหมาะสมนั้นมีการเปลี่ยนแปลงขนาดใหญ่เพียงใดเพื่อให้สามารถอำนวยความสะดวกได้? มีเทคนิคการออกแบบเพิ่มเติมบางอย่างไม่เป็นที่รู้จักสำหรับฉันหรือฉันล้มเหลวในการใช้งานที่ทำให้การปรับเปลี่ยนที่ทำให้เกิดเสียงง่าย ๆ หรือเป็นสัญญานั้น (ซึ่งฉันได้ยินจากกระบวนทัศน์ที่แตกต่างกันมากมาย) เป็นแนวคิดที่ดี ตัดการเชื่อมต่ออย่างสมบูรณ์จากความจริงที่ไม่เปลี่ยนรูปแบบของการพัฒนาซอฟต์แวร์? มี "เครื่องมือเปลี่ยน" …

11 design  object-oriented  maintenance  abstraction  changes 

ฉันได้ยินวลีที่ถูกโยนและฉันมีข้อโต้แย้งที่ฟังดูบ้าอย่างสมบูรณ์ (ขออภัยถ้าฉันกำลังทำฟางอยู่ที่นี่ไม่ใช่ความตั้งใจของฉัน) โดยทั่วไปจะมีบางอย่างตาม: คุณไม่ต้องการสร้างสิ่งที่เป็นนามธรรมก่อนที่คุณจะรู้ว่ากรณีทั่วไปคืออะไรมิฉะนั้น (1) คุณอาจวางสิ่งต่าง ๆ ในสิ่งที่เป็นนามธรรมของคุณหรือ (2) ไม่สนใจสิ่งที่มีความสำคัญ (1) สำหรับฉันนี่ดูเหมือนว่าโปรแกรมเมอร์ไม่ได้ใช้งานได้จริงพวกเขาได้ตั้งสมมติฐานว่าสิ่งต่าง ๆ จะมีอยู่ในโปรแกรมสุดท้ายที่ไม่ได้ทำงานดังนั้นพวกเขาจึงทำงานร่วมกับสิ่งที่เป็นนามธรรมในระดับต่ำปัญหาไม่ใช่ สิ่งที่เป็นนามธรรมก่อนวัยอันควร (2) การทิ้งสิ่งที่มีความสำคัญเป็นสิ่งหนึ่งอาจเป็นไปได้อย่างสิ้นเชิงที่บางสิ่งจะถูกตัดออกจากข้อมูลจำเพาะที่ในภายหลังกลายเป็นเรื่องสำคัญทางออกสำหรับสิ่งนี้ไม่ได้เกิดขึ้นกับการตัดสินใจของคุณและทรัพยากรเสียเปล่า เดาผิดก็เพื่อให้ได้ข้อมูลเพิ่มเติมจากลูกค้า เราควรทำงานจากนามธรรมลงไปถึงข้อตกลงเพราะนี่เป็นวิธีที่จริงจังที่สุดในการทำสิ่งต่าง ๆ และไม่ใช่วิธีอื่น ๆ ถ้าเราไม่ทำเช่นนั้นเราก็เสี่ยงต่อการเข้าใจผิดของลูกค้าและการสร้างสิ่งต่าง ๆ ที่จำเป็นต้องเปลี่ยน แต่ถ้าเราสร้างเพียงนามธรรมที่ลูกค้าได้กำหนดไว้ในภาษาของพวกเขาเองเราก็ไม่เคยตกอยู่ในความเสี่ยงนี้ ภาพหนึ่งในที่มืดโดยมีการสรุปบางอย่าง) ใช่เป็นไปได้ที่ลูกค้าจะเปลี่ยนใจเกี่ยวกับรายละเอียด แต่สิ่งที่พวกเขาเคยใช้ในการสื่อสารสิ่งที่พวกเขาต้องการมักจะยังคงใช้ได้ ต่อไปนี้เป็นตัวอย่างสมมติว่าลูกค้าต้องการให้คุณสร้างหุ่นยนต์ที่บรรจุถุง: public abstract class BaggingRobot() { private Collection<Item> items; public abstract void bag(Item item); } เรากำลังสร้างบางสิ่งจากนามธรรมที่ลูกค้าใช้โดยไม่ต้องลงรายละเอียดเพิ่มเติมกับสิ่งที่เราไม่รู้ นี่คือความยืดหยุ่นอย่างยิ่งฉันเห็นสิ่งนี้ถูกเรียกว่า "นามธรรมก่อนวัยอันควร" เมื่อในความเป็นจริงมันจะเร็วกว่าที่จะคิดว่าวิธีการบรรจุถุงถูกนำไปใช้อย่างไรพูดหลังจากพูดคุยกับลูกค้าที่พวกเขาต้องการ . เพื่ออัปเดตชั้นเรียนของฉันทั้งหมดที่ฉันต้องทำคือเปลี่ยนลายเซ็น …

10 design  design-patterns  object-oriented-design  development-process  abstraction 

เมื่อเขียนการสร้างหน้าใน PHP ฉันมักจะพบว่าตัวเองกำลังเขียนไฟล์ที่เกลื่อนไปด้วยแบบสอบถามฐานข้อมูล ตัวอย่างเช่นฉันอาจมีแบบสอบถามเพื่อดึงข้อมูลบางอย่างเกี่ยวกับการโพสต์โดยตรงจากฐานข้อมูลเพื่อแสดงบนหน้าเช่นนี้: $statement = $db->prepare('SELECT * FROM posts WHERE id=:id'); $statement->bindValue(':id', $id, PDO::PARAM_INT); $statement->execute(); $post = $statement->fetch(PDO::FETCH_ASSOC); $content = $post['content'] // do something with the content ข้อความค้นหาแบบครั้งเดียวที่รวดเร็วเหล่านี้มักจะเล็ก แต่บางครั้งฉันก็ลงท้ายด้วยรหัสการโต้ตอบของฐานข้อมูลขนาดใหญ่ซึ่งเริ่มดูยุ่งเหยิง ในบางกรณีฉันได้แก้ไขปัญหานี้ด้วยการสร้างไลบรารีฟังก์ชันที่ใช้งานง่ายเพื่อจัดการคิวรี db ที่เกี่ยวข้องกับการโพสต์ของฉันทำให้บล็อกโค้ดนั้นสั้นลงง่ายๆ $content = post_get_content($id); และนั่นก็ยอดเยี่ยม หรืออย่างน้อยก็จนกว่าฉันจะต้องทำอย่างอื่น บางทีฉันอาจต้องได้รับห้าโพสต์ล่าสุดเพื่อแสดงในรายการ ฉันสามารถเพิ่มฟังก์ชั่นอื่นได้เสมอ: $recent_posts = post_get_recent(5); foreach ($recent_posts as $post) { ... } …

10 php  database  sql  abstraction 

ฉันประสบปัญหากับสิ่งที่ฉันรู้สึกว่าเป็นนามธรรมมากเกินไปในรหัสฐาน (หรืออย่างน้อยก็จัดการกับมัน) เมธอดส่วนใหญ่ในฐานรหัสได้รับการสรุปให้ใช้ในพาเรนต์สูงสุด A ในโค้ดเบส แต่ลูก B ของพาเรนต์นี้มีแอ็ตทริบิวต์ใหม่ที่มีผลต่อตรรกะของบางเมธอดเหล่านั้น ปัญหาคือไม่สามารถตรวจสอบแอตทริบิวต์เหล่านั้นในวิธีการเหล่านั้นได้เนื่องจากอินพุตนั้นถูกส่งไปยัง A และแน่นอนว่า A ไม่มีคุณสมบัตินี้ ถ้าฉันพยายามสร้างวิธีการใหม่เพื่อจัดการ B ที่แตกต่างกันมันจะถูกเรียกใช้สำหรับการทำสำเนารหัส คำแนะนำโดยผู้นำด้านเทคนิคของฉันคือการสร้างวิธีการที่ใช้ร่วมกันซึ่งใช้ในพารามิเตอร์บูลีน แต่ปัญหาของเรื่องนี้คือบางคนมองว่านี่เป็น "การควบคุมการไหลที่ซ่อนอยู่" ซึ่งวิธีการแบ่งปันมีตรรกะที่อาจไม่ชัดเจนสำหรับนักพัฒนาในอนาคต , และวิธีการที่ใช้ร่วมกันนี้จะเพิ่มความซับซ้อน / ซับซ้อนมากขึ้นหากจำเป็นต้องเพิ่มแอตทริบิวต์ในอนาคตแม้ว่าจะถูกแยกย่อยเป็นวิธีที่ใช้ร่วมกันที่มีขนาดเล็กลง สิ่งนี้ยังเพิ่มการแต่งงานลดการทำงานร่วมกันและละเมิดหลักการความรับผิดชอบเดียวซึ่งมีคนในทีมของฉันชี้ให้เห็น โดยพื้นฐานแล้วสิ่งที่เป็นนามธรรมจำนวนมากใน codebase นี้ช่วยลดความซ้ำซ้อนของรหัส แต่มันทำให้การขยาย / เปลี่ยนวิธีที่ยากขึ้นเมื่อพวกเขาถูกทำให้เป็นนามธรรมที่สูงที่สุด ฉันควรทำอย่างไรในสถานการณ์เช่นนี้ ฉันอยู่ที่ศูนย์กลางของการตำหนิแม้ว่าคนอื่น ๆ จะไม่เห็นด้วยกับสิ่งที่พวกเขาคิดว่าดี แต่มันก็ทำให้ฉันเจ็บในที่สุด

9 object-oriented-design  class-design  abstraction  code-reuse  dry 

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

9 object-oriented  programming-practices  interfaces  abstraction