I want to create a class ProcessHandler for Windows that pretty much uses the WINAPI.
The class ProcessHandler should be able to scan memory, emulate keyboard and mouse, needs some DLLInjector, some hooking, and provides some process information. Since I want to use some design principles, I think I should split every part into their own classes (class MemoryScanner for example) and then let ProcessHandler just use the class.
Do I then just redefine (wrap around) the ArrayOfByte method of ProcessHandler like that
ArrayOfByteScan(){
return memoryscanner.ArrayOfByteScan()
}
Is this a valid approach? And considered good design?
I also dont like that every class (if I do it like that) has its own HANDLE datatype. For example, the class MemoryScanner and DLLInjector will need it. Is there also a different approach for that?
I have never applied any design patterns/principles and my usual approach would just be writing every method inside ProcessHandler.
3
The way you described it, your ProcessHandler will be a facade to all the other classes you mentioned like MemoryScanner, KeyboardEmulator etc., which provide “parts” of the containing ProcessHandler object. Splitting up the different responsibility to different classes is fine, that is a perfect example of the single responsibility priciple. You know that you have done the split-up correctly when you can develop unit tests for each of the “parts” of the ProcessHandler and test it in isolation.
For avoiding the need for a duplicate process handle, for the shown example it is probably most simple to make the handle a parameter of the called methods and pass it from the ProcessHandler object to the aggregate objects, like
ArrayOfByteScan(){
return memoryscanner.ArrayOfByteScan(handle)
}
For more complex scenarios, one could create an interface / abstract base class IHandlerContainer with a virtual method GetHandler, and inject a pointer to an IHandlerContainer into each of the parts at construction time. Then, ProcessHandler can be derived from that interface, and let the ProcessHandler constructor look roughly like
ProcessHandler::ProcessHandler()
:memoryscanner(this), keyboardEmulator(this)
{ ...
}
That will give an object like memoryscanner access to the handle inside ProcessHandler without creating a cyclic dependency between those two classes.
2