You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If we override a `virtual` member and provide our own implementation, we should default to `sealing` that member to prevent further derivations from modifying that logic unless we've _explicitly_ reviewed that particular case and determined that it is appropriate for derived classes to override the logic—and, potentially, not call `base`.
In most of these cases, we just implemented `protected override` without specific consideration of (further) derived implementations. In many of these cases, such as `SqlTopicRepository`, we don't anticipate derivations. In others, such as `KeyedTopicCollection<T>`, we do, but not of `protected override` members, such as `GetKeyForItem()` or `InsertItem()`.
0 commit comments