Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The God Object needs to be referenced at least transitively by the wrappers you hand out, and its API surface needs to grow constantly to encompass any possibly security-sensitive operation.

Dependency injection doesn't help here much, at least not with today's languages and injectors. The injector doesn't have any opinion on whether a piece of code should be given something or not, it just hands out whatever a dependency requests. And the injector often doesn't have enough information to precisely resolve what a piece of code needs or resolve it at the right time, so you need workarounds like injecting factories. It could be worth experimenting with a security-aware dependency injector, but if you gave it opinions about security it'd probably end up looking a lot like the SecurityManager did (some sort of config language with a billion fine grained permissions).



What is "injector"? Is this the Service Locator anti-pattern?

The application's entry point takes the God Object of capabilities, slices it accordingly to what it thinks its submodules should be able to access, and then initializes the submodules with the capabilities it has decided upon. Obviously, if some submodules declare that they need access to everything plus a kitchen sink, the choice is either a) give up and give them access to everything; b) look for a replacement that requires less capabilities.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: