OOP and overhead

Anon

Something that I've been thinking about lately is why some classes are so flat out huge. Why? The concern is that large classes are adding tons of overhead to the system that need not be there. It seems almost as though a class is created and every concievable method the person can create is thrown along with the kitchen sink.

Now I like using objects, but I also like thinking about what it is I'm doing. To that end, I am curious what others think about this topic. Does this not make sense. For example, an object just to maintain connections to a db and different objects for processing queries.

Let's hear it...

morpheus()

[deleted]

That's the ever-lasting dilemma.
Do you build one large library that you can use for every project, or do you write seperate smaller libraries for each project?

The biggest point is: is the overhead really a problem? in most cases I think you'll find that the overhead is quite acceptable, and in those cases having a large class that can do everything is simply easier to use.

nashirak

I have not played around too much with classes in PHP, but having a background in JAVA (almost all OOP), I would say if you had 1 class that was just ungodly big like you were talking about, then you have not done a proper job with OO programing. OO is not just about classes but breaking stuff down into smaller object.. for instance.. you might have a class that is a tableparse or something... well say that one of your tables might get input from a database... well instead of writing 1 big class file with just table and add methods to it, you could have a database table that extends parsetable. Now thats probably a bad example, but my philosophy is if you do classes right and do a good job OO programing the project there shouldnt been too much overhead. But mabye that is just me. 🙂

Anon

Hey Vince,

Are you the same person that wrote the Eclipse library?

It makes sense to consider the size of the project adn wonder if overhead is a problem based on this. However, it also seems possible that this can lead to bad practices.
Of course, that's up to the programmer to not be a bozo and think about what he's doing.

Personally, I like the idea of creating classes that will be used all the time in numerous projects large and small. To that end, write them small write out of the gate as opposed to having to come back and cut code bloat out of a class that has grown to large.

later on,
morpheus()

Anon

I agree with this for the most part. But you know what, this doesn't really seem to be the practice in the php world. In looking for a class to help ease the development of forms (it's getting old), all I found was huge hunks of code with poor interfaces. Including the one in the PEAR library.

If it's cool to write huge hunks of code like that and call them classes, what happens when you need to call multiple instances of a given bloated class?

Later on,
morpheus()

[deleted]

"Are you the same person that wrote the Eclipse library?"

Nope! :-)