Now multiply five private methods by five public ones, and you get around twenty-five hidden methods that are probably going to be called only once by those public ones.
This is what is known as Encapsulation, which creates a Control Abstraction at the higher level. This is a good thing.
This means that anyone reading your code, when they get to the startTheEngine()
method in your code, can ignore all of the lower level details such as openIgnitionModule()
, turnDistributorMotor()
, sendSparksToSparkPlugs()
, injectFuelIntoCylinders()
, activateStarterSolenoid()
, and all of the other complex, small, functions that must be run in order to facilitate the much larger, more abstract function of startTheEngine()
.
Unless the problem you are dealing with in your code deals directly with one of those components, code maintainers can move on, ignoring the sandboxed, encapsulated functionality.
This also has the added advantage of making your code easier to test.. For instance, I can write a test case for turnAlternatorMotor(int revolutionRate)
and test it's functionality completely independent of the other systems. If there is a problem with that function and the output isn't what I expect, then I know what the problem is.
Code that isn't broken down into components is much harder to test. Suddenly, your maintainers are only looking at the would be abstraction instead of being able to dig down into measurable components.
My advice is to keep doing what you're doing as your code will scale, be easy to maintain, and can be used and updated for years to come.
You should extract code into its own class if it is conceivable that it would be called by code other than the current caller, in particular by code that doesn't do essentially the same thing.
A perfect example for code that should be independent would be code that simply constructs the days of the week. Many conceivable callers could use this, therefore it is a good idea to factor it out even if there is actually only one caller and this will probably not change. The reason is simply that it is easier to think about only one task at a time: either date calculation or parking logic.
If your code does date manipulation and parking business logic it is less clear that this is functionality that could be used differently. You know better than we whether this is the case, but it might be.
A counterexample is a routine that performs complicated calculations on a line item in a complicated workflow (e.g. declaring taxes, verifying space shuttle code). Such special-purpose code is almost certainly of no use outside the context it is now in. Such code should certainly go into its own method, but a separate class is often overkill.
Best Answer
Just because you can omit linefeeds and indentations and your C# compiler will still understand what you want to tell it, it's not automatically a good idea to do that.
is much less readable to the human reader than:
And that's the whole point here—programs are written for two audiences:
The latter is the one who needs to understand and quickly grasp the meaning of what is written. Because of this there are a few good practices that have emerged over the years and are more or less commonly accepted quasi-standards. One of them is putting explicit scope keywords, another example is putting extra parentheses around complex expressions, even in cases where they would not be needed syntactically, like: