How/When to write reusable methods in OOP

Question

I often find myself in a situation where i am repeating two,three lines of code in a method multiple times and then think whether i should put that in a separate method to avoid code duplication. But then when i move those lines out of the method i find that the method just created is not reusable, was used only one time or requires an overload to be useful for another method.

My Question is what sort of patterns should we be looking for that indicate we should create a new method. I appreciate your response.

Answer 1

Don't put too much functionality in one method/class. Try to follow the single responsibility principle. It'll take some time getting familiar with that approach. But once you reach that level, you'll notice that it's done all by itself. Before coding, try to ask yourself, what functional units your concept includes.

For example, you want to develop an application, that can index the content of pdf files. It's just fictional, but at first sight, I could identify at least three components:

1. PdfParser - this provides you with the content of a pdf
2. Indexer - gets input from parser and counts meaningful words
3. Repository - it's for persistence; this could be made generic; so just say repository.Get<IndexData>(filename) or something

You should also try to code against interfaces. Especially when some kind of UI is involved. For example, you are developing a chat client with WinForms. If you follow the MVC/MVVM-pattern, you can easily (i.e., easier than coding against a Form object) use your original logic with a WPF version of the client.

Answer 2

I would start by reading about the DRY principle (Don't Repeat Yourself) hopefully it will give you a good answer for your question, which is a question that all developers should be asking themselves by the way, great question!!

See Don't repeat yourself

I wanted to leave it at DRY because it is such a simple but powerful concept that will need some reading and a lot of practice to get good add. But let me try to answer directly to your question (IMHO),

If you can't give your method a name that reflects exactly what your method is doing, break it into pieces that have meaning.

You'll find yourself DRYing up your code with ease, reusable pieces will show up, and you probably will never find yourself repeating code.

I would do this even if it meant having methods with only couple of lines of code.

Following this practice will give meaning to your code, make it readable and predictable, and definitely more reusable

Answer 3

If the lines of code that you intend to move to another method perform a specific set of actions (like read a file, calculate a value, etc.) then it is best to refactor into another helper method. Again, do this only if the helper method is being called at several places in your code or if your caller method is too long (definition of too long depends on the developer).

Similar questions

• How do programmers practice code reuse
• What techniques do you use to maximise code reuse?
• Code Reusability: Is it worth it?
• Coding Priorities: Performance, Maintainability, Reusability?

Answer 4

As a general rule, always think of those situations as functional entities. If a piece of code functionally performs a task (complex string conversion, parsing, etc), you should write reusable method. If that function is specific to a certain type, then write an extension method.

Answer 5

You could create a local variable inside your function of type Action<> or Func<> and assign the code snippet to it. Then you can use it everywhere inside your function without polluting your class with too many little helper functions.

Answer 6

If you build a method for reusability, but don't use it in more than one place, then the reusability of you method isn't really verified. Extract methods when it makes sense, and redesign those methods for reusability when you actually have the opportunity to reuse code.