re: Private methods are a code smell VIEW POST

TOP OF THREAD FULL DISCUSSION
re: Why isn't the motor a private/module/package class? I ask because I not sure adding an additional layer to eliminate a private class really helps i...
 

Why isn't the motor a private/module/package class?

Having private classes is the same as having private methods. It hides information that could be public. A Motor is just as a valid and standalone class as a Car is. Why should we hide functionality from being reused?

I not sure adding an additional layer to eliminate a private class really helps in readability or function

That's exactly my point. You'll end up with more classes in the end, each of which is more concise and properly adhering to the SRP than the class with private stuff in it. Having more specialized small parts is usually better than having a smaller number with less clear boundaries.

 

Adhering to the SRP just to adhere to it isn't helpful in writing "better" code.

I'm not a huge fan of the access modifiers, I generally find that I want access to most things at some point. But that is still different than a new class needs to be created so we can jump through additional objects to reach the programs logic.

Adhering to the SRP just to adhere to it isn't helpful in writing "better" code.

The SRP is in my opinion the single most important guideline in writing clean code. I've never seen code getting worse while adhering to the SRP.

I generally find that I want access to most things at some point.

Exactly, thus everything should be as public as possible.

But that is still different than a new class needs to be created so we can jump through additional objects to reach the programs logic.

If you want to have every piece of functionality publicly available you won't get around to extracting to multiple smaller pieces at some point. When a software system grows you have to split up. And having to search for logic in many specific classes is easier than having to look for it in hidden private methods that logically don't belong where they are.

And having to search for logic in many specific classes is easier than having to look for it in hidden private methods that logically don't belong where they are.

As nice as that sounds, private methods don't actually hide logic, I just don't see myself doing a search in the way you're describing it happens.

It's weird because I agree and disagree at the same time. I generally don't think class are required for most logic, they should generally be free functions which operate on the class/data. This way your class keeps its single responsibility and you have functions with one responsibility.

private methods don't actually hide logic.

They usually do though, which is (in my experience) the main reason for them to be private (which this post details).

I generally don't think class are required for most logic, they should generally be free functions which operate on the class/data. This way your class keeps its single responsibility and you have functions with one responsibility.

Neither do I, it heavily depends on the language you're using. A lot of languages don't require you to use classes to encapsulate logic. Using classes actually enables the use of private logic. Using functional approaches leads to treating each function as a valid public entity, generally leading to less running into the "private code smell".

code of conduct - report abuse