What is the biggest drawbacks on creating classes of everything? Instead of String name = person.getName() it would be Name name = person.getName();

What is the biggest drawbacks if I were to create type of everything, instead of using Strings and primitive types?

Normally it would look like:

String name = person.getName();
int age = person.getAge();

But now "everything" is objectified, you seldom handle Strings (unless you need specific String manipulation).

Name name = person.getName();
Age age = person.getAge();

W开发者_StackOverflow社区here Name and Age would be (in this example) simple container classes:

public class Name {

    private final String name;

    public Name(final String name) {
        this.name = name;
    }

    @Overide
    public String toString() {
        return name;
    }

}

However, in the future, they can have more more methods and validations, etc.

But the bottom line is that you basically create types for everything.

I know this makes the code more type safe, but what are the biggest drawbacks for this kind of code convention?

---

The code gets more verbose and not all libraries deal equally well with this pattern.

I try to strike a balance in Java code, I use quite a lot of primitives and strings, but some data types, such as monetary amounts and social security numbers get their own dedicated classes. An SSN has its internal validation rules. Monetary calculations benefit from explicit control over rounding and guards against adding amounts in different currency.

In languages less verbose than Java, I tend to use more of these dedicated classes than I do in Java.

---

The only real drawback to this is that the more code you write, the more code you have to maintain and test. Theoretically this is a great idea. It's the practical side that causes the issues.

---

• It's unnecessarily verbose
• You may lose immutability (in this case Name is immutable, but it's more error prone)

If you need more fields later you can easily add them. Keep your code as simple as possible.

---

Class Explosion will make your code difficult to follow and understand.

When someone sees String name, they know immediately what that object is. All java developers know about the String class. When someone sees Name name, they have no idea what the Name class is. What does it do? What functionality does it add?

If this class only just extends Name and does nothing else, then it's pointless and a waste of time for a developer coming in to work on the code. If this class does do something else, then of course you need to make the class to get the functionality.

Bottom line: if you're adding extra functionality, create your own class. If you just need the functionality in String, then just use String. You can always create Name and refactor later if you need additional functionality.

---

I would not recommend this, for the simple reason if you are integrating with other systems (e.g. web services in different parts of the organisation or third-party vendors, you'll end up having to deal with Strings and int's anyway and you'll have to make your code even more complex by having to wrap names in Name objects when you get them from other systems and unwrapping them when you want to post them to other systems.

I'd say Keep it Simple, and validation could easily be introduced using bean validation JSR-303.

Also, what happens if you needed different validation rules for Names on different objects, e.g. an organisation name is different from a person name, before you know it you'll have a whole class hierarchy to deal with which if you want to change a name would be a refactoring nightmare.

---

There have been times when I regretted not creating classes for object that were represented by simple strings (venue and tour of a concert being examples). I did this to follow the KISS principle for what was expected to be a very simple application

I can't remember that I ever regretted creating a class in such cases. There's certainly some more maintenance and boiler plate involved. But still, from a gut feeling, if you feel it could pay off in the future (refactoring, maybe even performance) I'd say go for it. It's a small investment that can save you from major headaches. But try not to overdo it.