Too many methods in a class?
Hey over there,
I was wondering if it makes sense to use a limit of how many methods to add to a class, to keep track of the scheme. I am not sure, wether I should try implementing any decomposed part into the class itsel, or let a few functions remain outside the class as "helper functions" for methods to call them.
But I believe this would be poor style...
How do You think about this?
I was wondering if it makes sense to use a limit of how many methods to add to a class, to keep track of the scheme. I am not sure, wether I should try implementing any decomposed part into the class itsel, or let a few functions remain outside the class as "helper functions" for methods to call them.
But I believe this would be poor style...
How do You think about this?
The public interface of a class often includes nonmember functions. All of which should be in the same namespace to allow ADL. Conversely, helper (nonmember) functions that are not logically part of the public interface should be in a nested namespace to disallow ADL.
As far as abstraction goes, if it makes sense to be in the interface, put it in the interface. It is recommended that classes model a single abstraction; avoid classes that attempt to provide too much.
As far as abstraction goes, if it makes sense to be in the interface, put it in the interface. It is recommended that classes model a single abstraction; avoid classes that attempt to provide too much.
Last edited on
A class with a lot of methods often times is an indicator that it is trying to do too much. The problem with doing too
much is that it does everything OK, but nothing well. Just like you can buy a combination copier, fax, and photo
printer -- and it will perform reasonably at all three tasks -- or you can buy a dedicated photo printer that does only
one thing, but does it very well.
much is that it does everything OK, but nothing well. Just like you can buy a combination copier, fax, and photo
printer -- and it will perform reasonably at all three tasks -- or you can buy a dedicated photo printer that does only
one thing, but does it very well.
I think we need to draw a fine line here. Too few classes implies trying to do too much. I have see other ppl code where they do the complete opposite. They have lot'sa small little classes in the whole project.
I was thinking does C++ support class nested within a class? Afterall, some of those little classes are created and they work together to achieve some SINGLE functionality. I was thinking have a class for that functionality and those little classes nested within. Is this syntax C++ compile-able ?
E.g
class A {
private:
class B {
...
}
...
}
Edit: Oops just try it out in Linux g++ and it compiles!!! Hooray!
I was thinking does C++ support class nested within a class? Afterall, some of those little classes are created and they work together to achieve some SINGLE functionality. I was thinking have a class for that functionality and those little classes nested within. Is this syntax C++ compile-able ?
E.g
class A {
private:
class B {
...
}
...
}
Edit: Oops just try it out in Linux g++ and it compiles!!! Hooray!
Last edited on
Topic archived. No new replies allowed.