Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

On the Use of Types in Java Programming

DZone's Guide to

On the Use of Types in Java Programming

· Java Zone
Free Resource

Build vs Buy a Data Quality Solution: Which is Best for You? Gain insights on a hybrid approach. Download white paper now!

Java is a typed language (duuhh!). It means that we can create new types like: 

public class User {
  private final string name;
 
  public User(String aName) {
  this.name = aName;
  }
}

And we can later on bring Users live into the virtual world that is our app. If our app deals with objects and their interactions, we should care that those objects are of a given type. That’s why we define our app’s blueprint (Java code, for that matter).

If my app has two users, somewhere in my code I’ll find something similar to this:

User userJon = new User("Jon");
...
User userDoe = new User("Doe");

I’m bringing those two Users live and hold a reference to them, so I can control their behaviour :). These references are of a given type, and I can figure out what I can do with them when in my hands.

Knowing object’s types is pretty nice, because it expresses better the thoughts in code. It's easier to read, indeed. For people like me who have bad memory, it's great to remember :).

Now, my model evolves and my customer is telling me that a user has many friends who are also players in the virtual world! I start to model something like:

public class User {

  private final string name;
  private List<User> friendsList = new ArrayList<>();
 
  public User(String aName) {
  this.name = aName;
  }
  ...
  public List<User> getFriendsList() {
  return Collections.unmodifiableList(frinedsList);
  }
}

Clients of the User type can interact with the reference like:

List<Users> userFriends = user.getFriendsList();

P.S. – Java 7!

Pretty straight-forward! User’s clients know that when they send a message to a user object they will receive a list of users, and the client code defines meaning for that list of users as being the friends of the user, using the name userFriends for the reference, for that matter. Later in the code, the client may use this reference, and when it uses it knows the context of that list of users, it’s a list of friends, duhh!

Now, other guy may write this code:

List<Users> user = user.getFriendsList();
It’s still OK, but … later in the code the only context I would infer immediately from this reference is that it is a list of users, but it represents what? Oops, I lost myself in loads of complex code, give some help for the maintainer please! :)


Getting things worst, in pre generics era, I would model something like:

public class User {

  private final string name;
  private List friendsList;
 
  public User(String aName) {
  this.name = aName;
  }
 
  public List getFriendsList() {
  return Collections.unmodifiableList(friendsList);
  }
 
}

And later in my code, getting the user’s friends would look something like:

List users = user.getFriendsList();

Now I'm completely lost. So, I have a list of objects, but hey, their type may be users, since the name of the reference is trying to give a hint, but it may be wrong … who knows? This code knows:

Object obj = users.get(0);

if (obj instanceof User) {
  User = (User)Object;
}

Getting back in time!

The point here is that if the Java language has evolved its type system, so will I!

I would prefer to model something like this:

public class User {

  private final string name;
  private FriendsList friendsList = new FriendsList();
  public User(String aName) {
  this.name = aName;
  }
  ...
  public FriendsList getFriendsList() {
      return friendsList
  }
}
 
public class FriendsList {
  private final string name;
  private List<User> = new ArrayList<User>();
  ...
  public Iterator<User> getFriendsListIterator() {
  return friendsList.iterator();
  }
}

Now I have context everywhere. Since Java is a Strongly typed language, let’s use types. What do you think? 

Originally from: Did you know java is a typed language

Build vs Buy a Data Quality Solution: Which is Best for You? Maintaining high quality data is essential for operational efficiency, meaningful analytics and good long-term customer relationships. But, when dealing with multiple sources of data, data quality becomes complex, so you need to know when you should build a custom data quality tools effort over canned solutions. Download our whitepaper for more insights into a hybrid approach.

Topics:

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}