chapter three

3 Encoding Semantics in the Type System

 

This chapter covers

  • Exploring data’s meaning
  • Moving from meanings to constraints
  • Encoding meaning in the type system

In the previous chapter we explored what data is; now we’re going to explore what it means. It might sound abstract, but this pursuit of “meaning” is one of our primary tools for building rock solid systems. To quote Leslie Lamport, “It’s a good idea to understand a system before building it”. Data is how we build that foundational understanding.

Once we know what our data means, we have the simpler task of moving that meaning into code. We’ll explore techniques for representing data in Java’s type system. We’ll look at what works, what doesn’t, and how we can judge if our modeling is moving in the right direction.

3.1 “What does it mean?”

The process of figuring out what the data in a new domain means can be a daunting challenge even for experienced developers. What questions do you ask? Where do you start? How do you know when you’re done? If you try to solve everything at once, it’s easy to get overwhelmed. A good way to tackle the complexity is to just start with the most basic and fundamental question you could possibly ask: “what is this thing?”

3.1.1 Discovering more about your domain

3.1.2 The importance of understanding meaning

3.2 Capturing semantics in code

3.2.1 Detailed documentation and better variable names are not enough

3.2.2 Enforce invariants during construction

3.2.3 Types denote sets of values

3.3 Using the type system as a design tool

3.3.1 Balancing type specificity with abstraction

3.3.2 Scoping numeric types to specific ranges

3.3.3 Beware the String

3.4 Is all this effort worth it?

3.4.1 Do types only catch low hanging fruit?

3.5 What about performance?

3.6 Wrapping Up

3.7 Summary