How to write a class that uses other classes but needs the same functionality - should I just wrap around the methods?

Question

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.

enter image description here

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.

• Robert Harvey: en.wikipedia.org/wiki/Adapter_pattern
• Laiv: Correct me if I'm wrong. The question is how to make a single ProcessHandler to work with several and different Process. Right?
• Vaio: @Laiv no how to Design Code so i Can Split up one big class into small classes and then Reuse all classes inside the big class so they have all the functionalitys of the small classes. I think the answers with Adapter pattern and Dependency injection are the answer to my Problem but i still had no time to try it out tho (sry for Bad english)

Answer 1

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.

• Vaio: Hey thanks so much for pointing me to the right directions, didnt asked for more <3
• Vaio: Okay after further reading/coding and checking what adapter,decorator and facade pattern is this can safely be the accepted answer, thanks so much again