จะหลีกเลี่ยงปัญหา“ พารามิเตอร์มากเกินไป” ในการออกแบบ API ได้อย่างไร

ฉันมีฟังก์ชั่น API นี้:

public ResultEnum DoSomeAction(string a, string b, DateTime c, OtherEnum d, 
     string e, string f, out Guid code)

ฉันไม่ชอบมัน เนื่องจากลำดับพารามิเตอร์มีความสำคัญเกินความจำเป็น การเพิ่มฟิลด์ใหม่กลายเป็นเรื่องยาก มันยากที่จะเห็นสิ่งที่ถูกส่งผ่าน มันยากกว่าที่จะ refactor method เป็นชิ้นส่วนเล็ก ๆ เพราะมันจะสร้างโอเวอร์เฮดอีกครั้งในการส่งผ่านพารามิเตอร์ทั้งหมดในฟังก์ชั่นย่อย รหัสอ่านยากกว่า

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

public class DoSomeActionParameters
{
    public string A;
    public string B;
    public DateTime C;
    public OtherEnum D;
    public string E;
    public string F;        
}

นั่นทำให้การประกาศ API ของฉันลดลงเป็น:

public ResultEnum DoSomeAction(DoSomeActionParameters parameters, out Guid code)

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

public class DoSomeActionParameters
{
    public string A { get; private set; }
    public string B { get; private set; }
    public DateTime C { get; private set; }
    public OtherEnum D { get; private set; }
    public string E { get; private set; }
    public string F { get; private set; }        

    public DoSomeActionParameters(string a, string b, DateTime c, OtherEnum d, 
     string e, string f)
    {
        this.A = a;
        this.B = b;
        // ... tears erased the text here
    }
}

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

public struct DoSomeActionParameters
{
    public readonly string A;
    public readonly string B;
    public readonly DateTime C;
    public readonly OtherEnum D;
    public readonly string E;
    public readonly string F;        
}

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

• ทุกคน (รวมถึง FXCop และจอนสกีต) ยอมรับว่าการเปิดเผยทุ่งสาธารณะที่ไม่ดี
• เอริค Lippert et al, กล่าวว่าอาศัยอยู่ในเขตอ่านได้อย่างเดียวสำหรับการเปลี่ยนไม่ได้เป็นเรื่องโกหก

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

คำชี้แจง:

• โปรดสมมติว่าไม่มีการละเมิดหลักการ responsibiltiy เดียว ในกรณีเดิมของฉันฟังก์ชั่นเพิ่งเขียนพารามิเตอร์ที่กำหนดไปยังระเบียนฐานข้อมูลเดียว
• ฉันไม่ได้กำลังหาวิธีแก้ปัญหาเฉพาะสำหรับฟังก์ชั่นที่กำหนด ฉันกำลังหาแนวทางทั่วไปในการแก้ไขปัญหาดังกล่าว ฉันสนใจที่จะแก้ปัญหา "พารามิเตอร์มากเกินไป" โดยไม่ต้องแนะนำความไม่แน่นอนหรือการออกแบบที่แย่มาก

UPDATE

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

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

var request = new HttpWebRequest(a, b);
var service = new RestService(request, c, d, e);
var client = new RestClient(service, f, g);
var resource = client.RequestRestResource(); // O params after 3 objects

ใช้การผสมผสานระหว่างผู้สร้างและ API สไตล์ภาษาเฉพาะโดเมน - ส่วนต่อประสาน Fluent API นั้นมีความละเอียดมากกว่านี้เล็กน้อย แต่ด้วย Intellisense ทำให้พิมพ์และเข้าใจได้ง่าย

public class Param
{
        public string A { get; private set; }
        public string B { get; private set; }
        public string C { get; private set; }


  public class Builder
  {
        private string a;
        private string b;
        private string c;

        public Builder WithA(string value)
        {
              a = value;
              return this;
        }

        public Builder WithB(string value)
        {
              b = value;
              return this;
        }

        public Builder WithC(string value)
        {
              c = value;
              return this;
        }

        public Param Build()
        {
              return new Param { A = a, B = b, C = c };
        }
  }


  DoSomeAction(new Param.Builder()
        .WithA("a")
        .WithB("b")
        .WithC("c")
        .Build());

สิ่งที่คุณมีบ่งบอกได้ค่อนข้างชัดเจนว่าชั้นเรียนที่มีปัญหานั้นละเมิดหลักการความรับผิดชอบเดี่ยวเพราะมีการพึ่งพามากเกินไป มองหาวิธีการ refactor อ้างอิงเหล่านั้นลงในกลุ่มของซุ้มอ้างอิง

เพียงแค่เปลี่ยนโครงสร้างข้อมูลพารามิเตอร์จากclassa structและคุณก็พร้อมที่จะไป

public struct DoSomeActionParameters 
{
   public string A;
   public string B;
   public DateTime C;
   public OtherEnum D;
   public string E;
   public string F;
}

public ResultEnum DoSomeAction(DoSomeActionParameters parameters, out Guid code) 

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

ข้อดี:

• ใช้งานง่ายที่สุด
• การเปลี่ยนแปลงพฤติกรรมอย่างน้อยที่สุดในกลศาสตร์พื้นฐาน

จุดด้อย:

• Immutability ไม่ชัดเจนต้องให้ความสนใจนักพัฒนา
• การคัดลอกที่ไม่จำเป็นเพื่อรักษาความไม่สามารถเปลี่ยนแปลงได้
• ตรงบริเวณพื้นที่สแต็ค

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

public class DoSomeActionParameters
    {
        public string A { get; private set; }
        public string B  { get; private set; }
        public DateTime C { get; private set; }
        public OtherEnum D  { get; private set; }
        public string E  { get; private set; }
        public string F  { get; private set; }

        public class Builder
        {
            DoSomeActionParameters obj = new DoSomeActionParameters();

            public string A
            {
                set { obj.A = value; }
            }
            public string B
            {
                set { obj.B = value; }
            }
            public DateTime C
            {
                set { obj.C = value; }
            }
            public OtherEnum D
            {
                set { obj.D = value; }
            }
            public string E
            {
                set { obj.E = value; }
            }
            public string F
            {
                set { obj.F = value; }
            }

            public DoSomeActionParameters Build()
            {
                return obj;
            }
        }
    }

    public class Example
    {

        private void DoSth()
        {
            var data = new DoSomeActionParameters.Builder()
            {
                A = "",
                B = "",
                C = DateTime.Now,
                D = testc,
                E = "",
                F = ""
            }.Build();
        }
    }

ฉันไม่ใช่โปรแกรมเมอร์ C # แต่ฉันเชื่อว่า C # รองรับอาร์กิวเมนต์ที่มีชื่อ: (F # ทำและ C # ส่วนใหญ่มีคุณสมบัติที่เข้ากันได้กับสิ่งนั้น): http://msdn.microsoft.com/en-us/library/dd264739 ขอบ # Y342

ดังนั้นการเรียกรหัสต้นฉบับของคุณจะกลายเป็น:

public ResultEnum DoSomeAction( 
 e:"bar", 
 a: "foo", 
 c: today(), 
 b:"sad", 
 d: Red,
 f:"penguins")

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

แก้ไข: นี่คือบทความที่ฉันพบเกี่ยวกับมัน http://www.globalnerdy.com/2009/03/12/default-and-named-parameters-in-c-40-sith-lord-in-training/ ฉันควรพูดถึง C # 4.0 รองรับอาร์กิวเมนต์ที่มีชื่อ 3.0 ไม่ได้

ทำไมไม่เพียงสร้างอินเทอร์เฟซที่บังคับให้ใช้ไม่ได้ (เช่น getters เท่านั้น)

เป็นวิธีแก้ปัญหาแรกของคุณ แต่คุณบังคับให้ฟังก์ชันใช้อินเทอร์เฟซเพื่อเข้าถึงพารามิเตอร์

public interface IDoSomeActionParameters
{
    string A { get; }
    string B { get; }
    DateTime C { get; }
    OtherEnum D { get; }
    string E { get; }
    string F { get; }              
}

public class DoSomeActionParameters: IDoSomeActionParameters
{
    public string A { get; set; }
    public string B { get; set; }
    public DateTime C { get; set; }
    public OtherEnum D { get; set; }
    public string E { get; set; }
    public string F { get; set; }        
}

และการประกาศฟังก์ชั่นจะกลายเป็น:

public ResultEnum DoSomeAction(IDoSomeActionParameters parameters, out Guid code)

ข้อดี:

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

จุดด้อย:

• งานซ้ำ ๆ (ประกาศเหมือนกันในสองหน่วยงานที่แตกต่างกัน)
• นักพัฒนาต้องเดาว่าDoSomeActionParametersเป็นคลาสที่สามารถแมปได้IDoSomeActionParameters

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

    public class ExampleClass
    {
        //create properties like this...
        private readonly int _exampleProperty;
        public int ExampleProperty { get { return _exampleProperty; } }

        //Private constructor, prohibiting construction outside of this class
        private ExampleClass(ExampleClassParams parameters)
        {                
            _exampleProperty = parameters.ExampleProperty;
            //and so on... 
        }

        //The object returned from here will be immutable
        public ExampleClass GetFromDatabase(DBConnection conn, int id)
        {
            //do database stuff here (ommitted from example)
            ExampleClassParams parameters = new ExampleClassParams()
            {
                ExampleProperty = 1,
                ExampleProperty2 = 2
            };

            //Danger here as parameters object is mutable

            return new ExampleClass(parameters);    

            //Danger is now over ;)
        }

        //Private struct representing the parameters, nested within class that uses it.
        //This is mutable, but the fact that it is private means that all potential 
        //"damage" is limited to this class only.
        private struct ExampleClassParams
        {
            public int ExampleProperty { get; set; }
            public int AnotherExampleProperty { get; set; }
            public int ExampleProperty2 { get; set; }
            public int AnotherExampleProperty2 { get; set; }
            public int ExampleProperty3 { get; set; }
            public int AnotherExampleProperty3 { get; set; }
            public int ExampleProperty4 { get; set; }
            public int AnotherExampleProperty4 { get; set; } 
        }
    }

คุณสามารถใช้วิธีการสร้างสไตล์ แต่ขึ้นอยู่กับความซับซ้อนของDoSomeActionวิธีการของคุณนี้อาจเป็นรุ่นหนา บางสิ่งบางอย่างตามสายเหล่านี้:

public class DoSomeActionParametersBuilder
{
    public string A { get; set; }
    public string B { get; set; }
    public DateTime C { get; set; }
    public OtherEnum D { get; set; }
    public string E { get; set; }
    public string F { get; set; }

    public DoSomeActionParameters Build()
    {
        return new DoSomeActionParameters(A, B, C, D, E, F);
    }
}

public class DoSomeActionParameters
{
    public string A { get; private set; }
    public string B { get; private set; }
    public DateTime C { get; private set; }
    public OtherEnum D { get; private set; }
    public string E { get; private set; }
    public string F { get; private set; }

    public DoSomeActionParameters(string a, string b, DateTime c, OtherEnum d, string e, string f)
    {
        A = a;
        // etc.
    }
}

// usage
var actionParams = new DoSomeActionParametersBuilder
{
    A = "value for A",
    C = DateTime.Now,
    F = "I don't care for B, D and E"
}.Build();

result = foo.DoSomeAction(actionParams, out code);

นอกเหนือจากการตอบสนองของ manji - คุณอาจต้องการแยกการปฏิบัติการหนึ่ง ๆ ออกเป็นปฏิบัติการเล็ก ๆ เปรียบเทียบ:

 BOOL WINAPI CreateProcess(
   __in_opt     LPCTSTR lpApplicationName,
   __inout_opt  LPTSTR lpCommandLine,
   __in_opt     LPSECURITY_ATTRIBUTES lpProcessAttributes,
   __in_opt     LPSECURITY_ATTRIBUTES lpThreadAttributes,
   __in         BOOL bInheritHandles,
   __in         DWORD dwCreationFlags,
   __in_opt     LPVOID lpEnvironment,
   __in_opt     LPCTSTR lpCurrentDirectory,
   __in         LPSTARTUPINFO lpStartupInfo,
   __out        LPPROCESS_INFORMATION lpProcessInformation
 );

และ

 pid_t fork()
 int execvpe(const char *file, char *const argv[], char *const envp[])
 ...

สำหรับผู้ที่ไม่รู้จัก POSIX การสร้างเด็กสามารถทำได้ง่ายเหมือน:

pid_t child = fork();
if (child == 0) {
    execl("/bin/echo", "Hello world from child", NULL);
} else if (child != 0) {
    handle_error();
}

ตัวเลือกการออกแบบแต่ละตัวแสดงถึงการแลกเปลี่ยนกับการปฏิบัติการที่อาจทำ

PS ใช่ - คล้ายกับตัวสร้าง - เป็นแบบย้อนกลับเท่านั้น (เช่นทางด้าน callee แทนที่จะเป็นผู้โทร) มันอาจจะหรืออาจจะไม่ดีกว่าแล้วสร้างในกรณีเฉพาะนี้

นี่คือสิ่งที่แตกต่างจาก Mikeys เล็กน้อย แต่สิ่งที่ฉันพยายามจะทำคือทำให้การเขียนให้น้อยที่สุด

public class DoSomeActionParameters
{
    readonly string _a;
    readonly int _b;

    public string A { get { return _a; } }

    public int B{ get { return _b; } }

    DoSomeActionParameters(Initializer data)
    {
        _a = data.A;
        _b = data.B;
    }

    public class Initializer
    {
        public Initializer()
        {
            A = "(unknown)";
            B = 88;
        }

        public string A { get; set; }
        public int B { get; set; }

        public DoSomeActionParameters Create()
        {
            return new DoSomeActionParameters(this);
        }
    }
}

DoSomeActionParameters ไม่สามารถเปลี่ยนได้เนื่องจากสามารถและไม่สามารถสร้างได้โดยตรงเนื่องจากตัวสร้างเริ่มต้นเป็นแบบส่วนตัว

initializer นั้นไม่เปลี่ยนรูป แต่เป็นเพียงการส่งผ่าน

การใช้งานใช้ประโยชน์จาก initializer บน Initializer (ถ้าคุณได้ดริฟท์ของฉัน) และฉันสามารถมีค่าเริ่มต้นใน Constructor เริ่มต้นของ Initializer

DoSomeAction(new DoSomeActionParameters.Initializer
            {
                A = "Hello",
                B = 42
            }
            .Create());

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

และการตรวจสอบสามารถไปในวิธีการสร้าง

public class Initializer
{
    public Initializer(int b)
    {
        A = "(unknown)";
        B = b;
    }

    public string A { get; set; }
    public int B { get; private set; }

    public DoSomeActionParameters Create()
    {
        if (B < 50) throw new ArgumentOutOfRangeException("B");

        return new DoSomeActionParameters(this);
    }
}

ดังนั้นตอนนี้ดูเหมือนว่า

DoSomeAction(new DoSomeActionParameters.Initializer
            (b: 42)
            {
                A = "Hello"
            }
            .Create());

ยังคงเป็นกูกี้เล็ก ๆ น้อย ๆ ที่ฉันรู้ แต่จะลองต่อไป

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

public class DoSomeActionParameters
{
    readonly string _a;
    readonly int _b;

    public string A { get { return _a; } }
    public int B{ get { return _b; } }

    DoSomeActionParameters(Initializer data)
    {
        _a = data.A;
        _b = data.B;
    }

    public class Initializer
    {
        public Initializer()
        {
            A = "(unknown)";
            B = 88;
        }

        public string A { get; set; }
        public int B { get; set; }
    }

    public static DoSomeActionParameters Create(Action<Initializer> assign)
    {
        var i = new Initializer();
        assign(i)

        return new DoSomeActionParameters(i);
    }
}

ดังนั้นตอนนี้การโทรจะเป็นแบบนี้

DoSomeAction(
        DoSomeActionParameters.Create(
            i => {
                i.A = "Hello";
            })
        );

ใช้โครงสร้าง แต่แทนที่จะเป็นเขตข้อมูลสาธารณะมีคุณสมบัติสาธารณะ:

•ทุกคน (รวมถึง FXCop & Jon Skeet) ยอมรับว่าการเปิดเผยช่องสาธารณะนั้นไม่ดี

จอนและ FXCop จะได้รับการตอบรับอย่างดีเนื่องจากคุณกำลังเปิดเผยว่าไม่ใช่สาขา

• Eric Lippert และคนอื่น ๆ กล่าวว่าการใช้ฟิลด์ที่อ่านไม่ออกสำหรับการเปลี่ยนไม่ได้เป็นเรื่องโกหก

Eric จะพอใจเพราะใช้คุณสมบัติคุณสามารถมั่นใจได้ว่าค่าจะถูกตั้งค่าเพียงครั้งเดียว

    private bool propC_set=false;
    private date pC;
    public date C {
        get{
            return pC;
        }
        set{
            if (!propC_set) {
               pC = value;
            }
            propC_set = true;
        }
    }

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

คำตอบของซามูเอลที่แตกต่างที่ฉันใช้ในโครงการเมื่อฉันมีปัญหาเดียวกัน:

class MagicPerformer
{
    public int Param1 { get; set; }
    public string Param2 { get; set; }
    public DateTime Param3 { get; set; }

    public MagicPerformer SetParam1(int value) { this.Param1 = value; return this; }
    public MagicPerformer SetParam2(string value) { this.Param2 = value; return this; }
    public MagicPerformer SetParam4(DateTime value) { this.Param3 = value; return this; }

    public void DoMagic() // Uses all the parameters and does the magic
    {
    }
}

และใช้:

new MagicPerformer().SeParam1(10).SetParam2("Yo!").DoMagic();

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