I am writing Portfolio module for my web site and it has 3 components. Gallery Category, Gallery, & Gallery Images.
I am doing all the request handling, (creating, reading, updating, other), for the above 3 components in 1 class, Portfolio.
DB handling jobs for Portfolio module is done in another file.
My question is, even just for request handling purpose, can you do all the operations in 1 class?


  • 2
    Based on what you write this smells like a God object. Can you post the code? It is hard to really answer without seeing what you are doing.
    – Jeff
    Jun 23, 2011 at 11:32
  • What is a God object?
    – jp2code
    Jun 23, 2011 at 13:15
  • 1
    @jp2code A "God Object" is an object that does many things that aren't necessarily related to itself instead of delegating to other objects; the connotation being that it is "playing God" by being involved in everything and being everywhere. Jun 23, 2011 at 13:29

3 Answers 3


You have to go back to the basics - coupling and cohesion. Coupling is how much a class depends on other classes, and cohesion is how well it does the job it is intended to do. Ideally, you want to lower coupling and raise cohesion. In other words - decoupled objects that do its one job well - without a whole bunch of other responsibilities.

It sounds like when you create your "Portfolio" class you are trying to make it do a lot of different jobs. Not only will this create coupling with the other objects, but will lower cohesion in that it must do things that it really is not intended for.

I wouldn't go down that path - it is only inviting maintenence issues in the long run.


If you have a CreatePortfolio and CreateGallery method in the same object, that smells. A Gallery should have a collection of Portfolios (or whatever) that you can call .Add on, and get an instance of IPortfolio back, so you can separate out the concerns.


You can do it all in one class; if you should is another matter entirely. I personally loathe and avoid God objects. This is C# not VB6; you don't need to use "Modules" that lump together related functions (sorry for the tone there, pet peeve because at work our code has a lot of these "C# Module" classes, one class with dozens of semi-related static methods); properly separate your concerns into different classes.

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.