Charles Lambert
Charles Lambert

Reputation: 5132

Are there any anti-pattern names for writing code like this?

Here is some code that uses a parameter class to contain the possible parameters to the Show() method. The values in this FooOption class aren't very related. You can see this by looking at the implementation of Show() below. I know this is bad code, but are there any anti-patterns related to doing this?

class FooOptions {
  public int? Id { get; set; }
  public string BazContext { get; set; }
  public int? BazId { get; set; }
}

class BarMgr {
  public Bar Show(FooOptions options) {
    if (options == null)
      options = new FooOptions();
    if (options.Id.HasValue)
      return svc.GetBar(options.Id.Value);
    if (!string.IsNullOrEmpty(options.BazContext) && options.BazId.HasValue)
      return svc.GetBar(options.BazContext, options.BazId.Value);
    return null;
  }
}

Update: I know that parameter objects are not an anti-pattern. In my experience, parameter object properties are related. This is the possible anti-pattern that I am trying to locate. setting all three properties makes no sense.

Upvotes: 1

Views: 471

Answers (3)

ralphtheninja
ralphtheninja

Reputation: 132988

There might be an anti-pattern if you use options a lot we have something called feature envy and is an indication that you might want to move functionality into the actual feature being used.

Upvotes: 2

Daniel Hilgarth
Daniel Hilgarth

Reputation: 174299

After your update, here my answer:
As far as I know, there is no real name for an anti-pattern like this, but there is at least one principle that this method violates:
The Single-Responsibility-Principle.

And it really is a problem of the method and not of the parameter object.

Upvotes: 5

Ernest Friedman-Hill
Ernest Friedman-Hill

Reputation: 81684

It's called the parameter object pattern, and it's not considered an antipattern -- it's a good way to deal with methods that would otherwise have too many parameters.

Upvotes: 5

Related Questions