Constructor Parameters vs Method Parameters?

Question

A very simple question really and I expect an answer of 'circumstance dictates'. I was wondering however what people's thoughts are on passing parameters to a constructor or a method.

I'll try and set a context for my question:

public interface ICopier
{
   void Copy();
}

public class FileCopier : ICopier
{
   String m_source;
   String m_destiniation;

   FileCopier(String source_, String destination_)
   {
        m_source = source_;
        m_destiniation = destiniation_;
   }

   public void Copy()
   {
        File.Copy(m_source, m_destiniation, true);
   }
}

Or should FileCopier.Copy() accept source_ and destination_ as method parameters?

I want to keep these classes as abstract as possible.

I'm asking this question as I now have other interfaces/classes for Deleting, Renaming and so on, and I want to create a standard for doing this.

Thanks!

Answer 1

It depends :)

Basically, object-orientation states that objects should encapsulate data and behavior. When you pass data as constructor parameters, you indicate that this is the data to encapsulate.

On the other hand, when you pass data as parameters, you indicate that this is data that somehow is less coupled to the object. Once you begin to move towards Data Context Interaction (DCI), lots of objects tend more and more to encapsulate behavior rather than data.

At the same time, the book Clean Code also guides us to limit the number of method parameters, towards the ultimate conclusion that a method with no parameters is the best design of all.

So I would tend towards encapsulating the data by passing it as constructor parameters in order to have simple APIs. It would then look much like a Command object.

Answer 2

Pass them to the method. That way you can copy to more than one location without having to reinstantiate FileCopier, and do other operations that may require other params. In this case you can make the methods static, so no instantiation is needed at all. You'll noticed this is the way the C# File class works, for example.

Answer 3

It also depends if the application is staless or stateful. On a stateful architecture probably I'd choose passing the parameters on the constructor, allowing me to save that object and call the already initialized instance multiple times. On a stateless application you'd have to create the object's state everytime you create an instance of the object, which is kinda redundant, so I'd choosing passing those parameters on the method for a clearer interface.

Answer 4

Generally speaking, it is better to avoid adding unnecessary state to a class. Meaning, that if some data items are only needed in the context of a specific operation, you would usually prefer to have them only as local variables in the method, and pass them as parameters.

This way your code will also tend to be less error-prone, because there will be less unnecessary state that is shared between methods, so less potential for bugs.

You should pass parameters to the constructor when you want to enforce that the values should never change during the usage of the class.

It probably doesn't make sense to create a FileCopier object that can only copy a specific file, so in your case a method is more appropriate.

On the other hand, if you have to manage state for each copying operation, such as progress tracking, error tracking, completion callbacks etc, it would make more sense to pass the parameters in the constructor, but also add enforcement that will prevent Copy from being called more than once.

Answer 5

Old question but it seems a lot of people are answering without considering the intent of the ICopier abstraction. As Saurabh stated, making it copy(String, String) (and adjusting the interface accordingly) will mean any other implementations of ICopier will be limited to using this method.

What if you need to extend it to create an EmailCopier that sends a file from a source to a list of emails instead of a destination file? You could write a hacky method that continues to accept (String, String):

ICopier copier = new EmailCopier();
copier.copy(sourceFile, "an@email.com,another@email.com");

Or you could put all this info in the constructor using proper data structures and a simple copy() command:

ICopier copier = new EmailCopier("sourceFile', aListOfEmails);
copier.copy();

To summarise, if the implementations of the interface will have largely different parameters, you should use constructor parameters with a simple command. If all the implementations are operating on the same inputs, method parameters are fine.

Answer 6

I recently found the following rule "If the parameter is used because of the implementation then put it in the constructor, if the parameter is used because of the interface then put it in the method".

The problem is you don't have any comment above the Copy method :

• If it's "copy one file from a destination to a source" then you should add source and destination parameters because you speak about it on the interface description
• if it's "when overriden copy something" then add it on the constructor because only your FileCopier implementation will need it

Answer 7

It is all about usage;

Which one is easier for you?

FileCopier f = new FileCopier(sourceFrom,sourceTo);
f.Copy();

or

FileCopier f = new FileCopier();
f.Copy(sourceFrom,sourceTo);

I prefer the second not only because it is easier to read but also, you don't have to re-create the object once your paths are changed. It is not a very good idea to set sources in the ctor. But again, it may only be me.

Answer 8

i would prefer constructor taking arguments becuase responsibility of FileCopier is to copy the file from source to destination and the Interface which it is implementing can be used with other hetrogeneous classes so if you provide the parameters to the Copy() function , it will become more specific but in the current state , it can be used in many places which requires the copy functionality

Answer 9

Unless there are a lot of other methods that operate on the source and destination files that you've not shown us, FileCopier should probably be a static class and not store the file paths as class-level variables at all. Rather, all of the individual methods of the class should accept the files to be operated upon (and any other necessary information or settings) as parameters. That way, you won't have to instantiate an instance of the class each time you want to copy a file.

FileCopier fc = new FileCopier(src, dest);
fc.Copy();

versus

FileCopier.Copy(src, dest);

The best example of what I'm talking about here is the System.Math class in the .NET Framework. The System.IO.File class also works this way (and begs the question of why you're recreating it).

Answer 10

wrt to your context it is better to pass parameter to method if you only have a copy method within your class . But passing them to constructor can be helpful if you have to do multiple operations using the same object.

for example :

    public class FileCopier : ICopier
    {
       String m_source;
       String m_destiniation;

       FileCopier(String source_, String destination_)
       {
            m_source = source_;
            m_destiniation = destiniation_;
       }

       public void Copy()
       {
            File.Copy(m_source, m_destiniation, true);
       }

       public void DeleteSource()
       {
       }

       public void DeleteCestination()
       {
       }

  etc...
    }

Answer 11

Strange that no one mentioned about your interface ICopier.

Just looking at this interface, I would pass the arguments in the method itself. Since, it is a contract it should also force the objects implementing this interface to accept the legitimate arguments to complete/implement the task.

If ICopier is asking for implementation of Copy(), it should also provide the values/arguments needed to accomplish the task.