Jump to content

  • Log In with Google      Sign In   
  • Create Account


#ActualKylotan

Posted 05 April 2013 - 11:07 AM

Say I have a class that just gets more and more methods, and I decided to split its responsibilities - how should I tie it up back together? This is the thing that makes me most unsure. I can't even give you a practiacal example

 

An abstract problem can only have an equally abstract answer.

 

But on the whole, if you separate 2 objects and you find they end up needing access to the internals of the other object, then you've done something wrong. The point is to create smaller objects that communicate via a minimal interface. The information they yield to the outside world should be on a need-to-know basis - that's the foundation of proper encapsulation and object-orientation more generally. So if you're worrying about how to expose the internals of your new object, you're thinking about it the wrong way.

 

I think one of the most important skills a programmer can develop is to see a large lump of vaguely related functionality and learn how to split it up so that there's a minimal interface between them. Sometimes you can do this by trial and error. Cut and paste the relevant functions from one class and put them into a new class. Hit compile. Compiler will tell you that you're missing several member variables and maybe other functions. So think about whether they can or should be moved to the new class too. You usually find that most stuff fits neatly into one side or the other, if you picked a good dividing line. And the bits that don't fit, you can work around either by passing in the data when the new object is created, or by having the new object query the old object, or occasionally refactoring the shared information out to a 3rd object.


#1Kylotan

Posted 05 April 2013 - 11:07 AM

Say I have a class that just gets more and more methods, and I decided to split its responsibilities - how should I tie it up back together? This is the thing that makes me most unsure. I can't even give you a practiacal example

 

An abstract problem can only have an equally abstract answer.

 

But on the whole, if you separate 2 objects and you find they end up needing access to the internals of the other object, then you've done something wrong. The point is to create smaller objects that communicate via the minimal interface. The information they yield to the outside world should be on a need-to-know basis - that's the foundation of proper encapsulation and object-orientation more generally. So if you're worrying about how to expose the internals of your new object, you're thinking about it the wrong way.

 

I think one of the most important skills a programmer can develop is to see a large lump of vaguely related functionality and learn how to split it up so that there's a minimal interface between them. Sometimes you can do this by trial and error. Cut and paste the relevant functions from one class and put them into a new class. Hit compile. Compiler will tell you that you're missing several member variables and maybe other functions. So think about whether they can or should be moved to the new class too. You usually find that most stuff fits neatly into one side or the other, if you picked a good dividing line. And the bits that don't fit, you can work around either by passing in the data when the new object is created, or by having the new object query the old object, or occasionally refactoring the shared information out to a 3rd object.


PARTNERS