Today the matching process is governed by the VulnerabilityMatcher object, which gives us a single place to control aspects of the matching process. The main FindMatches() function has been decomposed into ever-smaller functions that deal with smaller concerns of the matching process, which is ultimately good, however, each decomposition is bespoke in terms of what data it has access to and what the return signature is. This means that changes to the matching process may result in changing these function signatures, which isn't ideal.
Additionally, there is a common theme of the following return signature:
...or similar variants. This return signature is at risk of growing for every new data element we want to track.
I have two changes I'd like to propose:
Add tracking of all kinds of matches to the match.Matches collection (e.g. IgnoredMatches is not tracked within this, any dropped matches, etc.) or add an additional match.Collection that incorporates matches and ignored matches together. Then provide methods for adding, removing, and accessing these match objects. This would allow us to keep a single object in function signatures that produce or change matches as well as give us a single place to track changes to these matches (such as publishing result counts on the bus to the TUI, leading to accurate counts being displayed).
Form the existing decomposed functions involved in matched to a single function signature and chain these methods together into a common pipeline. Any function that wishes to participate in adding/removing/changing any aspect of matching will need to adhere to the function signature and placed into the pipeline for processing. Each "processor" function should be as small in scope and responsibility as possible.
Today the matching process is governed by the
VulnerabilityMatcherobject, which gives us a single place to control aspects of the matching process. The mainFindMatches()function has been decomposed into ever-smaller functions that deal with smaller concerns of the matching process, which is ultimately good, however, each decomposition is bespoke in terms of what data it has access to and what the return signature is. This means that changes to the matching process may result in changing these function signatures, which isn't ideal.Additionally, there is a common theme of the following return signature:
...or similar variants. This return signature is at risk of growing for every new data element we want to track.
I have two changes I'd like to propose:
match.Matchescollection (e.g.IgnoredMatchesis not tracked within this, any dropped matches, etc.) or add an additionalmatch.Collectionthat incorporates matches and ignored matches together. Then provide methods for adding, removing, and accessing these match objects. This would allow us to keep a single object in function signatures that produce or change matches as well as give us a single place to track changes to these matches (such as publishing result counts on the bus to the TUI, leading to accurate counts being displayed).