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

ฉันมักจะเผชิญหน้ากับผู้ช่วยหรือใช้คลาสใน Java หรือภาษาอะไรก็ได้ ดังนั้นฉันจึงถามตัวเองว่านี่เป็น Anti Pattern หรือไม่และการมีอยู่ของคลาสเหล่านี้เป็นเพียงการขาดการออกแบบและสถาปัตยกรรมของซอฟต์แวร์ บ่อยครั้งที่คลาสเหล่านี้ถูก จำกัด ด้วยวิธีการคงที่ซึ่งทำสิ่งต่างๆมากมาย แต่ส่วนใหญ่มันแน่นอนขึ้นอยู่กับบริบทและรัฐเต็ม คำถามของฉันคืออะไรความคิดเห็นของคุณเกี่ยวกับประเภทของผู้ช่วยคงที่ / ใช้ประโยชน์เช่นชั้นเรียนเพราะข้อได้เปรียบแน่นอนว่าการร้องขออย่างรวดเร็วโดยใช้เพียงชื่อชั้นเรียน แล้วคุณจะหลีกเลี่ยงการใช้คลาสประเภทนี้ในระดับใด ในความคิดของฉันคำหลัก "คงที่" ควรได้รับอนุญาตภายในการประกาศของคลาส (Java) และไม่ได้สำหรับวิธีการ ในความคิดของฉันคือการใช้วิธีนี้อาจเป็นทางเลือกที่ดีและตรงกลางเพื่อให้สามารถรวม Procuedural- และ OO-Paradigms ใน Java และหลีกเลี่ยงการใช้คำหลักที่ผิดพลาด เพิ่มเติมเนื่องจากคำตอบ: ตอนแรกฉันคิดว่ามันถูกกฎหมายอย่างสมบูรณ์เพื่อให้สามารถรวมกระบวนทัศน์ที่แตกต่างกันและแม้กระทั่งใช้ภาษาสคริปต์ตีความตีความรันไทม์ภายในเครื่องหรือรหัสที่รวบรวม vm ประสบการณ์ของฉันคือระหว่างกระบวนการพัฒนาโครงการผู้ช่วยเหลือและสิ่งของประเภทนั้นหรืออะไรก็ตามที่ชื่อกำลังเติบโตและเติบโตและใช้ในทุกมุมที่ลืมของ codebase ซึ่ง แต่เดิมได้รับการออกแบบให้เป็นแบบแยกส่วนและยืดหยุ่น และเนื่องจากไม่มีเวลาที่จะทำการปรับโครงสร้างใหม่หรือคิดเกี่ยวกับการออกแบบอีกครั้งคุณเพียงแค่ทำให้มันแย่ลงในช่วงเวลานั้น ฉันคิดว่าstaticควรถูกลบออกจาก Java โดยเฉพาะอย่างยิ่งตอนนี้ที่เป็นไปได้ที่จะใช้องค์ประกอบภาษาที่ซับซ้อนยิ่งขึ้น

19 design-patterns  anti-patterns  static 

เมื่อเร็ว ๆ นี้ฉันเริ่มเขียนโปรแกรมใน Groovy สำหรับกรอบการทดสอบการรวมสำหรับโครงการ Java ฉันใช้ Intellij IDEA กับปลั๊กอิน Groovy และฉันรู้สึกประหลาดใจที่เห็นว่าเป็นคำเตือนสำหรับวิธีการทั้งหมดที่ไม่คงที่และไม่ต้องพึ่งพาฟิลด์อินสแตนซ์ใด ๆ ใน Java อย่างไรก็ตามนี่ไม่ใช่ปัญหา (อย่างน้อยจากมุมมองของ IDE) วิธีการทั้งหมดที่ไม่ได้ขึ้นอยู่กับเขตข้อมูลอินสแตนซ์ใด ๆ ควรถูกเปลี่ยนเป็นฟังก์ชันแบบคงที่หรือไม่? ถ้าเป็นจริงจะมีเฉพาะกับ Groovy หรือเป็น OOP โดยทั่วไปหรือไม่ และทำไม?

19 java  object-oriented  groovy  static  instance 

สองสามเดือนที่ผ่านมาฉันเริ่มทำงานในโครงการใหม่และเมื่อผ่านรหัสมันทำให้ฉันจำนวนคงที่วิธีการแบบคงที่ ไม่เพียง แต่วิธีการใช้งานยูทิลิตี้collectionToCsvString(Collection<E> elements)แต่ยังมีตรรกะทางธุรกิจมากมาย เมื่อผมถามคนที่มีความรับผิดชอบสำหรับเหตุผลที่อยู่เบื้องหลังนี้เขาบอกว่ามันเป็นวิธีการหนีออกจากการปกครองแบบเผด็จการของฤดูใบไม้ผลิ มันมีบางสิ่งที่อยู่รอบกระบวนการคิดนี้: เพื่อใช้วิธีการสร้างการรับลูกค้าเราอาจมีบริการ @Service public class CustomerReceiptCreationService { public CustomerReceipt createReceipt(Object... args) { CustomerReceipt receipt = new CustomerReceipt(); // creation logic return receipt; } } ตอนนี้ผู้ชายคนนั้นบอกว่าเขาไม่ชอบที่จะมีคลาสที่จัดการโดยสปริงโดยไม่จำเป็นเพราะมันมีข้อ จำกัด ว่าคลาสไคลเอนต์จะต้องเป็นสปริงบีนเอง เราจบลงด้วยการจัดการทุกอย่างในฤดูใบไม้ผลิซึ่งบังคับให้เราทำงานกับวัตถุไร้สัญชาติอย่างเป็นขั้นตอน มากหรือน้อยที่ระบุไว้ที่นี่https://www.javacodegeeks.com/2011/02/domain-driven-design-spring-aspectj.html ดังนั้นแทนที่จะเป็นรหัสข้างต้นเขามี public class CustomerReceiptCreator { public static CustomerReceipt createReceipt(Object... args) { CustomerReceipt receipt = new CustomerReceipt(); …

13 java  object-oriented  state  static-methods  static 

เหตุใด C ++ จึงสร้างความแตกต่างระหว่างสถิตแบบคงที่ (การเชื่อมโยงภายใน) และสัญลักษณ์ในเนมสเปซที่ไม่มีชื่อ (การเชื่อมโยงภายนอก แต่ไม่มีวิธีการอ้างถึงจากภายนอกอย่างไรก็ตาม) เหตุผลเหล่านี้ยังคงใช้ได้หรือมีเหตุผลใหม่หรือไม่? มีสถานที่ใดบ้างที่ยังคงแตกต่างกันไป แต่ต้องมีกฎเกณฑ์ที่สหภาพนิรนามทั่วโลก (หรือขอบเขตของเนมสเปซ)staticที่ไม่ระบุชื่อและต้องเป็นอะไร สำหรับคะแนนโบนัสหากไม่มีเหตุผลดีๆที่ทำให้พวกเขาแตกต่างกันมีการขอให้เทียบเท่าหรือไม่? เมื่อ C ++ แนะนำเนมสเปซ (C ++ 98) และเนมสเปซที่ไม่มีชื่อโดยเฉพาะรูปทรงแบบคงที่ถูกเลิกใช้แล้วล้าสมัยและด้อยกว่าสิ่งใหม่ในความกระตือรือร้นแม้ว่ามันจะถูกเปลี่ยนกลับด้วย C ++ 11 : การ คัดค้านคำสำคัญ ... ไม่มาก ก่อน C ++ 11 สัญลักษณ์ที่มีการเชื่อมโยงภายในไม่สามารถใช้เป็นอาร์กิวเมนต์ของเทมเพลต: ทำไม C ++ 03 จึงต้องการให้พารามิเตอร์เทมเพลตมีการเชื่อมโยงภายนอก

11 c++  language-design  history  namespace  static 

ปิด คำถามนี้จะต้องมีมากขึ้นมุ่งเน้น ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้มุ่งเน้นที่ปัญหาเดียวโดยแก้ไขโพสต์นี้ ปิดให้บริการใน5 ปีที่ผ่านมา ฉันเข้าใจแนวคิดของวัตถุและในฐานะที่เป็นโปรแกรมเมอร์ Java ฉันรู้สึกว่ากระบวนทัศน์ OO นั้นค่อนข้างเป็นธรรมชาติสำหรับฉันในทางปฏิบัติ อย่างไรก็ตามเมื่อเร็ว ๆ นี้ฉันพบว่าตัวเองกำลังคิด: รอสักครู่สิ่งที่เป็นประโยชน์จริงของการใช้วัตถุมากกว่าการใช้คลาสคงที่ (มีการห่อหุ้มที่เหมาะสมและการปฏิบัติ OO)? ฉันนึกถึงประโยชน์สองประการของการใช้วัตถุ (ทั้งสองอย่างมีความสำคัญและมีประสิทธิภาพ): ความแตกต่าง: ช่วยให้คุณสามารถสลับการทำงานแบบไดนามิกและยืดหยุ่นในช่วงรันไทม์ ยังอนุญาตให้เพิ่ม 'ส่วน' การทำงานใหม่และทางเลือกให้กับระบบได้อย่างง่ายดาย ตัวอย่างเช่นหากมีCarคลาสที่ออกแบบมาเพื่อทำงานกับEngineวัตถุและคุณต้องการเพิ่ม Engine ใหม่ให้กับระบบที่รถยนต์สามารถใช้ได้คุณสามารถสร้างEngineคลาสย่อยใหม่ และเพียงส่งวัตถุของคลาสนี้ไปยัง Carวัตถุโดยไม่ต้อง Carเปลี่ยนอะไรเกี่ยวกับ และคุณสามารถตัดสินใจได้ในระหว่างรันไทม์ ความสามารถในการ 'ผ่านฟังก์ชันการทำงานรอบ ๆ ': คุณสามารถส่งผ่านวัตถุรอบ ๆ ระบบแบบไดนามิก แต่มีข้อได้เปรียบเพิ่มเติมใด ๆ กับวัตถุที่อยู่เหนือคลาสแบบคงที่ บ่อยครั้งที่ฉันเพิ่ม 'ส่วน' ใหม่ลงในระบบฉันทำได้โดยการสร้างคลาสใหม่และสร้างอินสแตนซ์ของวัตถุจากมัน แต่เมื่อเร็ว ๆ นี้เมื่อฉันหยุดและคิดเกี่ยวกับมันฉันรู้ว่าชั้นคงที่จะทำเช่นเดียวกับวัตถุในสถานที่จำนวนมากที่ฉันมักจะใช้วัตถุ ตัวอย่างเช่นฉันกำลังทำงานเพื่อเพิ่มกลไกการบันทึก / …

9 design  object-oriented  class  static