รูปแบบสำหรับคลาสที่ทำสิ่งเดียวเท่านั้น

สมมติว่าฉันมีขั้นตอนที่ทำสิ่งต่าง ๆ :

void doStuff(initalParams) {
    ...
}

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

class StuffDoer {
    private someInternalState;

    public Start(initalParams) {
        ...
    }

    // some private helper procedures here
    ...
}

แล้วฉันจะเรียกมันว่า:

new StuffDoer().Start(initialParams);

หรือเช่นนี้

new StuffDoer(initialParams).Start();

และนี่คือสิ่งที่รู้สึกผิด เมื่อใช้. NET หรือ Java API ฉันไม่เคยโทรnew SomeApiClass().Start(...);ซึ่งทำให้ฉันสงสัยว่าฉันทำผิด แน่นอนว่าฉันสามารถทำให้คอนสตรัคเตอร์ของ StuffDoer เป็นส่วนตัวและเพิ่มวิธีช่วยแบบคงที่:

public static DoStuff(initalParams) {
    new StuffDoer().Start(initialParams);
}

แต่แล้วฉันก็มีคลาสที่อินเตอร์เฟซภายนอกประกอบด้วยวิธีคงที่เพียงวิธีเดียวซึ่งก็รู้สึกแปลก ๆ

ดังนั้นคำถามของฉัน: มีรูปแบบที่ดีขึ้นสำหรับชั้นเรียนประเภทนี้หรือไม่

• มีจุดเข้าใช้งานเพียงจุดเดียวและ
• ไม่มีสถานะ "ที่รู้จักภายนอก" กล่าวคือต้องมีสถานะอินสแตนซ์เฉพาะในระหว่างการดำเนินการของจุดเริ่มต้นนั้น

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

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

ฉันจะบอกว่าชั้นเรียนที่มีปัญหา (ใช้จุดเข้าเดียว) ได้รับการออกแบบมาเป็นอย่างดี มันใช้งานง่ายและขยาย ค่อนข้างทึบ

no "externally recognizable" stateสิ่งเดียวกันสำหรับ มันเป็น encapsulation ที่ดี

ฉันไม่เห็นปัญหาเกี่ยวกับรหัสเช่น:

var doer = new StuffDoer(initialParams);
var result = doer.Calculate(extraParams);

จากมุมมองหลักการ SOLID คำตอบ jgauffinเหมาะสม อย่างไรก็ตามคุณไม่ควรลืมเกี่ยวกับหลักการออกแบบทั่วไปเช่นที่หลบซ่อนข้อมูล

ฉันเห็นปัญหาหลายประการด้วยวิธีการที่กำหนด:

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

ข้อมูลอ้างอิงบางส่วนที่เกี่ยวข้อง

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

การอ้างอิงที่เกี่ยวข้องอื่นที่เกี่ยวข้องกับหัวข้อนี้: "แบ่งโปรแกรมของคุณเป็นวิธีการที่ทำงานหนึ่งที่สามารถระบุตัวได้เก็บการดำเนินการทั้งหมดไว้ในวิธีการในระดับเดียวกันของนามธรรม " - Kent Beck Key นี่คือ "ระดับที่เป็นนามธรรมของสิ่งเดียวกัน" นั่นไม่ได้หมายความว่า "สิ่งหนึ่ง" เนื่องจากมักถูกตีความ ระดับของสิ่งที่เป็นนามธรรมนี้ขึ้นอยู่กับบริบทที่คุณออกแบบ

ดังนั้นวิธีการที่เหมาะสมคืออะไร?

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

new TupleList<Key, int>
{
    { Key.NumPad1, 1 },
            ...
    { Key.NumPad3, 16 },
    { Key.NumPad4, 17 },
}
    .ForEach( t =>
    {
        var trigger = new IC.Trigger.EventTrigger(
                        new KeyInputCondition( t.Item1, KeyInputCondition.KeyState.Down ) );
        trigger.ConditionsMet += () => AddMarker( t.Item2 );
        _inputController.AddTrigger( trigger );
    } );

เนื่องจากรหัส 'ท้องถิ่น' มาก ๆ ภายในForEachไม่ได้ถูกนำไปใช้ที่อื่นฉันสามารถเก็บไว้ในตำแหน่งที่แน่นอนซึ่งมีความเกี่ยวข้อง การสรุปรหัสในลักษณะที่รหัสซึ่งอาศัยซึ่งกันและกันถูกจัดกลุ่มอย่างรุนแรงร่วมกันทำให้สามารถอ่านได้ในความคิดของฉัน

ทางเลือกที่เป็นไปได้

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

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

new StuffDoer().Start(initialParams);

มีปัญหากับนักพัฒนาที่ไม่มีส่วนร่วมที่สามารถใช้อินสแตนซ์ที่แชร์และใช้งานได้

1. หลาย ๆ ครั้ง (ตกลงถ้าการดำเนินการก่อนหน้านี้ (อาจเป็นบางส่วน) ไม่ทำให้การทำงานในภายหลังยุ่งเหยิง)
2. จากหลายกระทู้ (ไม่ตกลงคุณบอกอย่างชัดเจนว่ามันมีสถานะภายใน)

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

การซ่อนไว้ในเมธอดแบบสแตติกช่วยในเรื่องนี้เพราะการใช้อินสแตนซ์ซ้ำจะไม่เกิดขึ้นอีก

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

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

นอกจากคำตอบอื่น ๆ ที่มีความซับซ้อนและเป็นส่วนตัวของฉันแล้วฉันรู้สึกว่าการสังเกตต่อไปนี้สมควรได้รับคำตอบแยกต่างหาก

มีข้อบ่งชี้ว่าคุณอาจจะมีต่อไปนี้เป็นจิตวิญญาณต่อต้านรูปแบบ

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

อาการและผลที่ตามมา

• เส้นทางการนำทางที่ซ้ำซ้อน
• ความสัมพันธ์ชั่วคราว
• ชนชั้นไร้สัญชาติ
• วัตถุและคลาสชั่วคราวระยะสั้น
• คลาสการดำเนินการเดี่ยวที่มีอยู่เฉพาะกับ "seed" หรือ "เรียกใช้" คลาสอื่นผ่านการเชื่อมโยงชั่วคราว
• คลาสที่มีชื่อการดำเนินการ“ เหมือนกับการควบคุม” เช่น start_process_alpha

โซลูชันที่ปรับโครงสร้างใหม่

Ghostbusters แก้ปัญหา Poltergeists โดยลบออกจากลำดับชั้นของคลาสทั้งหมด อย่างไรก็ตามหลังจากการลบออกแล้วฟังก์ชันการทำงานที่“ จัดเตรียมไว้” โดย poltergeist จะต้องถูกแทนที่ สิ่งนี้เป็นเรื่องง่ายด้วยการปรับแต่งอย่างง่ายเพื่อแก้ไขสถาปัตยกรรม

มีหลายรูปแบบที่สามารถพบได้ในแคตตาล็อก P of EAA ของ Martin Fowler ;

1. สคริปต์ธุรกรรม : ค่อนข้างคล้ายกับวิธีที่คุณกล่าวถึง
2. แทนที่เมธอด w / เมธอดอ็อบเจ็กต์ : ดูเหมือนว่าจะเป็นวิธีที่ดีเช่นเดียวกับ @anon ที่กล่าวถึง