4 ms·

This is interesting, but I'm not sure how practical it is. Has anyone ever tried this approach successfully?

j_baker 17y ago
Bear something in mind: a code smell isn't something that's bad. It's something that indicates that something may be bad. Therefore, don't run out and refactor all your classes with private methods. However, if there is a class that has a lot of methods that you're not comfortable exposing to the outside world, then there's a good chance that there's a way to split that class and make your code easier to maintain. Either that or you're being too picky with what methods the outside world can access.
- revolvingcur 17y ago
  I feel that the connotation of "code smell" is a little stronger than what you state, but mostly I take umbrage to this statement: "Moving these methods to collaborators and making them public creates opportunities for future reuse without reducing the clarity of the original code." This is the crux of the argument. After all, if you aren't planning for reuse, there's very little motivation to create a collaborating class unless the main class really is getting excessively large. But if you're guessing at future refactorings, especially when dealing with the types of specialized methods being discussed, you're probably optimizing prematurely. I do strongly agree that private methods often have unnecessary dependencies. But this is a different design issue.
  - stcredzero 17y ago
    "Moving these methods to collaborators and making them public creates opportunities for future reuse without reducing the clarity of the original code." That's not even always true. Sometimes, the best way to express an algorithm may be with a recursive function. Making those separate objects might even slightly reduce the code's clarity. The code smell here should not be the private methods. It should be such private methods with similar functions repeated in several objects. Let "a need for reuse" become self evident, then refactor for reuse. Otherwise, you are just pre-optimizing. YAGNI!
  - j_baker 17y ago
    Well, according to Martin Fowler: "The second is that smells don't always indicate a problem. Some long methods are just fine. You have to look deeper to see if there is an underlying problem there - smells aren't inherently bad on their own - they are often an indicator of a problem rather than the problem themselves." http://martinfowler.com/bliki/CodeSmell.html http://martinfowler.com/bliki/CodeSmell.html Granted, you don't have to agree with Martin Fowler. I'm just making the case that it's not unreasonable for me (or the article's author) to define code smells that way.
- deleted 17y ago
  [deleted]
michaelcampbell 17y ago
Yeah, I'd like to see an example of this showing where the creation of the private method to begin with seemed like a good idea, this refactoring technique, and how doing so improved anything. Stating something is a smell doesn't make it so.

Bear something in mind: a code smell isn't something that's bad. It's something that indicates that something may be bad. Therefore, don't run out and refactor all your classes with private methods. However, if there is a class that has a lot of methods that you're not comfortable exposing to the outside world, then there's a good chance that there's a way to split that class and make your code easier to maintain. Either that or you're being too picky with what methods the outside world can access.

revolvingcur 17y ago
I feel that the connotation of "code smell" is a little stronger than what you state, but mostly I take umbrage to this statement: "Moving these methods to collaborators and making them public creates opportunities for future reuse without reducing the clarity of the original code." This is the crux of the argument. After all, if you aren't planning for reuse, there's very little motivation to create a collaborating class unless the main class really is getting excessively large. But if you're guessing at future refactorings, especially when dealing with the types of specialized methods being discussed, you're probably optimizing prematurely. I do strongly agree that private methods often have unnecessary dependencies. But this is a different design issue.
- stcredzero 17y ago
  "Moving these methods to collaborators and making them public creates opportunities for future reuse without reducing the clarity of the original code." That's not even always true. Sometimes, the best way to express an algorithm may be with a recursive function. Making those separate objects might even slightly reduce the code's clarity. The code smell here should not be the private methods. It should be such private methods with similar functions repeated in several objects. Let "a need for reuse" become self evident, then refactor for reuse. Otherwise, you are just pre-optimizing. YAGNI!
- j_baker 17y ago
  Well, according to Martin Fowler: "The second is that smells don't always indicate a problem. Some long methods are just fine. You have to look deeper to see if there is an underlying problem there - smells aren't inherently bad on their own - they are often an indicator of a problem rather than the problem themselves." http://martinfowler.com/bliki/CodeSmell.html http://martinfowler.com/bliki/CodeSmell.html Granted, you don't have to agree with Martin Fowler. I'm just making the case that it's not unreasonable for me (or the article's author) to define code smells that way.
deleted 17y ago
[deleted]

michaelcampbell 17y ago

Yeah, I'd like to see an example of this showing where the creation of the private method to begin with seemed like a good idea, this refactoring technique, and how doing so improved anything. Stating something is a smell doesn't make it so.