Hi all

I have found 2 approaches in Object Oriented programming:

1. Creating a "master" class that contains all classes, and creating a method for each operation. (With this approach you only have to pass the "master" class throughout different GUI screens)
2. Using only the classes you need in the GUI (Then you have to see you pass through the appropriate classes)

I find that both approaches have their pro's and con's.
Using only the necessery classes fits my idea of OO better, but I'm not sure cause, well, as said, using a master class has it's advantages too.

If necessary I'll try to give some more specific pro's and con's, but I'll leave it to this for now.

What do you all think about this?

Thx in advance
Greets
K?!

Are you talking about an approach for a specific problem like GUI programming? Because you mention that problem but I'm not sure whether that's the context or just an example.

It is hard to understand from your post what you're describing, and a more concrete pair of examples with code, or just interfaces, would make your question clearer.

Well, now it is indeed for use with a GUI (well, web pages...). But I think it can be used as a general approach too (with or without GUI), just
"using one class containing all other classes and making a method(using the appropriate classes and their methods) for each action"
or
"using only the needed classes and building up the actions by using their methods"

It's kinda hard to give you a code example.
I don't have too much time right now, I'll try to post a more accurate example later on.

Grtz, K?!

So you want one class that has a whole heap of inner classes? What benefit does that give you?

For GUI: you only have to pass through that one class.

Other example: (I'm programming in php)
If a page has a list on it where the items represent objects (classes), I can not acces these objects themselves from the list, but only, for example, their ID's. If I pass a method to this superclass(here: "program"), like: "program.changePersonName(personId, name)", I can make this superclass search for the appropriate person to update.
When not using a super class, I have to let the GUI access the database, search for the person with that ID, and then let it create a new Person with it's data. After that I'm able to do something like "person.changeName(name)", after which the Person class will access the database (to update the data).
This also means that database connection is made in the GUI and in the actual program, while using a super class, this can be kept in the actual program.

Or you could just write the method for (in your example) Person to change the name themselves. ie., person->setName()
There is absolutely no need for a "superclass". Their true name is "god class" and it's referred to as an anti-pattern. They are the bane of good OOP principles. Don't make them. Just don't.

There is absolutely no reason you can't do

You could make the database access inside the Person constructor, it doesn't have to be in the GUI. I'm not entirely sure where you're getting this mindset.

Ok, thx.
Well, I heard it from a classmate. It felt kind of awkward indeed, but if it solved a problem, why not...
But I'll try solving the problems without using it.

Thx for the clear answer.

Grtz, K?!

To confirm his opinion: ShawnCPlus is absolutely correct. You'd be wise to follow his advice.