不同類的許多命令行參數

Question

我們使用特定的軟件來執行帶有許多參數的控制台應用程序（現在是25（！），並且可能會越來越多）。 當然，對於不同的類，需要使用不同的參數。 我用NDesk.Options解析它。 但是，我一次又一次地在所有課程上都這樣做了。

class A {
    A (IEnumerable<String> args){
        new OptionSet {
            { "arg1=", value => foo1 = value },
                { "arg2=", value => foo2 = value },
            ...
        }.Parse(args);
    }
}
class B {
    B (IEnumerable<String> args){
        new OptionSet {
            { "arg10=", value => foo10 = value },
                { "arg11=", value => foo11 = value },
            ...
        }.Parse(args);
    }
}

如何進行良好的設計？ 解析靜態類中的所有參數並使用它或其他？

Answer 1

由於您要的是設計模式，這聽起來像是Interpreter模式的工作 。

否則，以我的經驗，命令行參數'parsing'是Pattern Matching的一個很好的例子，不幸的是，C＃沒有，但是F＃有。 在ZeroToNine中 ，當前匹配的參數如下所示：

let Parse argv =
    match argv |> Seq.toList with
    | ["-l"] -> ListVersions
    | ["-a"; IsProperVersionString version] -> Assign version
    | ["-i"; "major"] -> Increment Rank.Major
    | ["-i"; "minor"] -> Increment Rank.Minor
    | ["-i"; "build"] -> Increment Rank.Build
    | ["-i"; "patch"] -> Increment Rank.Build
    | ["-i"; "revision"] -> Increment Rank.Revision
    | ["-a"; "major"; IntegerGreaterThanOrEqualToZero rankValue] -> AssignRank(Rank.Major, rankValue)
    | ["-a"; "minor"; IntegerGreaterThanOrEqualToZero rankValue] -> AssignRank(Rank.Minor, rankValue)
    | ["-a"; "build"; IntegerGreaterThanOrEqualToZero rankValue] -> AssignRank(Rank.Build, rankValue)
    | ["-a"; "patch"; IntegerGreaterThanOrEqualToZero rankValue] -> AssignRank(Rank.Build, rankValue)
    | ["-a"; "revision"; IntegerGreaterThanOrEqualToZero rankValue] -> AssignRank(Rank.Revision, rankValue)
    | ["-?"] -> ShowHelp
    | ["-h"] -> ShowHelp
    | [] -> ShowHelp
    | x -> Unknown(x)
    |> Seq.singleton

誠然，我們沒有25個不同的參數，但是上面的示例仍然應該使您感覺到處理各種情況有多么容易。

即使您具有C＃代碼庫，也可以使用F＃編寫解析器庫。

還有一點不同：如果您的控制台應用程序使用25個不同的參數，將它拆分成幾個較小的控制台應用程序是否有意義？ 聽起來好像做得很多。

Answer 2

構建器模式可用於通過命令行參數配置解析器和/或類。 這樣可以避免構造函數具有大量參數，其中一些參數可能是可選的。 它允許輕松添加新參數。

Apache有一個很好的示例，可用於命令行解析的Builder。

另一方面，Builder有風險。 有時，它用於避免構造函數的反模式過多的參數。 之所以采用反模式，是因為您可能暴露了太多的類機密（實現細節），或者同樣糟糕的是，類的職責過多。

正如我在對您的問題的評論中提到的那樣，論點數量眾多且一直在變化，這一事實可能是不良的高級設計的標志。 沒有更多細節很難說。