ชื่อสำหรับ antipattern นี้? ฟิลด์เป็นตัวแปรท้องถิ่น [ปิด]

ในบางรหัสที่ฉันกำลังตรวจสอบอยู่ฉันเห็นสิ่งที่มีค่าเทียบเท่ากับสิ่งต่อไปนี้:

public class Foo
{
    private Bar bar;

    public MethodA()
    {
        bar = new Bar();
        bar.A();
        bar = null;
    }

    public MethodB()
    {
        bar = new Bar();
        bar.B();
        bar = null;
    }
}

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

1. เห็นได้ชัดว่ามันไม่ถูกต้องใช่มั้ย
2. antipattern นี้มีชื่อหรือไม่?

เห็นได้ชัดว่ามันไม่ถูกต้องใช่มั้ย

ใช่.

• มันทำให้วิธีการที่ไม่ใช่ reentrant ซึ่งเป็นปัญหาถ้าพวกเขาจะเรียกว่าในอินสแตนซ์เดียวกันซ้ำหรือในบริบทแบบมัลติเธรด

• หมายความว่าสถานะจากการโทรหนึ่งสายรั่วไหลไปยังสายอื่น (หากคุณลืมเริ่มต้นใหม่)

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

• มันทำให้แต่ละFooอินสแตนซ์ใหญ่กว่าที่มันจำเป็นต้องมี (และลองจินตนาการว่าทำสิ่งนี้เพื่อตัวแปร N ... )

antipattern นี้มีชื่อหรือไม่?

IMO สิ่งนี้ไม่สมควรถูกเรียกว่า antipattern มันเป็นแค่นิสัยการเขียนโค้ดที่ไม่ดี / การใช้ Java ในทางที่ผิด / การสร้างโค้ด crap มันเป็นสิ่งที่คุณอาจเห็นในรหัสนักศึกษาระดับปริญญาตรีเมื่อนักเรียนข้ามการบรรยายและ / หรือไม่มีความสามารถในการเขียนโปรแกรม หากคุณเห็นมันในรหัสการผลิตมันเป็นสัญญาณที่คุณต้องทำรีวิวโค้ดอีกมากมาย ...

สำหรับบันทึกวิธีที่ถูกต้องในการเขียนคือ:

public class Foo
{
    public methodA()
    {
        Bar bar = new Bar();  // Use a >>local<< variable!!
        bar.a();
    }

    // Or more concisely (in this case) ...
    public methodB()
    {
        new Bar().b();
    }
}

โปรดสังเกตว่าฉันได้แก้ไขเมธอดและชื่อตัวแปรให้สอดคล้องกับกฎสไตล์ที่ยอมรับสำหรับตัวระบุ Java ด้วย

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

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

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

ในกรณีนี้ลูกบิดประตูเป็นเพียงข้อมูลอ้างอิงเท่านั้นดังนั้นจึงมีราคาถูก หากลูกบิดประตูเป็นวัตถุที่เกิดขึ้นจริง (และพวกเขาถูกนำวัตถุแทนเพียงการอ้างอิง) prudent global doorknobจากนั้นก็อาจจะมีราคาแพงพอที่จะเป็น cheapskate global doorknobแต่เมื่อมันมีราคาถูกเป็นที่รู้จักกันเป็น

ตัวอย่างของคุณมีcheapskateความหลากหลาย

ความกังวลหลักที่นี่จะเกิดขึ้นพร้อมกัน - หากมีการใช้ Foo โดยหลายเธรดคุณมีปัญหา

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

เป็นกรณีเฉพาะของ "การกำหนดขอบเขตที่ไม่เหมาะสม" โดยมีด้านข้างของ "การใช้ตัวแปรซ้ำ"

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

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

นี่เป็นเพียงความผิด

เพื่อเพิ่มอีกเล็กน้อย

รหัสนี้เป็นเรื่องเชื่อโชคลางหรือวิธีปฏิบัติที่ดีที่สุดในการขนส่งสินค้า

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

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

ในทั้งสองกรณีนี้ไม่มีกรณีจริง ๆ เกิดขึ้น

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

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

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

(1) ฉันจะบอกว่ามันไม่ดี

มันทำหน้าที่สร้างบ้านด้วยตนเองเพื่อให้สแต็คสามารถทำกับตัวแปรท้องถิ่นได้โดยอัตโนมัติ

ไม่มีประโยชน์ด้านประสิทธิภาพเนื่องจากเรียกว่า "ใหม่" แต่ละวิธีที่เรียกใช้

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

วิธีอื่นในชั้นเรียนสามารถมองเห็นแถบได้ วิธีการที่ไม่ใช้แถบไม่ควรมองเห็น

ข้อผิดพลาดตามรัฐ ในกรณีเฉพาะกรณีนี้สถานะข้อผิดพลาดพื้นฐานควรเกิดขึ้นในหลายเธรดเนื่องจากเรียกว่า "ใหม่" ในแต่ละครั้ง

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

ฉันจะเรียกมันว่า "Wenering Xenophobe" มันต้องการที่จะถูกทิ้งให้อยู่ตามลำพัง แต่ก็ไม่รู้ว่าอยู่ที่ไหนหรืออะไร ดังนั้นจึงเป็นเรื่องที่ไม่ดีอย่างที่คนอื่น ๆ ได้กล่าวไว้

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

วิธีนี้เป็นมาตรฐานในการทำการทดสอบหน่วย

public class BarTester
{
    private Bar bar;

    public Setup() { bar = new Bar(); }
    public Teardown() { bar = null; }

    public TestMethodA()
    {
        bar.A();        
    }

    public TestMethodB()
    {
        bar.B();
    }
}

เป็นเพียงการเปลี่ยนรหัสเทียบเท่าของ OP นี้

public class BarTester
{
    private Bar bar;

    public TestMethodA()
    {
        bar = new Bar();
        bar.A();
        bar = null;
    }

    public TestMethodB()
    {
        bar = new Bar();
        bar.B();
        bar = null;
    }
}

ฉันจะไม่เขียนรหัสตามที่กำหนดโดยตัวอย่าง OP ก็กรีดร้อง refactoring แต่ผมพิจารณารูปแบบที่จะเป็นค่าที่ไม่ถูกต้องหรือantipattern

กลิ่นรหัสนี้เรียกว่าเขตข้อมูลชั่วคราวใน Refactoring โดย Beck / Fowler

http://sourcemaking.com/refactoring/temporary-field

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

หากไม่ใช่การส่งเสริมการขายเป็นการส่วนตัวฉันก็อ้างอิงและอธิบายกลิ่นนี้ในหลักสูตร Pluralsight, Refactoring Fundamentals ซึ่งฉันคาดว่าจะเผยแพร่ในเดือนสิงหาคม 2013

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

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

สำหรับว่ามันไม่ดีหรือไม่ฉันจะบอกว่ามันชัดเจนและฉันคิดว่า Stephen C ทำงานได้อย่างยอดเยี่ยมในการอธิบายว่าทำไม อย่างไรก็ตามไม่ว่าจะสมควรถูกเรียกว่า "anti-pattern" หรือไม่ฉันคิดว่ามันและกระบวนทัศน์การเข้ารหัสอื่น ๆ สามารถทำกับฉลากได้เนื่องจากโดยทั่วไปจะทำให้การสื่อสารง่ายขึ้น

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

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

ฉันเคยพบเจอมาหลายครั้งแล้วโดยปกติแล้วเมื่อโค้ดรีเฟรชที่เขียนโดยคนที่หยิบ VBA สำหรับ Dummies เป็นชื่อแรกของพวกเขาและเขียนระบบที่ค่อนข้างใหญ่ในภาษาใดก็ตามที่พวกเขาสะดุด

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

มันไม่สมควรได้รับแท็ก "antipattern" แต่มันก็ดีที่ได้เห็นคำแนะนำว่า OP จะสามารถนำไปรีไซเคิลได้อย่างไร