3 ms·

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 col

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.

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.