让 Pages 从本身继承自 Page 的自定义类继承是一种好习惯吗？答案

【问题标题】：Is it good practice to have Pages that inherit from a custom class which itself inherits from Page?让 Pages 从本身继承自 Page 的自定义类继承是一种好习惯吗？
【发布时间】：2019-08-18 22:02:30
【问题描述】：

有趣的是它奏效了。编译器对代码没有任何问题，尽管这是我从未见过的（可能是因为我是新手）。我想使用新继承的基页面/类作为存储常用代码的地方，这样我就不必复制任何东西。看这里：

public sealed partial class HumanPage : SpeciesBasePage;
public sealed partial class AnimalPage : SpeciesBasePage;
public class SpeciesBasePage : Page;

显然，它之所以有效，是因为 SpeciesBasePage 实现了 Page 类。因此，您还将看到相关的 XAML 页面将具有不同的基类作为其开始标记：

<local:SpeciesBasePage 
    x:Class="PageInheritanceProject.HumanPage" 
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    ...>
    <Grid>
        <TextBlock Text="Hello, world!" />
    </Grid>
</local:SpeciesBasePage>

这样做可以吗？谢谢！

【问题讨论】：

为什么它的工作很有趣？这正是 OOP 中继承的设计方式，不是吗？在您经常这样做之前，请阅读 FCoI（优先组合优于继承）清洁代码原则。
好点。我会纠正它，虽然你可以间接继承。 HumanPage 间接继承 Page。
“这样可以吗？” - 你有疑问吗？其中有很多具有“良好/最佳实践”要求的问题（这太抽象了，甚至无法考虑提出问题），其中许多只是“请查看我的代码并确认它是正确的”而没有任何问题陈述。对我来说这是codereview 请求，请务必询问right。

标签： c# wpf xaml uwp

【解决方案1】：

这是一个相当标准的继承链。在 c# 术语中。需要考虑两件事。

页面的使用是许多商业团队会质疑的问题。

许多团队根本不使用页面，而是使用用户控件（托管在 contentcontrols 中）。

从页面继承。你不能继承 xaml 那你为什么要继承一个可能是容器的 UI 控件？

【讨论】：

我猜你每天都会学到一些新东西。我也必须阅读更多关于这种方法的信息。处理页面可能很烦人。你能给我至少一个在页面上使用 UserControls 的充分理由吗？谢谢。
页面意味着一个框架，它伴随着日志形式的内存开销复杂性和控件的缓存状态。