Tutorial :String vs. A new Data class



Question:

I overheard two of my colleagues arguing about whether or not to create a new data model class which only contains one string field and a setter and a getter for it. A program will then create a few objects of the class and put them in an array list. The guy who is storing them argue that there should be a new type while the guy who is getting the data said there is not point going through all this trouble while you can simple store string.

Personally I prefer creating a new type so we know what's being stored in the array list, but I don't have strong arguments to persuade the 'getting' data guy. Do you?

Sarah


Solution:1

... a new data model class which only contains one string field and a setter and a getter for it.

If it was just a getter, then it is not possible to say in general whether a String or a custom class is better. It depends on things like:

  • consistency with the rest of your data model,
  • anticipating whether you might want to change the representation,
  • anticipating whether you might want to implement validation when creating an instance, add helper methods, etc,
  • implications for memory usage or persistence (if they are even relevant).

(Personally, I would be inclined to use a plain String by default, and only use a custom class if for example, I knew that it was likely that a future representation change / refinement would be needed. In most situations, it is not a huge problem to change a String into custom class later ... if the need arises.)

However, the fact that there is proposed to be a setter for the field changes things significantly. Instances of the class will be mutable, where instances of String are not. On the one hand this could possibly be useful; e.g. where you actually need mutability. On the other hand, mutability would make the class somewhat risky for use in certain contexts; e.g. in sets and as keys in maps. And in other contexts you may need to copy the instances. (This would be unnecessary for an immutable wrapper class or a bare String.)

(The simple answer is to get rid of the setter, unless you really need it.)

There is also the issue that the semantics of equals will be different for a String and a custom wrapper. You may therefore need to override equals and hashCode to get a more intuitive semantic in the custom wrapper case. (And that relates back to the issue of a setter, and use of the class in collections.)


Solution:2

Wrap it in a class, if it matches the rest of your data model's design.

  • It gives you a label for the string so that you can tell what it represents at run time.
  • It makes it easier to take your entity and add additional fields, and behavior. (Which can be a likely occurrence>)

That said, the key is if it matches the rest of your data model's design... be consistent with what you already have.


Solution:3

Counterpoint to mschaef's answer:

Keep it as a string, if it matches the rest of your data model's design. (See how the opening sounds so important, even if I temper it with a sentence that basically says we don't know the answer?)

  • If you need a label saying what it is, add a comment. Cost = one line, total. Heck, for that matter, you need a line (or three) to comment your new class, anyway, so what's the class declaration for?
  • If you need to add additional fields later, you can refactor it then. You can't design for everything, and if you tried, you'd end up with a horrible mess.

As Yegge says, "the worst thing that can happen to a code base is size". Add a class declaration, a getter, a setter, now call those from everywhere that touches it, and you've added size to your code without an actual (i.e., non-hypothetical) purpose.


Solution:4

I disagree with the other answers:

It depends whether there's any real possibility of adding behavior to the type later [Matthew Flaschen]

No, it doesn’t. …

Never hurts to future-proof the design [Alex]

True, but not relevant here …

Personally, I would be inclined to use a plain String by default [Stephen C]

But this isn’t a matter of opinion. It’s a matter of design decisions:

Is the entity you store logically a string, a piece of text? If yes, then store a string (ignoring the setter issue).

If not â€" then do not store a string. That data may be stored as a string is an implementation detail, it should not be reflected in your code.

For the second point it’s irrelevant whether you might want to add behaviour later on. All that matters is that in a strongly typed language, the data type should describe the logical entity. If you handle things that are not text (but may be represented by text, may contain text …) then use a class that internally stores said text. Do not store the text directly.

This is the whole point of abstraction and strong typing: let the types represent the semantics of your code.

And finally:

As Yegge says, "the worst thing that can happen to a code base is size". [Ken]

Well, this is so ironic. Have you read any of Steve Yegge’s blog posts? I haven’t, they’re just too damn long.


Solution:5

It depends whether there's any real possibility of adding behavior to the type later. Even if the getters and setters are trivial now, a type makes sense if there is a real chance they could do something later. Otherwise, clear variable names should be sufficient.


Solution:6

In the time spent discussing whether to wrap it in a class, it could be wrapped and done with. Never hurts to future-proof the design, especially when it only takes minimal effort.


Solution:7

I see no reason why the String should be wrapped in a class. The basic perception behind the discussion is, the need of time is a String object. If it gets augmented later, get it refactored then. Why add unnecessary code in the name of future proofing.


Solution:8

Wrapping it in a class provides you with more type safety - in your model you can then only use instances of the wrapper class, and you can't easily make a mistake where you put a string that contains something different into the model.

However, it does add overhead, extra complexity and verbosity to your code.


Note:If u also have question or solution just comment us below or mail us on toontricks1994@gmail.com
Previous
Next Post »