PR Summary

This PR centralizes the ExcludeProperty filter application logic in the ViewGenerator base class, addressing the enhancement requested in #26568.

Changes

ViewGenerator base class:

• Changed activeAssociationList from protected field to private field (_activeAssociationList)
• Added ActiveAssociationList read-only property (returns IReadOnlyList<> for safety)
• Added BuildRawAssociationList(PSObject so, List<MshParameter> propertyList) virtual method for subclasses to override
• Added GetActiveAssociationList() template method that extracts both propertyList and excludeFilter from parameters and passes them explicitly to the respective methods
• Added ResetActiveAssociationList() method for List/Wide per-object processing
• Added internal static ApplyExcludeFilter() for reuse in ComplexViewObjectBrowser

Table/List/Wide ViewGenerators:

• Refactored to use the template method pattern
• Override BuildRawAssociationList(PSObject so, List<MshParameter> propertyList) to provide cmdlet-specific property expansion
• Subclasses no longer access parameters field directly; they receive propertyList as a method parameter
• Filter application is now structurally guaranteed (cannot be forgotten)

Complex ViewGenerator:

• Replaced inline filtering logic with ViewGenerator.ApplyExcludeFilter() call
• Removed using System.Linq; (no longer needed)

PR Context

PR #26514 added the -ExcludeProperty parameter to Format-* cmdlets. However, each ViewGenerator subclass had to manually call ApplyExcludePropertyFilter() after building the association list. This approach had two issues:

1. Future implementations: New ViewGenerator subclasses could forget to apply the filter
2. Discoverability: The base class didn't make this requirement obvious

This PR addresses these concerns by:

• Making _activeAssociationList private so subclasses cannot directly assign to it
• Providing GetActiveAssociationList() which automatically applies the filter
• Establishing a clear contract via BuildRawAssociationList() that subclasses override

Note: ComplexViewGenerator uses a recursive architecture with ComplexViewObjectBrowser (a separate class), so it cannot fully adopt the template method pattern. However, code duplication is eliminated by reusing ViewGenerator.ApplyExcludeFilter().

Design Decision: Explicit Parameter Passing

The template method GetActiveAssociationList() extracts both propertyList and excludeFilter from the parameters field at the same level, then passes them explicitly to the respective methods:

protected List<MshResolvedExpressionParameterAssociation> GetActiveAssociationList(PSObject so)
{
    if (_activeAssociationList is null)
    {
        var propertyList = parameters?.mshParameterList;
        var excludeFilter = parameters?.excludePropertyFilter;
        var rawList = BuildRawAssociationList(so, propertyList);
        _activeAssociationList = ApplyExcludeFilter(rawList, excludeFilter);
    }

    return _activeAssociationList;
}

This design ensures:

• Symmetry: Both propertyList and excludeFilter are retrieved at the same abstraction level
• Explicit data flow: Subclasses receive propertyList as a parameter instead of accessing parameters directly
• Separation of concerns: BuildRawAssociationList() handles property expansion; ApplyExcludeFilter() handles filtering

Design Decision: Lazy Initialization vs Constructor

The ViewGenerator class uses an Initialize() method pattern rather than a constructor, which is an existing design in this codebase. Within this pattern, the association list is built lazily via GetActiveAssociationList() rather than eagerly in Initialize() because different subclasses have different timing requirements:

The lazy initialization pattern with GetActiveAssociationList() and ResetActiveAssociationList() provides flexibility for subclasses to call these methods at the appropriate time for their specific formatting needs.

Design Decision: virtual vs abstract for BuildRawAssociationList()

Here is the mapping of cmdlets to ViewGenerator classes and their template method adoption:

The general pattern is that subclasses must implement BuildRawAssociationList(). ComplexViewGenerator (used by Format-Custom) is the exception because it delegates to a separate class for recursive object traversal.

Currently, BuildRawAssociationList() is declared as virtual with a default implementation that returns null. I'd like feedback on whether this should be abstract instead.

If abstract is preferred, I can update the PR.

PR Checklist

• PR has a meaningful title
  • Use the present tense and imperative mood when describing your changes
• Summarized changes
• Make sure all .h, .cpp, .cs, .ps1 and .psm1 files have the correct copyright header
• This PR is ready to merge. If this PR is a work in progress, please open this as a Draft Pull Request and mark it as Ready to Review when it is ready to merge.
• Breaking changes
  • None
  • OR
  • Experimental feature(s) needed
    • Experimental feature name(s):
• User-facing changes
  • Not Applicable
  • OR
  • Documentation needed
    • Issue filed:
• Testing - New and feature
  • N/A or can only be tested interactively
  • OR
  • Make sure you've added a new test if existing tests do not effectively test the code changed