首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
MCP广场
社区首页 >问答首页 >如何使此代码遵循坚实的C#原则

如何使此代码遵循坚实的C#原则
EN

Code Review用户
提问于 2021-01-19 09:58:29
回答 1查看 62关注 0票数 0

目前我有这样的代码:

代码语言:javascript
复制
private async Task<(List<SomeModel> data1, List<string> data2)> 
                    ProcessFileAsync(IEnumerable<FileInfo> filesInDirectory)
{
    var data1 = new List<SomeModel>();
    var data2 = new List<string>();
    
    var inDirectory = filesInDirectory as FileInfo[] ?? filesInDirectory.ToArray();
    for (var lIndex = 0; lIndex < inDirectory.Count(); lIndex++)
    {
        var content = await File.ReadAllTextAsync(inDirectory.ElementAt(lIndex).FullName);

        var name = Path.GetFileNameWithoutExtension(inDirectory.ElementAt(lIndex).Name);

        var data1Task = GetData1Async(content, name);
        var data2Task = GetData2Async(content);

        await Task.WhenAll(data1Task, data2Task);

        data1.AddRange(data1Task.Result);
        data2.AddRange(data2Task.Result);
    }

    return (data1, data2);
}
代码语言:javascript
复制
private async Task<(List<SomeModel> data1, List<string> data2)> BatchProcessFilesAsync()
{
    var batchSize = 4;

    var models
        = await GetDataFromSomewhereAsync().ConfigureAwait(false);
    var listOfRequests = new List<Task<(List<SomeModel> data1, List<string> data2)>>();

    var fileModels = models.ToList();
    for (var skip = 0; skip <= fileModels.Count(); skip += batchSize)
    {
        var files = fileModels.Skip(skip).Take(batchSize);
        listOfRequests.Add(ProcessFileAsync(files));
    }

    // This will run all the calls in parallel to gain some performance
    var allFinishedTasks = await 
    Task.WhenAll(listOfRequests).ConfigureAwait(false);

我面临的问题是,如果将来需要添加data3,我必须在这里再次添加代码。有没有办法让这段代码可靠。

EN

回答 1

Code Review用户

发布于 2021-01-19 13:00:44

让我向您展示如何从坚实的原则角度来审查您的代码。

在这里,我试图列出一些一般性问题,并给出一些指导,以帮助您确定您当前的解决方案是否违反了一些原则。

单责任原则

问:XYZ方法是做什么的?

如果你的答案与上述任何一个相似:

  • 首先..。然后它..。
  • 它确实..。而且它..。
  • 它叫..。方法和..。方法
  • 等。

这是代码方法做太多事情的一个好迹象。

为了说明清楚,这个原则并不建议将每一行包装成一个单独的函数。相反,它建议将密切相关的内容结合起来,以增强凝聚力。我们应该努力实现高凝聚力和低耦合的目标。

开闭原理

问:您的XYZ方法是否适合T或W类型的更改?

在这个原则中,你试着猜测未来你会遇到什么。假设XYZ可以处理XYZ。如果您需要支持TW,那么您需要修改当前的代码吗?或者,例如,您可以继承并且只覆盖必要的方法吗?

Liskov代换原理

不适用于此。

接口隔离原理

问:我(作为你的API的使用者)必须知道IXYZ的每一种方法都做什么吗?

这个原则建议试着从消费者的角度去思考。如果我只想调用X,那么需要提供XYZ的接口吗?您可以将此原则视为SRP对接口的扩展。如果您的界面包含的成员不是高度一致的,那么您需要滑动它。

依赖反演原理

问:您的XYZ类/方法是否依赖于其他具体类?

这个原则建议依赖抽象而不是具体的类型。(请记住,我们的目标是松散耦合)。如果您依赖于抽象而不是实现,那么您可以轻松切换,而不需要修改这个类(这也有助于OCP )。

我希望这对你有一点帮助。我建议进一步阅读这些优秀的文章:

票数 1
EN
页面原文内容由Code Review提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接:

https://codereview.stackexchange.com/questions/254941

复制
相关文章

相似问题

领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档