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

C # เป็นภาษาการเขียนโปรแกรมเชิงวัตถุที่มีการจัดการและรวบรวมขยะที่สร้างขึ้นโดย Microsoft ควบคู่ไปกับแพลตฟอร์ม. NET

6
เมื่อใดควรใช้การอ้างอิงที่อ่อนแอใน. Net
ฉันไม่ได้เจอกับสถานการณ์ที่ฉันต้องการใช้ WeakReference ใน. Net แต่โดยส่วนตัวแล้วความเชื่อที่ได้รับความนิยมดูเหมือนว่าควรจะใช้ในแคช ดรจอน Harrop ให้กรณีที่ดีมากกับการใช้งานของ WeakReferences ในแคชของเขาในคำตอบไปนี้คำถาม ฉันมักจะได้ยินนักพัฒนา AS3 พูดคุยเกี่ยวกับการใช้การอ้างอิงที่อ่อนแอเพื่อบันทึกในหน่วยความจำ แต่จากการสนทนาที่ฉันมีมันดูเหมือนว่าจะเพิ่มความซับซ้อนโดยไม่จำเป็นต้องบรรลุเป้าหมายที่กำหนดไว้และพฤติกรรมของรันไทม์ค่อนข้างไม่แน่นอน มากเสียจนหลายคนยอมแพ้และจัดการการใช้หน่วยความจำอย่างระมัดระวังมากขึ้น / เพิ่มประสิทธิภาพรหัสของพวกเขาเพื่อให้หน่วยความจำน้อยมาก (หรือทำให้การแลกเปลี่ยนรอบ CPU และหน่วยความจำขนาดเล็กลง) ดร. จอน Harrop ยังชี้ให้เห็นในคำตอบของเขาว่าการอ้างอิงที่อ่อนแอของ. Net นั้นไม่นุ่มนวลและมีการรวบรวมการอ้างอิงที่อ่อนแอใน gen0 จากการอ้างอิงของMSDNการอ้างอิงที่ไม่รัดกุมจะช่วยให้คุณสามารถสร้างวัตถุใหม่ได้but the state of the object remains unpredictable.! จากลักษณะเหล่านี้ฉันไม่สามารถนึกถึงสถานการณ์ที่การอ้างอิงที่อ่อนแอจะมีประโยชน์บางทีใครบางคนสามารถทำให้ฉันเข้าใจได้

12
การจับข้อยกเว้นทั่วไปเป็นสิ่งที่ไม่ดีจริง ๆ หรือ
ฉันมักจะเห็นด้วยกับคำเตือนการวิเคราะห์รหัสส่วนใหญ่และฉันพยายามที่จะปฏิบัติตามพวกเขา อย่างไรก็ตามฉันมีเวลายากขึ้นกับสิ่งนี้: CA1031: อย่าตรวจจับชนิดข้อยกเว้นทั่วไป ฉันเข้าใจเหตุผลของกฎนี้ แต่ในทางปฏิบัติถ้าฉันต้องการที่จะทำสิ่งเดียวกันโดยไม่คำนึงถึงข้อยกเว้นที่ถูกโยนออกไปทำไมฉันต้องจัดการแต่ละอย่างโดยเฉพาะ? นอกจากนี้หากฉันจัดการข้อยกเว้นเฉพาะจะเกิดอะไรขึ้นถ้ารหัสที่ฉันเรียกจะเปลี่ยนแปลงเพื่อให้เกิดข้อยกเว้นใหม่ในอนาคต ตอนนี้ฉันต้องเปลี่ยนรหัสเพื่อจัดการข้อยกเว้นใหม่นั้น ในขณะที่ถ้าฉันเพียงแค่จับExceptionรหัสของฉันไม่ต้องเปลี่ยน ตัวอย่างเช่นถ้า Foo เรียกบาร์และ Foo จำเป็นต้องหยุดการประมวลผลโดยไม่คำนึงถึงประเภทของข้อยกเว้นที่เกิดจาก Bar มีข้อได้เปรียบอะไรบ้างในการระบุประเภทของข้อยกเว้นที่ฉันจับได้ อาจเป็นตัวอย่างที่ดีกว่า: public void Foo() { // Some logic here. LogUtility.Log("some message"); } public static void Log() { try { // Actual logging here. } catch (Exception ex) { // Eat it. Logging failures shouldn't …
56 c#  design  exceptions 

7
หลักการความรับผิดชอบเดี่ยว - ฉันจะหลีกเลี่ยงการแตกรหัสได้อย่างไร
ฉันกำลังทำงานกับทีมที่หัวหน้าทีมเป็นผู้สนับสนุนหลักการการพัฒนาที่มั่นคง อย่างไรก็ตามเขาขาดประสบการณ์จำนวนมากในการนำซอฟต์แวร์ที่ซับซ้อนออกจากประตู เรามีสถานการณ์ที่เขาใช้ SRP กับสิ่งที่เคยเป็นฐานรหัสที่ซับซ้อนอยู่แล้วซึ่งตอนนี้มีการแยกส่วนสูงมากและยากที่จะเข้าใจและตรวจแก้จุดบกพร่อง ตอนนี้เรามีปัญหาไม่เพียง แต่กับการกระจายตัวของรหัส แต่ยังรวมถึงการห่อหุ้มเป็นวิธีการภายในชั้นเรียนที่อาจเป็นส่วนตัวหรือได้รับการป้องกันได้รับการพิจารณาเพื่อเป็นตัวแทนของ 'เหตุผลในการเปลี่ยนแปลง' และได้รับการสกัด ไม่สอดคล้องกับเป้าหมายการห่อหุ้มของแอปพลิเคชัน เรามีตัวสร้างคลาสที่ใช้พารามิเตอร์อินเทอร์เฟซมากกว่า 20 ตัวดังนั้นการลงทะเบียน IoC และการแก้ปัญหาของเราจึงกลายเป็นสัตว์ประหลาดในตัวของมันเอง ฉันต้องการทราบว่ามี 'refactor อยู่ห่างจาก SRP' หรือไม่ที่เราสามารถใช้เพื่อช่วยแก้ไขปัญหาเหล่านี้ได้ ฉันได้อ่านแล้วว่ามันไม่ได้เป็นการละเมิด SOLID ถ้าฉันสร้างคลาสที่ว่างเปล่าแบบหยาบจำนวนมากที่ 'ห่อ' คลาสที่เกี่ยวข้องอย่างใกล้ชิดเพื่อให้เข้าถึงจุดรวมการทำงานของจุดเดียว (เช่นการเลียนแบบน้อย ใช้งานคลาสมากเกินไป SRP) นอกจากนั้นฉันไม่สามารถคิดถึงวิธีแก้ปัญหาที่จะช่วยให้เราสามารถดำเนินการต่อไปในการพัฒนาของเราในทางปฏิบัติในขณะที่ทำให้ทุกคนมีความสุข ข้อเสนอแนะใด ๆ

8
ทำไมวิธีหลักแบบคงที่ใน Java และ C # มากกว่าตัวสร้าง?
ฉันกำลังมองหาคำตอบที่ชัดเจนจากแหล่งที่มาหลักหรือรองสำหรับเหตุผลที่ (โดยเฉพาะ) Java และ C # ตัดสินใจที่จะมีวิธีการแบบคงที่เป็นจุดเริ่มต้นของพวกเขาแทนที่จะเป็นตัวแทนอินสแตนซ์ของโปรแกรมประยุกต์โดยอินสแตนซ์ของApplicationชั้นเรียน เป็นตัวสร้างที่เหมาะสม) ความเป็นมาและรายละเอียดของการวิจัยก่อนหน้าของฉัน สิ่งนี้เคยถูกถามมาก่อน แต่น่าเสียดายที่คำตอบที่มีอยู่เป็นเพียงการขอถาม โดยเฉพาะอย่างยิ่งคำตอบต่อไปนี้จะไม่ทำให้ฉันพึงพอใจเพราะฉันคิดว่าไม่ถูกต้อง: จะมีความกำกวมหากคอนสตรัคเตอร์มากเกินไป - ในความเป็นจริง C # (เช่นเดียวกับ C และ C ++) ช่วยให้ลายเซ็นที่แตกต่างกันเพื่อMainให้มีความกำกวมที่อาจเกิดขึ้นเหมือนกันและมีการจัดการ staticวิธีหมายถึงวัตถุที่ไม่สามารถ instantiated ก่อนเพื่อให้คำสั่งของ initialisation เป็นที่ชัดเจน - นี่เป็นเพียงความผิดจริงวัตถุบางอย่างจะถูกยกตัวอย่างก่อน (เช่นในตัวสร้างแบบคงที่) ดังนั้นจึงสามารถเรียกใช้โดยรันไทม์โดยไม่ต้องสร้างอินสแตนซ์ของวัตถุหลัก - นี่ไม่ใช่คำตอบเลย เพื่อให้เหตุผลเพิ่มเติมว่าทำไมฉันจึงคิดว่านี่เป็นคำถามที่ถูกต้องและน่าสนใจ: กรอบหลายคนไม่ใช้ชั้นเรียนเพื่อเป็นตัวแทนของการใช้งานและการก่อสร้างเป็นจุดเข้า ยกตัวอย่างเช่นกรอบใบสมัคร VB.NETใช้โต้ตอบเฉพาะหลัก (และตัวสร้างของมัน) เป็นจุดเริ่มต้นที่1 ทั้ง Java และ C # ในทางเทคนิคต้องการวิธีการหลัก ดี C # ต้องการคอมไพล์ …
54 java  c#  history  entry-point 

2
เหตุใดจึงไม่อนุญาตให้ 'void' เป็นประเภททั่วไปใน C #
อะไรคือการตัดสินใจในการออกแบบที่แย้งว่าvoidไม่สามารถสร้างได้และไม่ได้รับอนุญาตให้เป็นประเภททั่วไป? structท้ายที่สุดมันก็ว่างเปล่าเป็นพิเศษและจะหลีกเลี่ยง PITA โดยรวมที่มีความแตกต่างFuncและActionผู้ได้รับมอบหมาย (C ++ อนุญาตให้voidส่งคืนอย่างชัดเจนและอนุญาตให้voidเป็นพารามิเตอร์เทมเพลต)

11
ฉันไม่เข้าใจว่า TDD ช่วยให้ฉันได้รับการออกแบบที่ดีได้อย่างไรถ้าฉันต้องการการออกแบบเพื่อเริ่มการทดสอบ
ฉันพยายามคลุมศีรษะด้วย TDD โดยเฉพาะในส่วนของการพัฒนา ฉันได้ดูหนังสือบางเล่ม แต่หนังสือที่ฉันพบส่วนใหญ่จัดการกับส่วนทดสอบ - ประวัติของ NUnit ทำไมการทดสอบจึงดี Red / Green / Refactor และวิธีการสร้างเครื่องคำนวณสตริง สิ่งที่ดี แต่นั่นคือ "เพียงแค่" การทดสอบหน่วยไม่ใช่ TDD โดยเฉพาะฉันไม่เข้าใจว่า TDD ช่วยให้ฉันได้รับการออกแบบที่ดีได้อย่างไรถ้าฉันต้องการการออกแบบเพื่อเริ่มการทดสอบ เพื่ออธิบายให้นึกภาพ 3 ข้อเหล่านี้: แคตตาล็อกต้องมีรายการผลิตภัณฑ์ แค็ตตาล็อกควรจดจำผลิตภัณฑ์ที่ผู้ใช้ดู ผู้ใช้ควรสามารถค้นหาผลิตภัณฑ์ได้ ณ จุดนี้มีหนังสือหลายเล่มดึงกระต่ายเวทมนตร์ออกมาจากหมวกและกระโดดลงไปใน "การทดสอบบริการผลิตภัณฑ์" แต่พวกเขาไม่ได้อธิบายว่าพวกเขาสรุปได้อย่างไรว่ามีบริการผลิตภัณฑ์ในตอนแรก นั่นคือส่วน "การพัฒนา" ใน TDD ที่ฉันพยายามเข้าใจ จำเป็นต้องมีการออกแบบที่มีอยู่ แต่สิ่งที่อยู่นอกบริการ - เอนทิตี้ (นั่นคือ: มีผลิตภัณฑ์ดังนั้นควรมี ProductService) ไม่พบ (เช่นข้อกำหนดที่สองต้องการให้ฉันมีแนวคิดบางอย่างของ ผู้ใช้ แต่ฉันจะใส่ฟังก์ชั่นการเตือนไว้ที่ไหนและค้นหาคุณสมบัติของ ProductService …
50 java  c#  .net  tdd 

7
การจัดการและจัดการจำนวนคลาสที่เพิ่มขึ้นอย่างมากหลังจากเปลี่ยนมาใช้ SOLID?
ในช่วงไม่กี่ปีที่ผ่านมาเราได้ค่อยๆเปลี่ยนไปใช้โค้ดที่ดีขึ้นอย่างค่อยเป็นค่อยไปในเวลาไม่กี่ก้าว ในที่สุดเราก็เริ่มที่จะเปลี่ยนไปใช้สิ่งที่คล้ายกับ SOLID อย่างน้อยที่สุด แต่เรายังไม่ถึงจุดนั้น นับตั้งแต่ทำการสลับหนึ่งในข้อร้องเรียนที่ใหญ่ที่สุดจากนักพัฒนาคือพวกเขาไม่สามารถยืนทบทวนและตรวจสอบไฟล์หลายสิบไฟล์ซึ่งก่อนหน้านี้ทุกงานต้องการเพียงผู้พัฒนาที่สัมผัส 5-10 ไฟล์ ก่อนที่จะเริ่มสวิตช์สถาปัตยกรรมของเราได้รับการจัดระเบียบอย่างดีดังต่อไปนี้ (ให้สิทธิ์โดยมีหนึ่งหรือสองไฟล์ที่มีขนาดมากกว่าหนึ่งคำสั่ง): Solution - Business -- AccountLogic -- DocumentLogic -- UsersLogic - Entities (Database entities) - Models (Domain Models) - Repositories -- AccountRepo -- DocumentRepo -- UserRepo - ViewModels -- AccountViewModel -- DocumentViewModel -- UserViewModel - UI ไฟล์ฉลาดทุกอย่างเป็นเส้นตรงและกะทัดรัดอย่างเหลือเชื่อ เห็นได้ชัดว่ามีการทำสำเนารหัสจำนวนมากการมีเพศสัมพันธ์อย่างแน่นหนาและปวดหัวอย่างไรก็ตามทุกคนสามารถเข้าไปสำรวจและคิดออกได้ สามเณรที่สมบูรณ์ผู้ที่ไม่เคยเปิด Visual Studio …

11
เหตุใด /// บล็อกความคิดเห็นจึงมีความสำคัญ
มีคนเคยกล่าวว่าเราควรนำหน้าวิธีการทั้งหมดของเราด้วย /// <summary>บล็อกความคิดเห็น (C #) แต่ไม่ได้อธิบายว่าทำไม ฉันเริ่มใช้พวกเขาและพบว่าพวกเขาทำให้ฉันรำคาญเล็กน้อยดังนั้นหยุดใช้พวกเขายกเว้นห้องสมุดและวิธีการคงที่ พวกมันเทอะทะและฉันก็ลืมที่จะอัพเดทอยู่เสมอ มีเหตุผลที่ดีที่ใช้/// <summary>บล็อคความคิดเห็นในรหัสของคุณหรือไม่ ปกติฉันจะใช้//ความคิดเห็นตลอดเวลามันเป็นเพียง/// <summary>ช่วงเวลาที่ฉันสงสัย
49 c#  comments 

3
วิธีใดเป็นวิธีปฏิบัติที่ดีกว่าสำหรับตัวอย่างหรือแบบสถิต?
คำถามนี้เป็นเรื่องส่วนตัว แต่ฉันแค่อยากรู้ว่าโปรแกรมเมอร์ส่วนใหญ่เข้าหานี้อย่างไร ตัวอย่างด้านล่างเป็นแบบหลอก -C # แต่ควรใช้กับ Java, C ++ และภาษา OOP อื่น ๆ ด้วย อย่างไรก็ตามเมื่อเขียนวิธีการช่วยเหลือในชั้นเรียนของฉันฉันมักจะประกาศให้พวกเขาเป็นแบบคงที่และเพียงผ่านเขตข้อมูลหากวิธีการช่วยเหลือที่พวกเขาต้องการ ตัวอย่างเช่นกำหนดรหัสข้างล่างนี้ผมชอบที่จะใช้วิธีการโทร # 2 class Foo { Bar _bar; public void DoSomethingWithBar() { // Method Call #1. DoSomethingWithBarImpl(); // Method Call #2. DoSomethingWithBarImpl(_bar); } private void DoSomethingWithBarImpl() { _bar.DoSomething(); } private static void DoSomethingWithBarImpl(Bar bar) { …

9
เหตุใดจึงเกิดการวน (จริง) ในตัวสร้างที่ไม่ดีจริง ๆ
แม้ว่าคำถามทั่วไปขอบเขตของฉันจะค่อนข้าง C # เพราะฉันรู้ว่าภาษาอย่าง C ++ มีความหมายที่แตกต่างกันเกี่ยวกับการเรียกใช้คอนสตรัคเตอร์การจัดการหน่วยความจำพฤติกรรมที่ไม่ได้กำหนด ฯลฯ บางคนถามคำถามที่น่าสนใจซึ่งไม่ได้รับคำตอบสำหรับฉันง่ายๆ ทำไม (หรือเลยหรือ?) ถือได้ว่าเป็นการออกแบบที่ไม่ดีเพื่อให้ตัวสร้างคลาสเริ่มการวนซ้ำไม่สิ้นสุด (เช่นลูปเกม) มีแนวคิดบางอย่างที่แตกหักโดยสิ่งนี้: เช่นเดียวกับหลักการที่สร้างความประหลาดใจน้อยที่สุดผู้ใช้ไม่คาดหวังว่านวกรรมิกจะทำงานแบบนี้ การทดสอบหน่วยยากขึ้นเนื่องจากคุณไม่สามารถสร้างคลาสนี้หรือฉีดได้เนื่องจากไม่เคยออกจากลูป จุดสิ้นสุดของลูป (จบเกม) เป็นแนวคิดในเวลาที่คอนสตรัคสร้างเสร็จซึ่งก็แปลก ในทางเทคนิคแล้วคลาสนี้ไม่มีสมาชิกสาธารณะยกเว้นนวกรรมิกซึ่งทำให้เข้าใจได้ยากขึ้น (โดยเฉพาะภาษาที่ไม่มีการใช้งาน) แล้วมีปัญหาทางเทคนิค: คอนสตรัคเตอร์ไม่เคยเสร็จสิ้นดังนั้นจะเกิดอะไรขึ้นกับ GC ที่นี่? วัตถุนี้มีอยู่แล้วใน Gen 0 หรือไม่ การได้มาจากคลาสนั้นเป็นไปไม่ได้หรืออย่างน้อยก็ซับซ้อนมากเนื่องจากข้อเท็จจริงที่ว่าคอนสตรัคเตอร์ไม่ส่งคืน เห็นได้ชัดว่ามีบางสิ่งที่ไม่ดีหรือคดเคี้ยวมากกว่านี้หรือไม่?
47 c#  architecture 

12
หลีกเลี่ยงวูดู `goto 'หรือไม่
ฉันมีswitchโครงสร้างที่มีหลายกรณีที่ต้องจัดการ การswitchดำเนินการมากกว่าenumที่ poses ปัญหาของรหัสที่ซ้ำกันผ่านค่ารวม: // All possible combinations of One - Eight. public enum ExampleEnum { One, Two, TwoOne, Three, ThreeOne, ThreeTwo, ThreeOneTwo, Four, FourOne, FourTwo, FourThree, FourOneTwo, FourOneThree, FourTwoThree, FourOneTwoThree // ETC. } ขณะนี้switchโครงสร้างจัดการแต่ละค่าแยกกัน: // All possible combinations of One - Eight. switch (enumValue) { case One: DrawOne; break; …

3
เหตุใด C # จึงอนุญาตคุณสมบัติในส่วนต่อประสาน
ใน C # รหัสต่อไปนี้ถูกต้อง interface I{ int property{get;set;} } ซึ่งไม่สมเหตุสมผลเลยสำหรับฉัน สิ่งนี้ดูเหมือนจะทำลายหนึ่งในหลักการที่สำคัญที่สุดของอินเทอร์เฟซ: ขาดสถานะ (กล่าวอีกนัยหนึ่งไม่มีฟิลด์) สถานที่ให้บริการไม่ได้สร้างเขตข้อมูลส่วนตัวโดยนัย? นั่นจะไม่เลวสำหรับอินเทอร์เฟซหรือไม่

1
เหตุใดโลกของ. Net จึงดูเหมือนว่าจะโอบกอดสายเวทมนตร์แทนที่จะเป็นทางเลือกที่ถูกพิมพ์อย่างคงที่?
ดังนั้นฉันทำงานใน. Net ฉันทำโครงการโอเพนซอร์สใน. Net หนึ่งในปัญหาที่ใหญ่ที่สุดของฉันกับมันไม่จำเป็นต้องมี. Net แต่กับชุมชนและกรอบรอบ ๆ มัน ดูเหมือนทุกที่แผนการตั้งชื่อและสตริงที่มีมนต์ขลังจะถือเป็นวิธีที่ดีที่สุดในการทำทุกอย่าง คำสั่งตัวหนา แต่ดูที่: ASP.Net MVC: สวัสดีเส้นทางโลก: routes.MapRoute( "Default", // Route name "{controller}/{action}/{id}", // URL with parameters new { controller = "Home", action = "Index", id = "" } // Parameter defaults ); สิ่งนี้หมายความว่า ASP.Net MVC จะค้นหาHomeControllerรหัสของคุณ สร้างอินสแตนซ์ใหม่ของมันแล้วเรียกใช้ฟังก์ชันIndex กับidพารามิเตอร์บางประเภท แล้วมีสิ่งอื่น ๆ เช่น: …

3
ตัวสร้างการฉีดคืออะไร?
ฉันได้ดูคำว่า constructor injection และการพึ่งพาในขณะที่อ่านบทความเกี่ยวกับรูปแบบการออกแบบ (Service locator) เมื่อฉันไปเกี่ยวกับการฉีดคอนสตรัคเตอร์ฉันได้ผลลัพธ์ที่ไม่ชัดเจนซึ่งทำให้ฉันเช็คอินที่นี่ ตัวสร้างการฉีดคืออะไร? นี่เป็นการฉีดแบบพึ่งพาหรือไม่? ตัวอย่างที่ยอมรับได้จะเป็นความช่วยเหลือที่ดี! แก้ไข กลับมาที่คำถามนี้อีกครั้งหลังจากผ่านไปหนึ่งสัปดาห์ฉันจะเห็นว่าฉันหลงทางได้อย่างไร ... ในกรณีที่มีใครปรากฏขึ้นที่นี่ฉันจะอัปเดตคำถามโดยมีการเรียนรู้เล็กน้อยของฉัน กรุณาอย่าลังเลที่จะแสดงความคิดเห็น / ถูกต้อง คอนสตรัคเตอร์การฉีดและการฉีดคุณสมบัติเป็นสองประเภทของการพึ่งพาการฉีด

4
ทำไมและเมื่อใดฉันจึงควรทำให้คลาส 'คงที่'? วัตถุประสงค์ของคำหลัก 'คงที่' ในชั้นเรียนคืออะไร?
staticคำหลักในเป็นสมาชิกในหลายภาษาหมายความว่าคุณไม่ควรสร้างตัวอย่างของการเรียนที่จะสามารถที่จะมีการเข้าถึงของสมาชิกที่ แต่ผมไม่เห็นเหตุผลใด ๆ staticที่จะทำให้ทั้งชั้น ทำไมและเมื่อไรฉันจึงควรเข้าเรียนstatic? ฉันได้รับประโยชน์อะไรบ้างจากการเข้าเรียนstatic? ฉันหมายถึงหลังจากประกาศคลาสคงที่หนึ่งควรยังคงประกาศสมาชิกทั้งหมดที่เขา / เธอต้องการที่จะเข้าถึงได้โดยไม่ต้องเริ่มต้นเช่นเดียวกับคงที่เช่นกัน ซึ่งหมายความว่าตัวอย่างเช่นMathคลาสสามารถประกาศปกติ (ไม่ใช่สแตติก) โดยไม่ส่งผลกระทบต่อวิธีที่นักพัฒนาโค้ด กล่าวอีกนัยหนึ่งการทำให้คลาสคงที่หรือปกตินั้นเป็นประเภทที่โปร่งใสสำหรับนักพัฒนา

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.