คำถามติดแท็ก object-oriented

ฉันสนใจว่ารูปแบบ ActiveRecord สร้างชื่อเสียงจาก Ruby on Rails กระตุ้นหรือกีดกันการใช้หลักการออกแบบSOLID ตัวอย่างเช่นสำหรับฉันแล้ววัตถุ ActiveRecord นั้นมีทั้งตรรกะของโดเมนและตรรกะการคงอยู่ซึ่งเป็นการละเมิดความรับผิดชอบเดียว

43 object-oriented  ruby-on-rails 

ในรหัสดั้งเดิมบางครั้งฉันเห็นชั้นเรียนที่ไม่มีอะไรนอกจากห่อหุ้มข้อมูล สิ่งที่ต้องการ: class Bottle { int height; int diameter; Cap capType; getters/setters, maybe a constructor } ความเข้าใจของฉันเกี่ยวกับ OO คือคลาสเป็นโครงสร้างของข้อมูลและวิธีการทำงานกับข้อมูล ดูเหมือนว่าจะแยกประเภทของวัตถุนี้ สำหรับฉันพวกเขาไม่มีอะไรมากไปกว่าstructsและชนิดของความพ่ายแพ้วัตถุประสงค์ของ OO ฉันไม่คิดว่ามันจะเป็นสิ่งชั่วร้ายแม้ว่ามันอาจจะเป็นกลิ่นรหัส มีกรณีที่วัตถุดังกล่าวจะมีความจำเป็นหรือไม่? หากมีการใช้งานบ่อยมันจะทำให้ผู้ต้องสงสัยในการออกแบบหรือไม่

43 java  code-quality  object-oriented  code-smell 

ในภาษา OOP ส่วนใหญ่โดยทั่วไปวัตถุจะเปลี่ยนแปลงไม่ได้ด้วยชุดข้อยกเว้นที่ จำกัด (เช่น tuples และสตริงใน python) ในภาษาที่ใช้งานได้ส่วนใหญ่ข้อมูลจะไม่เปลี่ยนรูป วัตถุที่เปลี่ยนแปลงไม่ได้และไม่เปลี่ยนรูปแบบนำรายชื่อทั้งข้อดีและข้อเสียมาเอง มีภาษาที่พยายามจะแต่งงานกับแนวคิดทั้งสองอย่างเช่นสกาล่าที่คุณมีข้อมูลที่ไม่แน่นอนและไม่เปลี่ยนรูปแบบ (ประกาศอย่างชัดเจน) (โปรดแก้ไขให้ฉันถ้าฉันผิดฉันมีความรู้เรื่องสกาล่ามากกว่า จำกัด ) คำถามของฉันคือไม่สมบูรณ์ (! sic) เปลี่ยนไม่ -ie วัตถุที่ไม่สามารถกลายพันธุ์เมื่อมันได้รับ created- ทำให้รู้สึกใด ๆ ในบริบท OOP แล้ว? มีการออกแบบหรือการนำโมเดลดังกล่าวไปใช้หรือไม่? โดยพื้นฐานแล้วความไม่สามารถเปลี่ยนแปลงได้ (สมบูรณ์) และ OOP ตรงกันข้ามหรือมุมฉากหรือไม่? แรงจูงใจ: ใน OOP ปกติแล้วคุณจะดำเนินการกับข้อมูลการเปลี่ยนแปลง (การกลายพันธุ์) ข้อมูลพื้นฐานทำให้การอ้างอิงระหว่างวัตถุเหล่านั้น เช่นวัตถุของคลาสที่Personมีสมาชิกfatherอ้างอิงPersonวัตถุอื่น หากคุณเปลี่ยนชื่อพ่อสิ่งนี้จะปรากฏแก่วัตถุลูกทันทีโดยไม่จำเป็นต้องอัปเดต การไม่เปลี่ยนรูปคุณจะต้องสร้างวัตถุใหม่สำหรับทั้งพ่อและลูก แต่คุณจะมีข้อผิดพลาด kerfuffle น้อยลงมากเมื่อใช้วัตถุที่แชร์หลายเธรด GIL และอื่น ๆ

43 object-oriented  immutability 

เมื่อเวลาผ่านไปฉันสามารถเข้าใจสองส่วนของSOLID - "S" และ "O" “ O” - ฉันเรียนรู้หลักการแบบเปิดด้วยความช่วยเหลือของรูปแบบการสืบทอดและกลยุทธ์ “ S” - ฉันเรียนรู้หลักการความรับผิดชอบเดี่ยวขณะเรียนรู้ ORM (ตรรกะการคงอยู่ถูกพรากไปจากวัตถุโดเมน) ในทำนองเดียวกันภูมิภาค / ภารกิจที่ดีที่สุดในการเรียนรู้ส่วนอื่น ๆ ของ SOLID (“ L”,“ I” และ“ D”) คืออะไร? อ้างอิง msdn - อันตรายจากการละเมิดหลักการ SOLID ใน C # channel9 - การนำหลักการ SOLID ไปใช้ใน. NET / C # หลักการของ OOPS (หลักการที่เป็นของแข็ง)

43 object-oriented  solid 

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

43 design-patterns  object-oriented  mvc  repository 

ตามที่ครอบงำจิตใจดั้งเดิมคือเมื่อไม่ได้กลิ่นรหัส? ฉันควรสร้างวัตถุ ZipCode เพื่อแสดงรหัสไปรษณีย์แทนวัตถุ String อย่างไรก็ตามจากประสบการณ์ของฉันฉันชอบดู public class Address{ public String zipCode; } แทน public class Address{ public ZipCode zipCode; } เพราะฉันคิดว่าอันหลังต้องการให้ฉันย้ายไปที่คลาส ZipCode เพื่อทำความเข้าใจกับโปรแกรม และฉันเชื่อว่าฉันต้องย้ายระหว่างหลาย ๆ คลาสเพื่อดูคำจำกัดความถ้าทุกเขตข้อมูลดั้งเดิมถูกแทนที่ด้วยคลาสซึ่งรู้สึกราวกับว่าทุกข์ทรมานจากปัญหาโยโย่ (รูปแบบการต่อต้าน) ดังนั้นฉันต้องการย้ายวิธีการ ZipCode เป็นคลาสใหม่ตัวอย่างเช่น: เก่า: public class ZipCode{ public boolean validate(String zipCode){ } } ใหม่: public class ZipCodeHelper{ public static boolean validate(String zipCode){ …

42 object-oriented  coding-style 

ฉันเพิ่งออกแบบแอปพลิเคชันของฉันและฉันไม่แน่ใจว่าฉันเข้าใจ 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 

มีการจำแนกที่ชัดเจน แต่ง่ายและเข้าใจได้ของความแตกต่างระหว่าง "use case", "User Story" และ "ฉากการใช้งาน" หรือไม่? มีคำอธิบายมากมาย แต่ตอนนี้ฉันไม่เห็นใครอธิบายความแตกต่างในประโยคเดียวหรือสอง ... (เช่นhttp://c2.com/cgi-bin/wiki?UserStoryAndUseCaseComparisonนานและยากที่จะได้รับเต็มไปด้วยการอภิปราย)

42 agile  object-oriented 

คำถามนี้เป็นคำถามที่ค่อนข้างภาษาไม่เชื่อเรื่องพระเจ้า แต่ไม่สมบูรณ์ตั้งแต่โปรแกรมเชิงวัตถุ (OOP) อยู่ในที่แตกต่างกันเช่นJava , ซึ่งไม่ได้มีฟังก์ชั่นชั้นแรกมากกว่าที่เป็นอยู่ในหลาม กล่าวอีกนัยหนึ่งฉันรู้สึกผิดน้อยลงสำหรับการสร้างคลาสที่ไม่จำเป็นในภาษาเช่น Java แต่ฉันรู้สึกว่าอาจมีวิธีที่ดีกว่าในภาษาที่มีจำนวนต้นแบบน้อยลงเช่น Python โปรแกรมของฉันต้องทำการดำเนินการที่ค่อนข้างซับซ้อนหลายครั้ง การดำเนินการนั้นต้องใช้ "การบันทึกบัญชี" จำนวนมากต้องสร้างและลบไฟล์ชั่วคราวบางไฟล์ ฯลฯ นั่นเป็นเหตุผลที่มันยังต้องการเรียก "suboperations" อื่น ๆ อีกมากมาย - การใส่ทุกอย่างลงในวิธีการอันใหญ่โตนั้นไม่ได้ดีมากโมดุลอ่านได้ ฯลฯ ต่อไปนี้เป็นแนวทางที่อยู่ในใจของฉัน: 1. สร้างคลาสที่มีวิธีพับลิกเพียงวิธีเดียวเท่านั้นและรักษาสถานะภายในที่จำเป็นสำหรับการปฏิบัติการย่อยในตัวแปรอินสแตนซ์ มันจะมีลักษณะเช่นนี้: class Thing: def __init__(self, var1, var2): self.var1 = var1 self.var2 = var2 self.var3 = [] def the_public_method(self, param1, param2): self.var4 = param1 self.var5 …

40 object-oriented  python  object-oriented-design 

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

40 object-oriented  object-oriented-design  rest 

เมื่อทำการ Red, Green & Refactor cycle เราควรเขียนโค้ดขั้นต่ำเพื่อผ่านการทดสอบ นี่คือวิธีที่ฉันได้รับการสอนเกี่ยวกับ TDD และวิธีที่หนังสือเกือบทั้งหมดบรรยายกระบวนการ แต่สิ่งที่เกี่ยวกับการเข้าสู่ระบบ? จริงๆแล้วฉันไม่ค่อยได้ใช้การบันทึกในแอพพลิเคชั่นเว้นแต่มีบางสิ่งที่ซับซ้อนจริงๆที่เกิดขึ้นอย่างไรก็ตามฉันได้เห็นโพสต์มากมายที่พูดถึงความสำคัญของการบันทึกที่เหมาะสม ดังนั้นนอกเหนือจากการบันทึกข้อยกเว้นฉันไม่สามารถพิสูจน์ความสำคัญที่แท้จริงของการบันทึกในแอปพลิเคชันที่ผ่านการทดสอบที่เหมาะสม (การทดสอบหน่วย / การรวม / การยอมรับ) ดังนั้นคำถามของฉันคือ: เราจำเป็นต้องเข้าสู่ระบบหากเรากำลังทำ TDD อยู่หรือไม่? การทดสอบที่ล้มเหลวจะไม่เปิดเผยว่ามีอะไรผิดปกติกับแอปพลิเคชันหรือไม่ เราควรเพิ่มการทดสอบสำหรับกระบวนการบันทึกในแต่ละวิธีในแต่ละคลาสหรือไม่ หากระดับการบันทึกบางส่วนถูกปิดใช้งานในสภาพแวดล้อมการผลิตเช่นนั้นจะไม่แนะนำการพึ่งพาระหว่างการทดสอบและสภาพแวดล้อมหรือไม่? ผู้คนพูดถึงวิธีที่ง่ายในการดีบัก แต่หนึ่งในข้อดีหลักเกี่ยวกับ TDD คือฉันมักจะรู้ว่ามีอะไรผิดปกติเนื่องจากการทดสอบที่ล้มเหลว มีบางอย่างที่ฉันพลาดไปไหม

40 design  object-oriented  unit-testing  tdd  logging 

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

40 java  object-oriented  abstract-class 

โปรแกรม CS ของโรงเรียนของฉันหลีกเลี่ยงการกล่าวถึงการเขียนโปรแกรมเชิงวัตถุดังนั้นฉันจึงต้องอ่านด้วยตัวเองเพื่อเสริม - โดยเฉพาะการสร้างซอฟต์แวร์เชิงวัตถุโดย Bertrand Meyer เมเยอร์ชี้ให้เห็นซ้ำ ๆ ว่าคลาสควรซ่อนข้อมูลเกี่ยวกับการนำไปปฏิบัติให้มากที่สุดเท่าที่จะทำได้ โดยเฉพาะเขาให้เหตุผลซ้ำ ๆ ว่าแอตทริบิวต์ (เช่นคุณสมบัติแบบคงที่และไม่คำนวณของคลาส) และรูทีน (คุณสมบัติของคลาสที่สอดคล้องกับการเรียกใช้ฟังก์ชัน / โพรซีเดอร์) ไม่สามารถแยกกันได้ ตัวอย่างเช่นถ้าคลาสPersonมีคุณสมบัติageเขายืนยันว่ามันเป็นไปไม่ได้ที่จะบอกจากสัญลักษณ์ไม่ว่าจะPerson.ageสอดคล้องภายในกับสิ่งที่ชอบreturn current_year - self.birth_dateหรือเรียบง่ายreturn self.ageที่self.ageได้รับการกำหนดเป็นแอตทริบิวต์คงที่ เรื่องนี้ทำให้รู้สึกถึงฉัน อย่างไรก็ตามเขายังคงเรียกร้องต่อไปนี้: เอกสารไคลเอนต์มาตรฐานสำหรับคลาสที่เรียกว่ารูปแบบสั้น ๆ ของคลาสจะถูกคิดขึ้นใหม่เพื่อไม่ให้เปิดเผยว่าคุณลักษณะที่กำหนดเป็นคุณลักษณะหรือฟังก์ชัน (ในกรณีที่อาจเป็นได้) กล่าวคือเขาอ้างว่าแม้แต่เอกสารสำหรับชั้นเรียนควรหลีกเลี่ยงการระบุว่า "ผู้เอา" ทำการคำนวณใด ๆ นี่ฉันไม่ทำตาม เอกสารไม่ใช่ที่เดียวที่ควรแจ้งให้ผู้ใช้ทราบถึงความแตกต่างนี้หรือไม่ ถ้าฉันต้องออกแบบฐานข้อมูลที่เต็มไปด้วยPersonวัตถุมันจะไม่สำคัญที่จะรู้ว่าPerson.ageการโทรที่มีราคาแพงหรือไม่ดังนั้นฉันจึงสามารถตัดสินใจได้ว่าจะใช้แคชบางประเภทหรือไม่ ฉันเข้าใจผิดในสิ่งที่เขาพูดหรือเขาเป็นเพียงตัวอย่างที่ยอดเยี่ยมที่สุดของปรัชญาการออกแบบ OOP หรือไม่?

39 design  object-oriented  documentation  performance 

ฉันสับสนเกี่ยวกับสัญลักษณ์บางอย่างของแผนภาพคลาส UML ค่อนข้างแน่ใจว่าฉันรู้ว่าสมาคมหมายถึงอะไร ความสัมพันธ์ระหว่างอินสแตนซ์ของสองคลาสที่อินสแตนซ์ของคลาสหนึ่งจำเป็นต้องทราบเกี่ยวกับอินสแตนซ์ของคลาสที่สองเพื่อที่จะทำงานได้ - เป็นความสัมพันธ์ของสมาคม สมาคมมักหมายถึงคลาส A มีการอ้างอิง (ฟิลด์) กับอินสแตนซ์ของคลาส B อย่างไรก็ตามฉันมีปัญหาในการทำความเข้าใจว่าลูกศรการรวมและการจัดองค์ประกอบหมายถึงอะไร ความสับสนส่วนหนึ่งของฉันเกิดจากการเผชิญหน้ากับคำจำกัดความต่าง ๆ ของสัญลักษณ์เหล่านี้ คำจำกัดความสองประการของสัญลักษณ์การรวม : คำจำกัดความที่ 1:สัญกรณ์การรวมตัวระหว่างสองคลาสนั้นเหมาะสมเมื่อใดก็ตามที่อินสแตนซ์ของคลาส A เก็บชุดอินสแตนซ์ของคลาส B (เช่น List, Array หรืออะไรก็ตาม) คำจำกัดความที่ 2:ลิงค์รวมระหว่างสองคลาสนั้นเหมาะสมถ้าอินสแตนซ์ของคลาส A มีการอ้างอิงถึงอินสแตนซ์ของคลาส B และอินสแตนซ์ B นั้นขึ้นอยู่กับวงจรชีวิตของอินสแตนซ์ A ความหมาย: เมื่ออินสแตนซ์ของคลาส A ถูกลบดังนั้นอินสแตนซ์ของคลาส B อินสแตนซ์ของคลาส B จะมีอยู่ทั้งหมดโดยอินสแตนซ์ของคลาส A ซึ่งตรงข้ามกับอินสแตนซ์ของคลาส A เพียงเป็นเจ้าของการอ้างอิงถึงอินสแตนซ์ของ คลาส B …

39 object-oriented  uml  class-diagram