|
| 1 | +--- |
| 2 | +title: Sample Chapter 5 - Beans to Values |
| 3 | +layout: sample |
| 4 | +--- |
| 5 | + |
| 6 | +Many Java projects have settled on mutable JavaBeans or POJO (plain old Java object) conventions for representing data. |
| 7 | +Mutability brings complications, though. |
| 8 | +Why are immutable values a better choice, and how can we reduce the cost of mutability in a codebase? |
| 9 | + |
| 10 | +## Beans |
| 11 | + |
| 12 | +As we discussed in the introduction, JavaBeans were introduced to allow the development of drag-and-drop GUI builders in the Visual Basic style. |
| 13 | +A developer could drop a button onto a form, change its title and icon, and then wire in an on-click handler. |
| 14 | +Behind the scenes, the GUI builder would write code to instantiate a button object and then call setters for the properties that the developer had changed. |
| 15 | + |
| 16 | +To define a JavaBean, a class needs a default (no-argument) constructor, getters for its properties, and setters for its mutable properties. (We'll gloss over the `Serializable` requirement, because even Sun never really took this seriously.) |
| 17 | +This makes sense for objects that have a lot of properties. |
| 18 | +GUI components typically have foreground and background colors, font, label, borders, size, alignments, paddings, and so on. |
| 19 | +Mostly the defaults for these properties are fine, so calling setters for just the special values minimizes the amount of code to be generated. |
| 20 | +Even today, a mutable component model is a solid choice for GUI toolkits. |
| 21 | + |
| 22 | +When JavaBeans were introduced, though, we thought of most objects as mutable, not just UI components. |
| 23 | +I mean, why not? The point of objects was to encapsulate properties and manage the relationships between them. |
| 24 | +They were _designed_ to solve problems like updating the width of a component when its bounds are changed, or the total of a shopping cart as items are added. |
| 25 | +Objects were the solution to the problem of managing mutable state. |
| 26 | +Java was quite radical at the time in having an immutable `String` class (although it couldn't help itself and still plumped for a mutable `Date`). |
| 27 | + |
| 28 | +As a profession, we have a more sophisticated understanding these days. |
| 29 | +We appreciate that we can use objects to represent different types of things—values, entities, services, actions, transactions, and so on. |
| 30 | +And yet the default pattern for a Java object is still the JavaBean, a mutable object with getters and setters for its properties. |
| 31 | +Although it may be appropriate for a UI toolkit, this is not a good default pattern. |
| 32 | +For most things that we want to represent with objects, a value would be better. |
| 33 | + |
| 34 | +## Values |
| 35 | + |
| 36 | +_Value_ is a much overloaded term in English. |
| 37 | +In computing, we say that variables, parameters, and fields have values: the primitive or reference that they are bound to. |
| 38 | +When we refer to _a value_ in this book, we are referring to a specific type of primitive or reference: those with value semantics. |
| 39 | +An object has value semantics if only its value is significant in its interactions, not its identity. |
| 40 | +Java primitives all have value semantics: every `7` is equal to every other `7`. |
| 41 | +Objects may or may not have value semantics though; in particular, mutable objects do not. |
| 42 | +In later chapters we'll look at finer distinctions, but for now, let's just define a _value_ to be an immutable piece of data, and a _value type_ to be a type that defines the behavior of an immutable piece of data. |
| 43 | + |
| 44 | +So `7` is a value, and the boxed `Integer` is a value type (because boxed types are immutable), `banana` is a value (because `String`s are immutable), a `URI` is a value (because `URI`s are immutable), but `java.util.Date` is not a value type (because we can call `setYear` and others on the date). |
| 45 | + |
| 46 | +An instance of an immutable `DBConnectionInfo` is a value, but an instance of `Database` is not a value, even if all its properties are immutable. This is because it is not a piece of data; it is a means of accessing, and mutating, pieces of data. |
| 47 | + |
| 48 | +Are JavaBeans values? |
| 49 | +UI component JavaBeans are not values because UI components aren't just data—two otherwise identical buttons have different identities. |
| 50 | +In the case of beans used to represent plain data, it will depend on whether they are immutable. |
| 51 | +It is possible to create immutable beans, but most developers would think of these more as plain old java objects. |
| 52 | + |
| 53 | +Are POJOs values? |
| 54 | +The term was coined to refer to classes that don't have to extend from framework types to be useful. |
| 55 | +They usually represent data and conform to the JavaBeans conventions for accessor methods. |
| 56 | +Many POJOs will not have a default constructor, but instead define constructors to initialize properties that don't have sensible defaults. |
| 57 | +Because of this, immutable POJOs are common and may have value semantics. |
| 58 | +Mutable POJOs still seem to be the default though, so much so that many people consider that object-oriented programming in Java is synonymous with mutable objects. |
| 59 | +Mutable POJOs are not values. |
| 60 | + |
| 61 | +In summary, a bean could technically be a value but rarely is. |
| 62 | +POJOs more often have value semantics, especially in the modern Java age. |
| 63 | +So whereas _Beans to Values_ is snappy, in this chapter we're really looking at refactoring from mutable objects to immutable data, so maybe we should have called it __Mutable POJOs to Values__. |
| 64 | +We hope you'll forgive the sloppy title. |
| 65 | + |
| 66 | +## Why Should We Prefer Values? |
| 67 | + |
| 68 | +A value is immutable data. |
| 69 | +Why should we prefer immutable objects to mutable objects, and objects that represent data to other types of objects? |
| 70 | +This is a theme that we will visit time and again in this book. |
| 71 | +For now, let's just say that immutable objects are easier to reason about because they don't change, and so: |
| 72 | + |
| 73 | +* We can put them into sets or use them as map keys. |
| 74 | +* We never have to worry about an immutable collection changing as we iterate over its contents. |
| 75 | +* We can explore different scenarios without having to deep-copy initial states (which also makes it easy to implement undo and redo). |
| 76 | +* We can safely share immutable objects between different threads. |
0 commit comments