By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
445,797 Members | 1,848 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 445,797 IT Pros & Developers. It's quick & easy.

Dividing large classes

P: n/a
Let's say I have two classes, Foo and Bar, and a Bar object is a member
of Foo. Then I want to have Bar aware of Foo and able to call the
public members of it. I can think of two ways to do this:

1) Have a Foo pointer as a member of Bar.
2) Don't do this. If this is the case, Foo and Bar shouldn't be
separate classes, they should be combined.

Has anyone done something like this before? Is there any time when the
second option isn't true? I I like keeping my classes small, and I've
heard that it's good programming practicel. I have a class whose
implementation is approaching 2000 lines, and I'd really like to break
it into smaller classes, but then I run into this problem.

Dec 9 '05 #1
Share this Question
Share on Google+
3 Replies


P: n/a
* ra*****@gmail.com:
Let's say I have two classes, Foo and Bar, and a Bar object is a member
of Foo. Then I want to have Bar aware of Foo and able to call the
public members of it. I can think of two ways to do this:

1) Have a Foo pointer as a member of Bar.
2) Don't do this. If this is the case, Foo and Bar shouldn't be
separate classes, they should be combined.

Has anyone done something like this before?
Yes, it's quite common. Java even has a language feature to do (1)
automatically.

Is there any time when the second option isn't true?
?
I I like keeping my classes small, and I've
heard that it's good programming practicel. I have a class whose
implementation is approaching 2000 lines, and I'd really like to break
it into smaller classes, but then I run into this problem.


Just use your option (1).

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Dec 9 '05 #2

P: n/a
> 1) Have a Foo pointer as a member of Bar.
2) Don't do this. If this is the case, Foo and Bar shouldn't be
separate classes, they should be combined.


Go with option 1.

Another possible design would be to use return values to obtain the
results from Bar and have the code in Foo update it's variables. That
way Bar does not depend upon Foo.

--
EventStudio System Designer 2.5 - http://www.EventHelix.com/EventStudio
Sequence Diagram Based System Design and Object Modeling Tool

Dec 9 '05 #3

P: n/a

ra*****@gmail.com wrote:
Let's say I have two classes, Foo and Bar, and a Bar object is a member
of Foo. Then I want to have Bar aware of Foo and able to call the
public members of it. I can think of two ways to do this: 1) Have a Foo pointer as a member of Bar.
You could also have a pointer (or reference) in Bar to a base-class
from which Foo derives.
2) Don't do this. If this is the case, Foo and Bar shouldn't be
separate classes, they should be combined. From what you have described they are tightly coupled as both depend on

each other. But if you get Bar to use a base-class of Foo then Bar will
no longer have a direct dependency on Foo and can be used with other
types as well that inherit from the same base class.

It is also possible, of course, that Foo could contain a pointer to a
base class from which Bar derives and call methods through that.

This would also reduce coupling and now neither Foo nor Bar would know
the full details of the other.

Dec 9 '05 #4

This discussion thread is closed

Replies have been disabled for this discussion.