Your DeletePicture(int pictureId) example could be a method of a class (let's call it PictureManager) that depends on an ISecurityContext implementation (or an IPictureDataProvider whose concrete class depends on an ISecurityContext, or any other runtime configuration that happens to be appropriate). The nice bit about that is you can abstract the security portion away, and test your class in isolation. Your example actually is indicative of one of the sources of many bugs: coupling. You're coupling the responsibility of every piece of code to security. What if someone then comes along and says, "We now have a priority to gather analytics on our API. This is just as high a priority and just as critical as security." Your way means modifying the method signatures of every method in the system. That's bad design. Go back to school, kid. You've got a lot to learn.