在声明名称空间和类时,我注意到至少有两种方法可以这样做。我遇到的两个最常见的情况是:
namespace Vehicles
{
public class Car
{
public string Make {get; set;}
public int Year {get; set;}
public string Model {get; set;}
}
}
namespace Vehicles.Car.Engine
{
public class Engine
{
public string Type {get; set;}
public int Cylinder {get; set;}
}
}
namespace Vehicles
{
public class Car
{
public string Make {get; set;}
public int Year {get; set;}
public string Model {get; set;}
}
public class CarEngine
{
public string Type {get; set;}
public int Cylinder {get; set;}
}
}
关于命名约定,如何为命名空间/类选择命名约定,以及在将类名组合为一个长类名时如何调用此约定?
答案 0 :(得分:1)
您的名称空间应该是逻辑域,您的类名称应根据它们的具体用途而定,同时还要考虑要解决的问题。
例如
namespace Vehicles.Cars
{
public class CarBase
{
public string Make {get; set;}
public int Year {get; set;}
public string Model {get; set;}
}
public class Toyota : CarBase
{
}
}
namespace Vehicles.Cars.Engines
{
public class DeiselEngine
{
public string Type {get; set;}
public int Cylinder {get; set;}
}
}
答案 1 :(得分:1)
我相信在这种情况下,这取决于您是否拥有其他引擎。
如果这是您系统中引擎的唯一示例,只需将其命名为Engine
。
否则,我会选择CarEngine
,因为这样可以更轻松地识别您要查找的类。
此外,还可以将名称空间视为组织类的一种方式,就像将文件组织到文件夹中一样。它总是有帮助的。
考虑control+ting
并在拥有相同名称的许多不同类时搜索Engine
。
这里没有对与错,只要确保您的团队有一套自己的规则对所有人可见,确保在请求请求期间这些规则就可以了。
不必太担心,命名和缓存失效是计算机科学中最困难的问题。
答案 2 :(得分:0)
更多取决于您要如何构建应用程序。并非每个应用程序都需要相同的粒度和结构类型。主要标准是它必须简单,并针对您的应用程序要解决的问题/场景保持逻辑。另外,并非所有事物都在别的东西里面,您的引擎在汽车内,但是引擎本身非常复杂,是自己的东西:
namespace Vehicles
{
public class MotorBike
{
Engine Engine { get; set; }
List<Tire> Tires {get; set; }
}
public class Car
{
Engine Engine { get; set; }
List<Tire> Tires {get; set; }
}
public class CompactCar : Car
{
}
public class Engine
{
List<Pistons> { get; set;}
...
}
public class DieselEngine : Engine
{
...
}
public class Tire
{
int Diameter {get; set;}
...
}
}