codebase ของเรานั้นเก่าและโปรแกรมเมอร์ใหม่อย่างฉันเรียนรู้ที่จะทำอย่างที่มันทำเพื่อความสม่ำเสมอ เมื่อคิดว่าเราจะต้องเริ่มต้นที่ไหนสักแห่งฉันก็เลยทำมันเองเพื่อสร้างคลาสของตัวยึดข้อมูลอีกครั้ง:

• ลบเมธอด setter และสร้างฟิลด์ทั้งหมดfinal(ฉันใช้ " finalดี" ตามหลักการ) ตัวตั้งค่าถูกใช้เฉพาะในตัวสร้างเมื่อมันปรากฏออกดังนั้นสิ่งนี้จึงไม่มีผลข้างเคียง
• แนะนำคลาส Builder

คลาส Builder นั้นจำเป็นเนื่องจากตัวสร้าง (ซึ่งเป็นสิ่งที่ให้การรีแฟคเตอร์ใหม่ในตอนแรก) ครอบคลุมโค้ดประมาณ 3 บรรทัด แต่ก็มีจำนวนมากของพารามิเตอร์

โชคดีที่มีมันเพื่อนร่วมทีมของฉันกำลังทำงานในโมดูลอื่นและเกิดขึ้นเพื่อต้องการผู้ตั้งค่าเนื่องจากค่าที่เขาต้องการนั้นมีอยู่ในจุดต่าง ๆ ในการไหล ดังนั้นรหัสดูเหมือนว่านี้:

public void foo(Bar bar){
    //do stuff
    bar.setA(stuff);
    //do more stuff
    bar.setB(moreStuff);
}

ฉันเป็นที่ถกเถียงกันอยู่ว่าเขาควรจะใช้ผู้สร้างแทนเพราะการกำจัด setters ทำให้ทุ่งนาไม่สามารถเปลี่ยนแปลงได้ (พวกเขาเคยได้ยินว่าฉันโกรธมากเกี่ยวกับความไม่สามารถเปลี่ยนแปลงได้ก่อนหน้านี้) และเพราะผู้สร้างอนุญาตให้สร้างวัตถุ ฉันร่างรหัสเทียมต่อไปนี้:

public void foo(Bar bar){
    try{
        bar.setA(a);
        //enter exception-throwing stuff
        bar.setB(b);
    }catch(){}
}

หากข้อยกเว้นนั้นเริ่มทำงานbarจะมีข้อมูลที่เสียหายซึ่งจะหลีกเลี่ยงได้ด้วยตัวสร้าง:

public Bar foo(){
        Builder builder=new Builder();
    try{
        builder.setA(a);
        //dangerous stuff;
        builder.setB(b);
        //more dangerous stuff
        builder.setC(c);
        return builder.build();
    }catch(){}
    return null;
}

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

การประนีประนอมคือการย้อนกลับไปใช้โซลูชันเก่าคือใช้ตัวสร้างที่ไม่มีพารามิเตอร์และตั้งค่าทุกอย่างด้วย setters ตามต้องการ เหตุผลคือการแก้ปัญหานี้เป็นไปตามหลักการ KISS ซึ่งเหมืองของฉันละเมิด

ฉันใหม่กับ บริษัท นี้ (น้อยกว่า 6 เดือน) และตระหนักดีว่าฉันทำสิ่งนี้หาย คำถามที่ฉันมีคือ:

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

แต่จริงๆ

• คุณมีเคล็ดลับใดบ้างที่จะนำเสนอข้อโต้แย้งดังกล่าวได้ดีขึ้นเมื่อพยายามสนับสนุนสิ่งใหม่ ๆ ?

เมื่อคิดว่าเราจะต้องเริ่มต้นที่ไหนสักแห่งฉันก็ต้องทำมันเองเพื่อสร้างคลาสของ data holder อีกครั้ง

นี่คือที่ที่มันผิดพลาด - คุณทำการเปลี่ยนแปลงทางสถาปัตยกรรมครั้งใหญ่ใน codebase เพื่อให้มันแตกต่างจากที่คาดไว้มาก คุณแปลกใจที่เพื่อนร่วมงานของคุณ ความประหลาดใจเป็นสิ่งที่ดีถ้ามันเกี่ยวข้องกับงานปาร์ตี้หลักการของความประหลาดใจอย่างน้อยที่สุดก็คือทองคำ (แม้ว่าจะเกี่ยวข้องกับงานปาร์ตี้แล้วฉันก็รู้ว่าสวมกางเกงในที่สะอาด!)

ตอนนี้ถ้าคุณคิดว่าการเปลี่ยนแปลงนี้มีค่าควรจะเป็นการดีกว่าที่จะร่าง pseudocode ที่แสดงการเปลี่ยนแปลงและนำเสนอให้เพื่อนร่วมงานของคุณ (หรืออย่างน้อยผู้ที่มีบทบาทใกล้ชิดกับสถาปนิกมากที่สุด) และดูสิ่งที่พวกเขาคิดก่อนทำอะไร ตามที่เป็นอยู่คุณไปโกงคิดว่า codebase ทั้งหมดเป็นของคุณที่จะเล่นกับตามที่คุณคิดว่าเหมาะสม ผู้เล่นในทีมไม่ใช่ผู้เล่นในทีม!

ฉันอาจจะรุนแรงเล็กน้อยกับคุณ แต่ฉันอยู่ในสถานที่ตรงกันข้าม: ลองดูโค้ดและคิดว่า "WTF เกิดขึ้นที่นี่ใช่มั้ย!" เพื่อหาผู้ชายคนใหม่ (เกือบจะเป็นคนใหม่เสมอ) จึงตัดสินใจเปลี่ยน สิ่งต่าง ๆ ขึ้นอยู่กับสิ่งที่เขาคิดว่า "ถูกวิธี" ควรเป็น สกรูที่มีประวัติ SCM ด้วยซึ่งเป็นปัญหาสำคัญอีกประการหนึ่ง

โชคดีที่มีมันเพื่อนร่วมทีมของฉันกำลังทำงานในโมดูลอื่นและเกิดขึ้นเพื่อต้องการผู้ตั้งค่าเนื่องจากค่าที่เขาต้องการนั้นมีอยู่ในจุดต่าง ๆ ในการไหล

ตามที่อธิบายไว้ฉันไม่เห็นสิ่งที่ทำให้รหัสต้องการตัวตั้งค่า ฉันอาจไม่รู้เกี่ยวกับการใช้งานเคสมากพอ แต่ทำไมไม่รอจนกว่าพารามิเตอร์ทั้งหมดจะรู้จักก่อนที่จะทำให้วัตถุเป็นตัวอย่าง?

อีกทางเลือกหนึ่งหากสถานการณ์ต้องการตัวติดตั้ง: เสนอวิธีในการตรึงโค้ดของคุณให้ตัวตั้งค่านั้นโยนข้อผิดพลาดในการยืนยัน (ข้อผิดพลาดของโปรแกรมโปรแกรมเมอร์) หากคุณพยายามแก้ไขฟิลด์หลังจากวัตถุพร้อม

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

เคล็ดลับทั่วไป

เก่า = ไม่ดีใหม่ = ดีวิธีของฉันวิธีของคุณ ... การสนทนาประเภทนี้ไม่สร้างสรรค์

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

ในบางวิธีการปรับเปลี่ยนรหัสจะเชื่อมโยงกับทฤษฎีBroken Window : คุณรู้สึกถูกต้องที่จะแก้ไขปัญหาใด ๆ ตามที่คุณเห็น (หรือจดบันทึกการประชุม "การปรับปรุงคุณภาพ" ในภายหลัง) เพื่อให้โค้ดดูน่าทำงานอยู่เสมอ ปลอดภัยและสะอาด คุณและทีมของคุณไม่มีความคิดเดียวกันเกี่ยวกับสิ่งที่ "ดีพอ" สิ่งที่คุณเห็นว่าเป็นโอกาสในการมีส่วนร่วมและทำให้รหัสดีขึ้นด้วยความสุจริตใจอาจเห็นแตกต่างจากทีมที่มีอยู่

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

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

บางทีทีมของคุณอาจคิดว่าสิ่งที่คุณแนะนำนั้นผ่านจุดที่ลดลงไปแล้ว แม้ว่าคุณจะพบอินสแตนซ์ที่แท้จริงของข้อผิดพลาดเนื่องจากเป็นตัวอย่างที่คุณแสดง (ยกเว้น) พวกเขาอาจจะแก้ไขได้เพียงครั้งเดียวและไม่ต้องการปรับโครงสร้างโค้ดอีกครั้ง

ดังนั้นคำถามคือเกี่ยวกับวิธีการที่จะใช้เวลาและพลังงานของคุณที่ระบุว่าพวกเขาจะถูกจำกัด ? มีการเปลี่ยนแปลงอย่างต่อเนื่องกับซอฟต์แวร์ แต่โดยทั่วไปความคิดของคุณเริ่มต้นด้วยคะแนนลบจนกว่าคุณจะสามารถให้ข้อโต้แย้งที่ดี แม้ว่าคุณจะถูกเกี่ยวกับผลประโยชน์มันไม่ได้เป็นข้อโต้แย้งที่เพียงพอด้วยตัวเองเพราะมันจะจบในตะกร้า" Nice to have, one day ... "

เมื่อคุณแสดงข้อโต้แย้งของคุณคุณต้องทำการตรวจสอบ "สติ": คุณพยายามขายความคิดหรือตัวคุณเองหรือไม่? จะเกิดอะไรขึ้นถ้ามีคนอื่นมอบสิ่งนี้ให้กับทีม? คุณจะพบข้อบกพร่องบางอย่างในการให้เหตุผลของพวกเขา? คุณกำลังพยายามที่จะใช้แนวปฏิบัติทั่วไปที่ดีที่สุดหรือคุณคำนึงถึงข้อกำหนดเฉพาะของรหัสของคุณหรือไม่?

จากนั้นคุณต้องแน่ใจว่าจะไม่ปรากฏเป็น - หากคุณพยายามแก้ไข "ข้อผิดพลาด" ที่ผ่านมาของทีม ช่วยแสดงว่าคุณไม่ใช่ความคิดของคุณ แต่สามารถรับข้อเสนอแนะได้อย่างสมเหตุสมผล ยิ่งคุณทำสิ่งนี้มากเท่าไหร่ข้อเสนอแนะของคุณก็จะยิ่งมีโอกาสมากขึ้น

ฉันจะโปรโมตการใช้รูปแบบเครื่องมือสร้างในทีมของฉันได้อย่างไร

คุณทำไม่ได้

หากคอนสตรัคเตอร์ของคุณมีพารามิเตอร์ 3 บรรทัดมันใหญ่เกินไปและซับซ้อนเกินไป ไม่มีรูปแบบการออกแบบที่จะแก้ไขได้

หากคุณมีคลาสที่มีข้อมูลพร้อมใช้งานในเวลาที่ต่างกันควรเป็นวัตถุสองชิ้นที่แตกต่างกันหรือผู้บริโภคของคุณควรรวมส่วนประกอบแล้วสร้างวัตถุ พวกเขาไม่ต้องการผู้สร้างที่จะทำเช่นนั้น

คุณดูเหมือนจะเน้นไปที่ความถูกต้องมากกว่าที่จะทำงานได้ดีกับผู้อื่น ยิ่งไปกว่านั้นคุณรู้ว่าสิ่งที่คุณกำลังทำคือการต่อสู้กับอำนาจและยังไม่คิดว่าสิ่งต่าง ๆ มีแนวโน้มที่จะรู้สึกกับคนที่มีประสบการณ์และอำนาจที่คุณกำลังท้าทาย

ย้อนกลับที่

มุ่งเน้นการทำงานร่วมกับผู้อื่น วางกรอบความคิดของคุณเป็นข้อเสนอแนะและความคิด ให้พวกเขาพูดคุยผ่านความคิดของพวกเขาก่อนถามคำถามเพื่อทำให้พวกเขาคิดถึงคุณ หลีกเลี่ยงการเผชิญหน้าโดยตรงและเต็มใจที่จะยอมรับว่าการทำสิ่งต่าง ๆ ตามแนวทางของกลุ่ม (ตอนนี้) มีประสิทธิผลมากกว่าการต่อสู้เพื่อต่อสู้เพื่อเปลี่ยนกลุ่ม (แม้ว่าจะนำสิ่งต่าง ๆ กลับคืนมา) ทำให้การทำงานร่วมกับคุณมีความสุข

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

แต่นั่นเป็นความขัดแย้งโดยตรงกับความเป็นจริง ข้อโต้แย้งส่วนใหญ่จะหายไปก่อนที่จะได้รับจุดแรก แม้ในหมู่คนที่อ้างเหตุผลตรรกะจิตวิทยาสำคัญกว่าเหตุผล การโน้มน้าวใจผู้คนคือการผ่านอุปสรรคทางจิตวิทยาในอดีตไปสู่การรับฟังอย่างถูกต้องและไม่เกี่ยวกับการมีเหตุผลที่สมบูรณ์แบบ

มีข้อโต้แย้งอื่น ๆ สำหรับการใช้ผู้สร้างแทนที่จะเป็น "วิธีเก่า" หรือไม่?

"เมื่อคุณมีค้อนใหม่ทุกอย่างจะดูเหมือนเล็บ" - นี่คือสิ่งที่ฉันคิดเมื่อฉันอ่านคำถามของคุณ

ถ้าฉันเป็น coleague ของคุณฉันจะถามคุณว่า "ทำไมไม่เริ่มต้นวัตถุทั้งหมดในตัวสร้าง?" นั่นคือสิ่งที่มันเป็นฟังก์ชั่นหลังจากทั้งหมด ทำไมต้องใช้รูปแบบการสร้าง (หรือการออกแบบอื่น ๆ )?

การเปลี่ยนแปลงที่ฉันเสนอนั้นคุ้มค่าหรือไม่

เป็นการยากที่จะบอกจากตัวอย่างรหัสขนาดเล็กนั้น อาจเป็น - คุณและเพื่อนร่วมทีมของคุณต้องประเมินมัน

คุณมีเคล็ดลับใดบ้างที่จะนำเสนอข้อโต้แย้งดังกล่าวได้ดีขึ้นเมื่อพยายามสนับสนุนสิ่งใหม่ ๆ ?

ใช่เรียนรู้เพิ่มเติมเกี่ยวกับหัวข้อก่อนที่จะอภิปราย แขนตัวเองด้วยข้อโต้แย้งที่ดีและเหตุผลก่อนเข้าสู่การสนทนา

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

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

คำถามที่เกิดขึ้นจริง

ทำไมต้องใช้วัตถุที่ไม่เปลี่ยนรูป? เพราะคุณรู้ว่าคุณกำลังทำอะไรอยู่

สมมติว่าคุณมีการเชื่อมต่อฐานข้อมูลที่ส่งผ่านซึ่งอนุญาตให้คุณเปลี่ยนโฮสต์ผ่านตัวตั้งค่าแล้วคุณจะไม่ทราบว่าการเชื่อมต่อนั้นคืออะไร การไม่เปลี่ยนรูปแล้วคุณจะรู้

สมมติว่าคุณมีโครงสร้างของข้อมูลที่สามารถดึงออกมาจากการคงอยู่แล้วยืนยันข้อมูลใหม่อีกครั้งจากนั้นจึงเหมาะสมที่โครงสร้างนี้ไม่สามารถเปลี่ยนแปลงได้ เป็นเอนทิตีเดียวกัน แต่ค่าสามารถเปลี่ยนแปลงได้ แทนที่จะใช้วัตถุที่ไม่เปลี่ยนค่าเป็นอาร์กิวเมนต์

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

tl; DR

การถอดตัวเซ็ตเตอร์สามารถแก้ไขได้ขึ้นอยู่กับคลาส รูปแบบการสร้างไม่ได้แก้ปัญหาเพียงซ่อนมันไว้ (สิ่งสกปรกใต้พรมยังคงมีอยู่แม้ว่าคุณจะมองไม่เห็น)

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

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

// business objects

interface CharRange {
   public char getCharacter();
   public int getFrom();
   public int getTo();
}

class MultiCharRange implements CharRange {
   final char ch;
   final int from;
   final int to;

   public char getCharacter() { return ch; }
   public int getFrom() { return from; }
   public int getTo() { return to; }
}

class SingleCharRange implements CharRange {
   final char ch;
   final int position;

   public char getCharacter() { return ch; }
   public int getFrom() { return position; }
   public int getTo() { return position; }
}

// builders

class Builder1 {
   public Builder2 character(char ch) {
      return new Builder2(ch);
   }
}

class Builder2 {
   final char ch;
   int from;
   int to;

   public Builder2 range(int from, int to) {
      if (from > to) throw new IllegalArgumentException("from > to");
      this.from = from;
      this.to = to;
      return this;
   }

   public Builder2 zeroStartRange(int to) {
      this.from = 0;
      this.to = to;
      return this;
   }

   public CharRange build() {
      if (from == to)
         return new SingleCharRange(ch,from);
      else 
         return new MultiCharRange(ch,from,to);
   }
}

นี่เป็นตัวอย่างที่น่าเบื่อที่ไม่ค่อยสมเหตุสมผล แต่มันแสดงคุณสมบัติทั้งสาม: ตัวละครจะถูกตั้งค่าก่อนเสมอช่วง จำกัด จะถูกตั้งค่าและตรวจสอบร่วมกันเสมอและคุณเลือกการนำไปใช้ในเวลาบิลด์

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

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

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

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

ฉันไม่คิดว่าคุณสามารถออกแบบรหัสในระดับนี้โดยคณะกรรมการเว้นแต่ว่าคุณจะเขียนโปรแกรมม็อบอย่างแท้จริง (ไม่เหมือนว่าคุณอยู่ในทีมประเภทนั้น) ดังนั้นฉันคิดว่ามันโอเคที่จะทำการเปลี่ยนแปลงตามคุณ การตัดสินที่ดีที่สุดจากนั้นนำไปที่คางหากปรากฎว่าคุณตัดสินผิด

อย่างไรก็ตามตราบใดที่คุณสามารถที่จะพูดถึงปัญหาที่อาจเกิดขึ้นกับรหัสตามที่เป็นอยู่แล้วคุณยังสามารถอภิปรายว่าจำเป็นต้องมีวิธีแก้ปัญหาแม้ว่าคุณจะไม่ได้รับการยอมรับ ผู้คนมีอิสระที่จะเสนอทางเลือกอื่น ๆ

" ความคิดเห็นที่แข็งแกร่งจัดขึ้นอย่างอ่อนแอ " เป็นหลักการที่ดี - คุณจะไปข้างหน้าด้วยความมั่นใจตามสิ่งที่คุณรู้ แต่ถ้าคุณพบข้อมูลใหม่ที่เคาน์เตอร์มันจะสุภาพและก้าวลงและเข้าสู่การอภิปรายเกี่ยวกับทางออกที่ถูกต้อง เป็น คำตอบเดียวที่ผิดคือปล่อยให้แย่ลง