Is there a naming convention for a method that should set the properties of the passed object.

Question

Hello,

I am writing a method that will set the properties of an object passed as a parameter. The method accepts one parameter of type interface and the return type of the method is the same interface. I was wondering if there is some kind of a naming convention for such methods. I was thinking of something like:

FillInInterfaceTypeData or InitInterfaceTypeData but both sound clumsy to me. How do you think?

Answer 1

There are no hard and fast rules here. Both of those names sound good but I would normally use something like PopulateInterfaceTypeData.

Answer 2

FillInInterfaceTypeData sounds fine to me. Perhaps if you even specify shortly the kind of data I guess all fits in. It all depends on the context after all.

Answer 3

Depending on what kind of language you use: If it supports dynamic binding, you could drop the "TypeData" suffix and let the runtime do its work.

Just name your methods

SetDefaultsFor(Customer c) { ... }
SetDefaultsFor(Dog d)      { ... }

Answer 4

I think it depends on what you are populating the objects with and why?

Are you setting default values? In which case something like InitialiseTypeData or DefaultTypeData might made sense..

Are you perhaps clearing their values? Maybe the state of the objects is being moved to a different one. In which case something like DeactivateBankAccount or MakeUserMarried or whatever it is that is being done to the objects.

---

Beware of code smells Often (not always, of course) you will find if you are having difficulty naming the method, this is an indication that something is not quite right with the design which could lead to difficulty further down the line.

There may be other things you should consider in the design.

For example, if this method is setting default values, is this not something that should occur in the constructor of the class?

If the interface represents multiple class types that all need the same values, perhaps each of these classes could be separated out into 1 class which represents what is the same between each of these classes and another class that represents the difference..

ie.

interface IA
{
  int a;
  int b;
}
class X : IA
{
  int a;
  int b;
  int c:
}
class Y : IA
{
  int a;
  int b;
  int d:
}

could be refactored to

class A
{
  int a;
  int b;
}

class X
{
  A a;
  int c:
}

class Y
{
  A a;
  int d:
}

Then the constructor of class A can set its default values. You no longer have to put any effort into thinking up a good function name. You also gain a more orthogonal system as well which is easier to test and cope with changes.

Obviously, this is probably not exactly your situation, Im just highlighting how when you struggle to find a good name, its because your design needs improving!