1

In order to avoid a confusion within a method signature comprised of the same types, a class can be introduced to make it distinguishable from others.

Let me support a text description with an example in Java.

E.g., from:

public void foo(String bar, String baz, String qux, String quux);

to: 

public void foo(Bar bar, Baz baz, Qux qux, Quux quux);

with the class definitions like the following one:

public final class Bar {

    private String bar;

    public String getBar() {
        return bar;
    }

    public void setBar(String bar) {
        this.bar = bar;
    }
}

Is there a name for a such design pattern or a similar one?

Improve this question
8
  • 3
    It's not a design pattern, it's the third rule of object calisthenics : wrap all primitives and strings.
    – Steve Chamaillard
    Mar 15, 2018 at 4:27
  • 2
    That's not a design pattern, it's a code smell. Don't have methods that take four parameters of the same type, and definitely don't wrap each of them in a new type - that's not less confusing, just differently confusing. Have you considered using a Builder pattern (the Bloch one, not the GoF one)?
    – Eric Stein
    Mar 15, 2018 at 5:14
  • @EricStein, surely, that's an exaggerated example.
    – Pavel
    Mar 15, 2018 at 5:23
  • @SteveChamaillard, thank you! Will have a look at those rules.
    – Pavel
    Mar 15, 2018 at 5:23
  • 1
    @SteveChamaillard The presentation (fr.slideshare.net/rdohms/bettercode-phpbenelux212alternate/…) actually says "Wrap primitive types and string, if it has behavior" (slide 23). That's not the case here.
    – Eric Stein
    Mar 15, 2018 at 12:05

1 Answer 1

Reset to default
1

There are two possible cases here, and unfortunately your example is too simplified to tell which one of the two applies in your question:

  1. The parameter types represent some domain concept.
  2. The parameters actually are Strings.

In case #1, the types shouldn't have been Strings to begin with, they should have been domain types, such as FirstName, LastName, or Address. Darren Hobbs calls this the Tiny Types Pattern, but really, it's just correct design.

In case #2, what you are proposing is just wrong. The parameters are Strings, so their type should be String.

However, at least in case #2, it is highly likely that this piece of code violates some other guideline of good design and is, for example, doing too much work. Or, the parameters actually have a relationship with each other and shouldn't be separate parameters but rather an object.

I challenge you to give a real example of a method that takes 4 Strings as parameters and isn't violating good design somewhere. You might want to read the discussion about the Zero, One, Infinity Rule on the Wiki. @Steve Chamaillard mentioned the relationship to Object Callisthenics in his comment.

Note: As @Derek Elkins mentioned in his comment, the fact that you made your wrapper types mutable whereas the original type (String) is immutable, completely changes the semantics of the code! In my answer, I am assuming this mistake is corrected and the setter removed. (Veering off into very opinionated territory here, I suggest that you should never have setters, period.)

Improve this answer
1
  • Jörg, thank you for a comprehensive answer, the refereed articles are nice! doesn't look like a feasible task to provide a example of a method that takes four strings as parameters and doesn't break some good design principle. Though, the mutability aspect mentioned in your answer is opinionated, it looks valid for me as well.
    – Pavel
    Mar 19, 2018 at 3:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.