One could introduce a dependency injection framework to handle the wire up, or do it manually. So, one will either have to use method level or constructor level dependency injection to pass the dependency in. Now, whoever is calling this method will have to create the proper instance and pass it in. Now, one will need to extract that dependency, either in the constructor or the method that is calling it.Īs an example callout, let's use method level injection: public string MethodLevelInjection(IFileSystem fileSystem, string path) Now the real one: public class RealFileSystem : IFileSystemĪn alternative (Fake): public class FakeFileSystem: IFileSystem I will use an example based on a static file system call, but the concepts are the same for your Redis problem. the Session and Response syntax looked the same but worked rather differently.Ĭreate an interface for the functionality. I believe this is pretty much the approach Microsoft took when migrating everyone from classic ASP to ASP.NET, e.g. Once all of the tests pass identically, you're ready to switch it out, which is as easy as changing the one dependency. Be sure you can explain any difference in test outcomes ideally there shouldn't be any. Run this class through exactly the same unit tests.
#Software wrapper design code
Once you have a thorough understanding of the interface as implemented by the legacy code, create a new class, implementing the same interface, but with brand new code using your newer back end technology (Redis, or whatever).
You want to make sure you understand what it means to fulfill the contract implied by that interface,not just syntactically but semantically.
#Software wrapper design series
Once you have the existing code extracted to an interface/implementation, write a series of integration tests and get it nice and stable. SessionHelper.Foo() //Notice this code hasn't changed at all _sessionHelper = sessionHelper //Injected, or injectable at least Public MassiveSpaghettiCode(ISessionHelper sessionHelper) Public MassiveSpaghettiCode() : this( new SessionHelper() ) //Default constructor requires no injection Protected readonly ISessionHelper _sessionHelper For bonus points, we can inject the instance if we want. This allows the legacy spaghetti code to continue to function without any modification. Then, expose an instance of the implementation via a member property with the same name as the original static class. I would extract the static methods to an interface and copy the implementation code from the static class, only exposing each method as an interface member. Let's say you have a static library like this: class SessionHelperĪnd a program that uses it, that you'd rather not monkey with too much: class MassiveSpaghettiCode That's the difference to the other solutions provided here, which require changes elsewhere.
That's the only change required in the rest of the program, nothing else needs to be changed, the rest of the program will not need to know anything about the changes in the static class. Now you can set the instance to Redis somewhere during the start-up of your application: SessionHelper.SetInstance(new RedisSessionHelper()). Public static void SetInstance(ISessionHelper instance) Private static ISessionHelper _Instance = new DatabaseSessionHelper() Now go back to your original static class, add a new static member of the interface type, instantiate the DatabaseSessionHelper by default, but allow for a different instance to be injected, and forward all calls to the instance: public static class SessionHelper Implementation taken from the static classĬlass RedisSessionHelper : ISessionHelper Also generate such a class using Redis instead of the database: public interface ISessionHelperĬlass DatabaseSessionHelper : ISessionHelper
Let's start with the simple example given by John Wu, with small modification (I assume that the class is also marked static): public static class SessionHelperĮxtract the interface, create a new (non-static) class implementing it by moving all the implementation details from the static class into the new class, and remove its static modifiers. The solution provided in Mike Feather's Legacy Code book is very similar to the solutions given above, but without any need to change the consumers of your static class.
0 kommentar(er)
