如何设计课程

发布于 2024-10-20 16:04:56 字数 774 浏览 2 评论 0原文

我正在使用 LINQ to SQL 3.5 Framework，我想知道哪种是设计类的最佳方法。以User 表为例。
如果我有一个用户表，其中包含 3 个不同的角色：客户、管理员、出纳员。我想说我需要为每个角色创建 3 个类。例如customers.cs...

问题：
1）由于 Linq .dbml 已经从我的用户表自动生成了 User，所有属性都已预定义，我是否还需要创建一个 User.cs 类以由上面的 3 个类角色继承？这是因为我无法在 User.cs 中添加任何重复的属性，例如 Public string Name {get;set;} 将失败，因为在 .dbml 中已经具有属性调用 Name。

2）我认为这个问题将是非常基本的问题......但我发现如果我能知道正确的答案它会很有用。我应该如何将我的功能放入正确的类中？ 例如PrintYearlyReport()、CheckStaffSalary()、ModifySale()、UpdateGovernmentTax()....所有这些功能都在Admin的角色下。如果我们有admin.PrintYearlyReport()、admin.ModifySale()...，那么它的可读性会很好。但是，如果我们将所有管理员功能都放在Admin.cs文件中，那么这个文件将是非常非常巨大！！！为了 OOP，我们需要有像 Sale.cs、Payment.cs、Invoice.cs 这样的类。如果我们将所有这些功能分成不同的类，那么我们将不再有调用 admin.PrintYearlyReport() 的优雅方式。

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

怎樣才叫好 2024-10-27 16:04:56

您可以创建 User 类的子类，即 Customer、Admin 和 Cashier，然后指定正确的基于类关于用户的角色。有时，我们会通过创建诸如 User.IsInRole 或 User.HasAccessTo 之类的方法进行设计，您可以调用这些方法来验证他们是否可以访问或使用某些功能。
您可以使用 partial 类将功能拆分为单独的文件，但仍将它们放在同一个类中。如果定义公共分部类 Admin，则可以在任意数量的单独文件中定义类 Admin，并且在构建项目时所有属性都将添加到一起。

回复收藏 0 原文

荒人说梦 2024-10-27 16:04:56

让我们保持简单。通常最好的答案是最简单的答案。您需要上一门以上的课程吗？可能是也可能不是。如果角色之间的差异很简单，那么为什么需要创建子类呢？我通常从一个类开始，因为行为得到了更好的定义，并且您可以清楚地区分子类而不是创建子类。话虽如此，您应该考虑您希望对象是什么样子，我的意思是您要创建什么依赖项以及将共享什么功能。组合与继承当我想到用户和角色时，我想：用户具有角色 x，而不是用户是角色 x，因为角色可以更改。通用功能和属性应该位于基类中。也许您可以将访问规则放在用户内部的类中：

User{
    Name
    Role
    Rules{ }
}

因此您可以说

if(user123.Rules.CanPrint())
{
Print();
}

在用户内部创建规则并传入角色，以便规则类可以确定该用户可以做什么。我就是这样做的。我的观点是，不要纠结于哪个类应该去哪里。定义对象和行为并让类自行定义它们。您将学会发现班级何时变得太大并需要将其分解。

Let’s keep it simple. Usually the best answer is the simplest one. Do you need to have more than one class? May be may be not. If the differences between the roles is simple one liners, than why the need to create subclasses? I usually start out with one class and as the behavior is better defined and you can clearly diferentiate the subclasses than you create them. With that said you should think about what you want your objects to look like, and by that I mean what dependencies you what to create and what functionality will be shared. Composition vs inheretance When I think of users and roles I think: user has role x, not user is role x because roles can change. Common functionality and properties should be in a base class. May be you can put your access rules in a class that lives within the user:

User{
    Name
    Role
    Rules{ }
}

So you can say

if(user123.Rules.CanPrint())
{
Print();
}

Create the rules inside the user and pass in the role(s) so the rules class can figure out what this user can do. This is how I would do it. My point is, don't get hungup on what class should go where. Define objects and behavior and let the classes define them selves. You will learn to spot when a class is getting too big and need to breake it up.

回复收藏 0 原文