Stryker.NET uses custom classes to keep track of folders and files. These classes are based on the composite pattern.
These FolderComposite and FileLeafs have readonly variants, this is done to ensure the mutated sourcecode and Mutants are not changed after the mutation is placed.
UML of the classes in the namespace Stryker.Core.ProjectComponents
The global structure was as follows:
With the abstract class they both implement:
When implementing F# the old structure showed it's disadvantages since F# uses a different type to indicate syntaxtrees.
To solve this
ProjectComponent was made generic
However many parts of stryker use
FileLeaf without needing access to the syntaxtrees or to know what language is used.
For this purpose the Interface IProjectComponent is used.
IFileLeaf are implemented for the same reason.
This enables code to ask for an
IFileLeaf so It can access the elements that do not depend on the language, that being all except the syntaxtrees.
For applications that do need access to the syntaxtrees
ProjectComponent<T> can be used or the specific type, being:
IFileLeaf<T> is needed to have languageagnostic notation for the syntaxtrees.
Not al code is created equaly, and not all parts of stryker need write access to the ProjectComponents. This is why a IReadOnyProjectcomponent was created.
When expanding into F# we found the implementation lacking and expanded upon it.
There are ReadOnly variants of
The readonly variants do not need access to the syntaxtrees so they are languageagnostic which improves the expandability of Stryker.NET
The variant of
FileLeaf all contain the functions
ToReadOnly() returns the ReadOnly varient of said type.
ToReadOnlyInputComponent() does the same, just casted to
ToReadOnly() takes the interfaces
IFileLeaf as input so the readonly variants do not need to distinguish between
CsharpFileLeaf and FsharpFileLeaf for example.
FileLeaf are NOT classes that exist in Stryker.NET only the languagespecific implementations exist!