I'm working on a project with a MVP architecture.
My program revolve around forms that give rights to people.
There are X differents forms depending on profiles ( so there are X differents profiles)
I have an abstract class which we will call BasicFormClass.
Each forms has a presentation that inherits from BasicFormClass
The more I work on this project, the more I observe my presentations becoming "fat", especially BasicFormClass : a lot of functionnality are called and execute by it.

So my question is : Is a presentation potentially a god object?

  • This depends on what functionality you put into the presentation classes and the base class. If it is not directly related to the presentation, it should be extracted to separate classes.
    – JacquesB
    Apr 18, 2018 at 8:46
  • Functionnalities are: crypting content, checking content of fields ,etc. but even if it's in separate class, if the calls are done by the presentation isn't it the same trough the eye of the "god object" problem ?
    – Freddykong
    Apr 18, 2018 at 9:00
  • Possible duplicate of What is the real responsibility of a class?
    – gnat
    Apr 18, 2018 at 9:11
  • 1
    @Freddykong: It depends if the calls logically belong in the presentation layer or not. You might legitimately have a complex presentation layer, but if it does things like calling the database or a network service, then you haven't separated responsibilities correctly.
    – JacquesB
    Apr 18, 2018 at 10:27
  • 1
    @Freddykong BasicFormClass can be heavily involved without doing most of the work. You can create user controls to group logic in its own class, or create an event handler. It's only a god class if it contains most of the logic. Decide what must be handled in the BasicFormClass and what can be delegated elsewhere. Does that answer your question?
    – Neil
    Apr 18, 2018 at 12:44

1 Answer 1


Is it getting fat from low-level statements or because the complexity is increasing? If it is the latter, use a helper class to reduce the bulk. If it is the former, consider refactoring common tasks and handlers to allow handler classes to deal with such things (bonus points if derived classes can make use of them as well).

Your BaseFormClass is only a god class if it contains all the logic. There is nothing wrong with BaseFormClass delegating tasks to other classes, thereby freeing up BaseFormClass to the very basic decisions necessary for your class to work.

Consider creating an event handler or user controls to help separate smaller responsibilities handled in BaseFormClass into their own classes. Good luck!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.