> One day in the name of a better UX you add an AJAX component to > this, and forget to copy across that check into the ajax endpoint. > Suddenly I can

> One day in the name of a better UX you add an AJAX component to > this, and forget to copy across that check into the ajax endpoint. > Suddenly I can change anyone's username, despite not being an admin. Your AuthContext library sounds like a very unusual solution to this problem. Yes, there should be a single, unduplicated piece of code that restricts users' ability to edit each others' usernames. But why does that code need to know where the user is in the software? Surely admin users can always edit other users' names regardless of whether they're in the admin panel, and the question of whether or not to show the UI for editing usernames is a front-end concern. It sounds like an unusual and unnecessary tight coupling between the front-end and the back-end. > Having an object that does a lot of stuff is not necessarily the > much-feared "God object", although it certainly can become that. > I've learned to become more fearful of the "God methods" instead I'd argue that both are more or less equally harmful symptoms of the same problem: code that isn't clean. There are a couple of paragraphs about this in Clean Code that I like: > At the same time, many developers fear that a large number of small, > single-purpose classes makes it more difficult to understand the > bigger picture. They are concerned that they must navigate from class > to class in order to figure out how a larger piece of work gets > accomplished. > However, a system with many small classes has no more moving parts > than a system with a few large classes. There is just as much to > learn in the system with a few large classes. So the question is: Do > you want your tools organized into toolboxes with many small drawers > each containing well-defined and well--labeled components? Or do you > want a few drawers that you just toss everything into?