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

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

265 object-oriented  encapsulation  access-modifiers 

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

210 object-oriented  encapsulation 

เท่าที่ฉันเข้าใจคนส่วนใหญ่ดูเหมือนจะยอมรับว่าวิธีการส่วนตัวไม่ควรทดสอบโดยตรง แต่ผ่านวิธีการสาธารณะใด ๆ เรียกพวกเขา ฉันสามารถเห็นประเด็นของพวกเขา แต่ฉันมีปัญหาบางอย่างกับเรื่องนี้เมื่อฉันพยายามติดตาม "สามกฏของ TDD" และใช้วงจร "สีแดง - เขียว - refactor" ฉันคิดว่าตัวอย่างอธิบายได้ดีที่สุด: ตอนนี้ฉันต้องการโปรแกรมที่สามารถอ่านไฟล์ (ที่มีข้อมูลคั่นด้วยแท็บ) และกรองคอลัมน์ทั้งหมดที่มีข้อมูลที่ไม่ใช่ตัวเลข ฉันคิดว่าอาจมีเครื่องมือง่ายๆที่มีอยู่แล้วในการทำเช่นนี้ แต่ฉันตัดสินใจที่จะใช้มันตั้งแต่ต้นตัวเองเพราะฉันคิดว่ามันอาจเป็นโครงการที่ดีและสะอาดสำหรับฉันที่จะได้รับการฝึกฝนด้วย TDD ดังนั้นก่อนอื่นฉัน "ใส่หมวกสีแดง" นั่นคือฉันต้องการการทดสอบที่ล้มเหลว ฉันคิดว่าฉันจะต้องใช้วิธีการที่พบเขตข้อมูลที่ไม่ใช่ตัวเลขทั้งหมดในบรรทัด ดังนั้นฉันจึงเขียนการทดสอบอย่างง่ายแน่นอนว่ามันไม่สามารถรวบรวมได้ทันทีดังนั้นฉันจึงเริ่มเขียนฟังก์ชั่นของตัวเองและหลังจากผ่านไปมาสองรอบ (แดง / เขียว) ฉันมีฟังก์ชั่นการทำงานและการทดสอบที่สมบูรณ์ ถัดไปฉันใช้ฟังก์ชัน "gatherNonNumericColumns" ที่อ่านไฟล์ครั้งละหนึ่งบรรทัดและเรียก "findNonNumericFields" ของฉัน - ฟังก์ชันในแต่ละบรรทัดเพื่อรวบรวมคอลัมน์ทั้งหมดที่ต้องถูกลบออกในที่สุด สองรอบสีแดงสีเขียวและฉันเสร็จแล้วมีอีกครั้งฟังก์ชั่นการทำงานและการทดสอบที่สมบูรณ์ ตอนนี้ฉันคิดว่าฉันควร refactor เนื่องจากวิธีการของฉัน "findNonNumericFields" ได้รับการออกแบบเพราะฉันคิดว่าฉันจะต้องใช้เมื่อใช้งาน "gatherNonNumericColumns" ดูเหมือนว่าฉันจะมีเหตุผลที่จะให้ "findNonNumericFields" เป็นแบบส่วนตัว อย่างไรก็ตามนั่นจะเป็นการทำลายการทดสอบครั้งแรกของฉันเนื่องจากพวกเขาจะไม่สามารถเข้าถึงวิธีการทดสอบได้อีกต่อไป ดังนั้นฉันจบลงด้วยวิธีการส่วนตัวและชุดทดสอบที่ทดสอบ เนื่องจากผู้คนจำนวนมากให้คำแนะนำว่าไม่ควรทำการทดสอบวิธีส่วนตัวจึงรู้สึกเหมือนว่าฉันได้ทาสีตัวเองให้เป็นมุมตรงนี้ …

91 tdd  refactoring  encapsulation 

โครงการส่วนใหญ่ที่ฉันเกี่ยวข้องกับการใช้ส่วนประกอบโอเพ่นซอร์สหลาย ๆ ตามหลักการทั่วไปเป็นความคิดที่ดีเสมอหรือไม่ที่จะหลีกเลี่ยงการผูกส่วนประกอบทั้งหมดของรหัสกับห้องสมุดบุคคลที่สามและแทนที่จะใช้กระดาษห่อหุ้มห่อหุ้มเพื่อป้องกันความเจ็บปวดจากการเปลี่ยนแปลง ตัวอย่างโครงการ PHP ส่วนใหญ่ของเราโดยตรงใช้ log4php เป็นเฟรมเวิร์กการบันทึกนั่นคือยกตัวอย่างผ่าน \ Logger :: getLogger () พวกมันใช้ -> info () หรือ -> warn () วิธีอื่น ๆ ในอนาคต อย่างไรก็ตามกรอบการบันทึกข้อมูลสมมุติฐานอาจปรากฏขึ้นซึ่งจะดีกว่าในบางวิธี โครงการทั้งหมดที่เข้าคู่กับลายเซ็นเมธอด log4php จะต้องเปลี่ยนแปลงในหลาย ๆ แห่งเพื่อให้เหมาะสมกับลายเซ็นใหม่ สิ่งนี้จะส่งผลกระทบอย่างกว้างขวางต่อ codebase และการเปลี่ยนแปลงใด ๆ อาจเป็นปัญหาได้ ในการพิสูจน์โค้ดใหม่ในอนาคตจากสถานการณ์ประเภทนี้ฉันมักจะพิจารณา (และบางครั้งใช้) คลาส wrapper เพื่อห่อหุ้มฟังก์ชั่นการบันทึกและทำให้ง่ายขึ้นแม้ว่าจะไม่เข้าใจผิดเพื่อเปลี่ยนวิธีการบันทึกในอนาคตโดยมีการเปลี่ยนแปลงน้อยที่สุด ; รหัสเรียกเสื้อคลุม, เสื้อคลุมผ่านการเรียกร้องให้กรอบการเข้าสู่ระบบแบบหวือหวา โปรดจำไว้ว่ามีตัวอย่างที่ซับซ้อนมากขึ้นกับห้องสมุดอื่น ๆ ฉันเป็นวิศวกรรมมากเกินไปหรือนี่เป็นข้อควรระวังที่ชาญฉลาดในกรณีส่วนใหญ่? แก้ไข: ข้อควรพิจารณาเพิ่มเติม - การใช้การฉีดพึ่งพาและการทดสอบสองเท่าต้องการให้เราสรุป …

78 third-party-libraries  encapsulation 

ในแอปพลิเคชันเว็บ MVC ทั่วไป (ออกแบบมาอย่างดี) ฐานข้อมูลไม่ทราบรหัสรุ่นรหัสรุ่นไม่ทราบรหัสคอนโทรลเลอร์และรหัสควบคุมไม่ทราบรหัสมุมมอง (ฉันคิดว่าคุณสามารถเริ่มได้ไกลถึงฮาร์ดแวร์หรืออาจจะยิ่งกว่านั้นอีกและรูปแบบอาจเหมือนกัน) ไปอีกทิศทางหนึ่งคุณสามารถลงไปหนึ่งชั้น มุมมองสามารถรับรู้ถึงคอนโทรลเลอร์ แต่ไม่ใช่โมเดล คอนโทรลเลอร์สามารถรับรู้ถึงโมเดล แต่ไม่ใช่ฐานข้อมูล รูปแบบสามารถรับรู้ถึงฐานข้อมูล แต่ไม่ใช่ระบบปฏิบัติการ (อะไรที่ลึกกว่านั้นอาจไม่เกี่ยวข้อง) ฉันสามารถเข้าใจได้อย่างสังหรณ์ใจว่าทำไมนี่เป็นความคิดที่ดี แต่ฉันไม่สามารถพูดได้ ทำไมรูปแบบทิศทางเดียวของการวางแนวคิดที่ดีนี้

66 architecture  mvc  encapsulation  layers 

ฉันได้ข้อโต้แย้งอินเทอร์เน็ตที่น่าสนใจเกี่ยวกับวิธี getter และ setter และการห่อหุ้ม บางคนบอกว่าสิ่งที่พวกเขาควรทำคือมอบหมาย (setters) หรือตัวแปร access (getters) เพื่อให้พวกเขา "บริสุทธิ์" และทำให้แน่ใจว่าการห่อหุ้ม ฉันถูกต้องไหมที่สิ่งนี้จะเอาชนะจุดประสงค์ของการมีผู้ได้รับและผู้ตั้งถิ่นฐานในตอนแรกและการตรวจสอบความถูกต้องและตรรกะอื่น ๆ (โดยไม่มีผลข้างเคียงที่แปลกประหลาดของหลักสูตร) ​​ควรได้รับอนุญาตหรือไม่ การตรวจสอบควรเกิดขึ้นเมื่อใด เมื่อตั้งค่าภายใน setter (เพื่อป้องกันวัตถุจากการเข้าสู่สถานะที่ไม่ถูกต้อง - ความคิดเห็นของฉัน) ก่อนการตั้งค่านอกตัวตั้ง ภายในวัตถุก่อนทุกครั้งที่ใช้ค่า setter ได้รับอนุญาตให้เปลี่ยนค่าหรือไม่ (อาจแปลงค่าที่ถูกต้องเป็นตัวแทนภายในที่ยอมรับได้)

45 object-oriented  language-agnostic  encapsulation 

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

32 javascript  programming-practices  encapsulation  enum 

ซึ่งเป็นวิธีปฏิบัติที่ยอมรับกันโดยทั่วไประหว่างสองกรณีนี้: function insertIntoDatabase(Account account, Otherthing thing) { database.insertMethod(account.getId(), thing.getId(), thing.getSomeValue()); } หรือ function insertIntoDatabase(long accountId, long thingId, double someValue) { database.insertMethod(accountId, thingId, someValue); } กล่าวอีกนัยหนึ่งโดยทั่วไปแล้วการส่งวัตถุทั้งหมดไปรอบ ๆ

31 design-patterns  object-oriented  programming-practices  coding-standards  encapsulation 

โดยเฉพาะฉันเขียนใน JavaScript สมมติว่าฟังก์ชั่นหลักของฉันคือฟังก์ชั่น A ถ้าฟังก์ชั่น A ทำการโทรไปยังฟังก์ชั่น B หลายครั้ง แต่ฟังก์ชั่น B นั้นไม่ได้ใช้ที่อื่นฉันควรวางฟังก์ชั่น B ไว้ในฟังก์ชั่น A หรือไม่ เป็นการปฏิบัติที่ดีหรือไม่? หรือฉันควรจะวาง Function B ในขอบเขตเดียวกับ Function A หรือไม่

30 javascript  programming-practices  patterns-and-practices  encapsulation  scope 

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

26 java  unit-testing  encapsulation  access-modifiers  language-specifications 

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

25 design  design-patterns  object-oriented  encapsulation 

คำถามของฉันเกี่ยวข้องกับSystem.inและSystem.outชั้นเรียน (อาจมีคนอื่น ๆ เช่นที่อยู่ในไลบรารีมาตรฐาน) ทำไมถึงเป็นอย่างนั้น? นั่นเป็นวิธีปฏิบัติที่ไม่ดีใน OOP ใช่หรือไม่ ไม่ควรใช้เช่น: System.getIn()และSystem.getOut()? ฉันมีคำถามนี้มาตลอดและหวังว่าฉันจะหาคำตอบที่ดีได้ที่นี่

25 java  object-oriented  encapsulation 

มันเป็นกลิ่นรหัสที่จะเรียกวิธีสาธารณะในวิธีส่วนตัวของอินสแตนซ์วัตถุเดียวกันหรือไม่?

25 object-oriented  language-agnostic  encapsulation 

ฉันมีคลาสที่มีตัวแปรที่เป็นส่วนตัวและคลาสนั้นมีทะเยอทะยานและ setter สำหรับตัวแปรนั้น ทำไมไม่ทำให้ตัวแปรนั้นเป็นแบบสาธารณะ กรณีเดียวที่ฉันคิดว่าคุณต้องใช้ getters และ setters คือถ้าคุณจำเป็นต้องดำเนินการบางอย่างนอกเหนือจากการตั้งค่าหรือการรับ ตัวอย่าง: void my_class::set_variable(int x){ /* Some operation like updating a log */ this->variable = x; }

23 c++  encapsulation  setters 

ฉันได้ผ่านทฤษฏีมากมายเกี่ยวกับการห่อหุ้มและเทคนิคสามประการของการนำไปใช้ซึ่ง ได้แก่ Association, Aggregation and Composition สิ่งที่ฉันพบคือ : encapsulation Encapsulation เป็นเทคนิคในการสร้างฟิลด์ในคลาสส่วนตัวและให้การเข้าถึงฟิลด์ด้วยวิธีสาธารณะ หากมีการประกาศเขตข้อมูลส่วนบุคคลจะไม่สามารถเข้าถึงได้โดยทุกคนที่อยู่นอกชั้นเรียนดังนั้นจึงซ่อนเขตข้อมูลภายในชั้นเรียน ด้วยเหตุนี้การห่อหุ้มจึงถูกเรียกว่าการซ่อนข้อมูล การห่อหุ้มสามารถอธิบายได้ว่าเป็นเกราะป้องกันที่ป้องกันรหัสและข้อมูลที่ถูกเข้าถึงแบบสุ่มโดยรหัสอื่นที่กำหนดไว้นอกคลาส การเข้าถึงข้อมูลและรหัสถูกควบคุมอย่างแน่นหนาโดยอินเตอร์เฟส ประโยชน์หลักของการห่อหุ้มคือความสามารถในการปรับเปลี่ยนรหัสที่เรานำไปใช้โดยไม่ทำลายรหัสของผู้อื่นที่ใช้รหัสของเรา ด้วยคุณสมบัตินี้ Encapsulation ช่วยให้การบำรุงรักษาความยืดหยุ่นและความสามารถในการขยายโค้ดของเรา สมาคม การเชื่อมโยงคือความสัมพันธ์ที่วัตถุทั้งหมดมีวงจรชีวิตของตนเองและไม่มีเจ้าของ ลองมาเป็นตัวอย่างของครูและนักเรียน นักเรียนหลายคนสามารถเชื่อมโยงกับครูคนเดียวและนักเรียนคนเดียวสามารถเชื่อมโยงกับครูหลายคน แต่ไม่มีความเป็นเจ้าของระหว่างวัตถุและทั้งสองมีวงจรชีวิตของตัวเอง ทั้งสามารถสร้างและลบได้อย่างอิสระ การรวมตัว การรวมเป็นรูปแบบเฉพาะของสมาคมที่วัตถุทั้งหมดมีวงจรชีวิตของตนเอง แต่มีความเป็นเจ้าของและวัตถุลูกไม่สามารถเป็นของวัตถุแม่อื่นได้ มาดูตัวอย่างของภาควิชาและอาจารย์ ครูคนเดียวไม่สามารถอยู่ในหลายแผนกได้ แต่ถ้าเราลบแผนกวัตถุของอาจารย์จะไม่ถูกทำลาย เราสามารถคิดว่ามันเป็นความสัมพันธ์แบบ "มี - a" ส่วนประกอบ องค์ประกอบเป็นอีกรูปแบบหนึ่งของการรวมตัวและเราสามารถเรียกสิ่งนี้ว่าเป็นความสัมพันธ์ "ความตาย" มันเป็นประเภทที่แข็งแกร่งของการรวม วัตถุลูกไม่มีวงจรชีวิตและถ้าวัตถุแม่ลบวัตถุลูกทั้งหมดจะถูกลบ ลองมาอีกตัวอย่างของความสัมพันธ์ระหว่างบ้านและห้อง บ้านสามารถมีหลายห้อง แต่ไม่มีชีวิตอิสระของห้องและห้องใด ๆ ไม่สามารถเป็นของบ้านสองหลังที่แตกต่างกัน หากเราลบบ้านห้องจะถูกลบโดยอัตโนมัติ คำถามคือ: ตอนนี้สิ่งเหล่านี้เป็นตัวอย่างของโลกแห่งความจริง ฉันกำลังมองหาคำอธิบายเกี่ยวกับวิธีการใช้เทคนิคเหล่านี้ในรหัสชั้นเรียนจริง ผมหมายถึงสิ่งที่เป็นจุดสำหรับการใช้สามเทคนิคที่แตกต่างกันสำหรับการห่อหุ้ม …

20 object-oriented  encapsulation