Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
[Proposal] Embrace dependency injection vs super class extension #25
I just need to get a blessing on this from you guys before we move forward with any major refactors.
Single Responsibility Violations
Right now we have to extend the super class in order to add custom functionality. For example if I wanted to use my own persistent data storage handler, I'd need to extend the
There are a few problems with this type of customizability.
As it stands,
It's also causing other issues as pointed out in #8. :)
So it needs to be refactored. We need to pull out the persistent store methods into their own class that's concerned with nothing more than persistent data storage. This will also be helpful for future versions of the Graph API that might require we store persistent data for another class.
As pointed out in #4, a single responsibility violation also exists for the
Custom Named Classes Are A Bitch
Another issue with super class extension in this context is that all the existing nomenclature goes to hell and refactoring is a bitch. To be frank. :)
So you'd have some classes that are named
Dependency Injection To The Rescue!
Both of these issues can be fixed with a refactor (and they will be soon!) but I need your blessing on dependency injection with an interface.
If I can get your blessing on this (say yes!) then I'll start the refactor for both. But I have one more question on naming the interfaces. We have two main options.
I've used both conventions and I'm kinda loving on option 2. :)