1. 继承与重写：C#面向对象编程的核心机制
在银行账户管理系统的开发过程中，我深刻体会到继承与重写是构建可扩展业务逻辑的利器。想象一下，当我们需要为不同类型的银行账户（储蓄账户、信用账户、礼品卡账户）实现差异化业务规则时，继承机制让我们能够复用基础账户类的通用功能，而方法重写则赋予子类定制特定行为的能力。
1.1 继承的本质与实现
继承的核心价值在于建立"is-a"关系。在我们的银行系统案例中，InterestEarningAccount（利息账户）本质上就是一个BankAccount（银行账户），只是增加了计算利息的特殊行为。C#中使用冒号语法实现继承：
csharp复制public class InterestEarningAccount : BankAccount
{
// 子类特有成员
}
实际开发中需要注意几个关键点：
- 构造函数链式调用：子类必须通过
base关键字调用父类构造函数 - 访问控制：父类的
private成员对子类不可见，应使用protected修饰需要继承的成员 - 初始化顺序：父类字段初始化 → 父类构造函数 → 子类字段初始化 → 子类构造函数
经验之谈：在金融系统中，账户基类通常会将核心字段如_balance标记为private，通过protected方法提供受控访问，这是封装敏感数据的行业惯例。
1.2 方法重写的实战技巧
当不同类型的账户需要实现不同的月末处理逻辑时，虚方法重写就派上用场了。我们在基类中定义虚方法：
csharp复制public virtual void PerformMonthEndTransactions() { }
在子类中通过override关键字提供具体实现：
csharp复制// 利息账户实现
public override void PerformMonthEndTransactions()
{
if (Balance > 500m)
{
decimal interest = Balance * 0.02m;
MakeDeposit(interest, DateTime.Now, "apply monthly interest");
}
}
// 信用账户实现
public override void PerformMonthEndTransactions()
{
if (Balance < 0) // 透支状态
{
decimal interest = -Balance * 0.07m;
MakeWithdrawal(interest, DateTime.Now, "Charge monthly interest");
}
}
实际项目中的经验教训：
- 虚方法不宜过多：过度使用会降低代码可预测性
- 保持行为一致性：重写方法应保持与基类方法相似的行为契约
- 使用模板方法模式：将不可变流程放在基类，可变部分设为虚方法
2. 高级技巧：构建弹性继承体系
2.1 可扩展的取款限制机制
在开发信用账户时，我们发现传统的直接抛出异常的方式不够灵活。通过引入保护方法模式，我们实现了更优雅的解决方案：
csharp复制// 基类中的取款方法
public void MakeWithdrawal(decimal amount, DateTime date, string note)
{
ArgumentOutOfRangeException.ThrowIfNegativeOrZero(amount);
Transaction? overdraftTransaction = CheckWithdrawalLimit(Balance - amount < _minimumBalance);
Transaction? withdrawal = new(-amount, date, note);
_allTransactions.Add(withdrawal);
if (overdraftTransaction != null)
_allTransactions.Add(overdraftTransaction);
}
// 可重写的限制检查方法
protected virtual Transaction? CheckWithdrawalLimit(bool isOverdrawn)
{
if (isOverdrawn)
{
throw new InvalidOperationException("Not sufficient funds for this withdrawal");
}
return null;
}
信用账户通过重写该方法实现透支费用机制：
csharp复制protected override Transaction? CheckWithdrawalLimit(bool isOverdrawn) =>
isOverdrawn
? new Transaction(-20, DateTime.Now, "Apply overdraft fee")
: default;
这种设计模式的优点：
- 保持核心流程稳定
- 允许子类灵活改变边界行为
- 避免重复验证逻辑
2.2 构造函数链的最佳实践
当账户体系需要支持不同初始化参数时，构造函数链可以保持代码DRY原则：
csharp复制public class BankAccount
{
private readonly decimal _minimumBalance;
// 主构造函数
public BankAccount(string name, decimal initialBalance, decimal minimumBalance)
{
Owner = name;
_minimumBalance = minimumBalance;
if (initialBalance > 0)
MakeDeposit(initialBalance, DateTime.Now, "Initial balance");
}
// 次级构造函数
public BankAccount(string name, decimal initialBalance)
: this(name, initialBalance, 0) { }
}
在信用账户中的使用：
csharp复制public LineOfCreditAccount(string name, decimal initialBalance, decimal creditLimit)
: base(name, initialBalance, -creditLimit) { }
关键点：使用readonly保护关键字段，确保账户最低余额等核心参数在对象生命周期内不可变
3. 实战中的陷阱与解决方案
3.1 继承体系下的异常处理
在重构取款逻辑时，我们遇到过典型的Liskov替换原则问题。原始实现直接抛出异常：
csharp复制// 旧版实现
public void MakeWithdrawal(decimal amount, DateTime date, string note)
{
if (Balance - amount < _minimumBalance)
{
throw new InvalidOperationException("Not sufficient funds");
}
// ...
}
这导致信用账户无法实现透支功能。通过引入策略模式，我们将异常处理转化为可重写的保护方法，使子类能自定义不足额处理方式。
3.2 多态引发的性能考量
在高频交易的金融系统中，虚方法调用会比非虚方法有轻微性能开销。我们的解决方案：
- 对性能关键路径的方法避免使用virtual
- 必要时使用sealed禁止进一步重写
- 采用模板方法模式集中处理性能敏感操作
csharp复制public sealed override void PerformMonthEndTransactions()
{
// 最终实现，禁止派生类修改
base.PerformMonthEndTransactions();
// 子类特有逻辑
}
4. 架构层面的思考
4.1 继承与组合的抉择
虽然继承功能强大，但在实际项目中我们遵循"优先组合"的原则：
- 继承适用于严格的is-a关系
- 组合更适合has-a或行为扩展场景
- 当继承层次超过3层时考虑重构
例如，账户奖励系统更适合用组合实现：
csharp复制public class BankAccount
{
private IRewardCalculator _rewardCalculator;
public void ApplyReward()
{
var reward = _rewardCalculator.Calculate(this);
MakeDeposit(reward, DateTime.Now, "Reward");
}
}
4.2 领域驱动设计中的继承应用
在复杂金融系统中，我们采用DDD的分层架构：
- 核心领域层：抽象账户基类
- 领域服务：处理跨账户交易
- 应用层：协调用例流程
- 基础设施层：持久化实现
继承主要用在领域模型层，保持业务逻辑的集中与复用。