The Successor Value Pattern

The Successor Value Pattern 27

Posted by Michael Feathers Sun, 22 Mar 2009 16:03:00 GMT

Functional programming is in the air. It’s nearly unavoidable. Even if you haven’t heard people talk about it or haven’t read a blog about it, you’ve probably seen its influence in your project. People are taking ideas that they learned in functional programming and applying them in straight object-oriented code. In Java, where there are no closures, today you are much more likely to encounter someone’s hand-rolled fold or map abstraction, and even if they haven’t gone that far, you are likely to find attempts to replace mutable data with immutable data. It’s part of the learning process, and there are some interesting patterns which occur along the way.

OO programmers often think in terms of entities. They imagine objects with identity and changeable local state; messages sent to objects alter their local state and trigger further message sends. Classic OO is intrinsically time-oriented. How do we pull this into a functional world? One thing that we can do is choose to see an entity as a series of values over time. Here’s one way to do it. If we have an entity like this:

public class EventDay {
    private LocalDate date;

    ...

    public void advance() {
        do {
            date = RegionalEventCalendar.nextValidDate(date)
        } while (!fitsLocalCalendar(date));
    }

    ...
}

We can change it to this:

public class EventDay {
    private final LocalDate date;

    ...

    public EventDay next() {
        return new EventDay(prospectiveDay(date));
    }

    ...
}

This is the successor value pattern. The notion is that you model state change as a series of value transformations. Is this good? Well, successor value is extremely common in functional programming languages. In Haskell, for instance, you don’t have mutation so you are always constructing new values. When Scala and F# are used in a functional style, you do the same thing; but is this a good idea in Java, C#, and C++? One concern is that the runtimes and libraries of those languages might not be as well tuned for continual reconstruction of value representations of the larger domain objects that we often see in OO designs. On the surface, however, successor value is nice; it gives us a mapping to immutable values and a dose of referential transparency.

Successor Value has an interesting quality from a type perspective. You compute successor values using a function which takes a type to another value of that same type. In the example above, next is a function like that. It maps from ‘this’, which has the type EventDay, to a new EventDay. In category theory, this is called an endomorphism. It’s a relationship with some cool characteristics. One of them is closure. You can chain any number of endomorphic operations and still end up with the type you started with:

LocalDate next  = date.nextDay().nextWeek().fridayAfter();

This is really about as encapsulated as you can get. Endomorphic chains don’t betray their representations and they don’t force users to use new types. In a way, you can look at an endomorphic chain as a state machine over an entity, spread out over time.

If you are used to thinking in terms of entities, you can mechanically translate entities into values and mapping functions. However, the better thing is to rethink your data types a bit. Sometimes the mapping from entities to values is clean but often with a bit of thought you can end up with representations which are better tuned for functional work.

Posted in Michaels Musings
Meta 27 comments, permalink, rss, atom

Comments

Leave a response

Dean Wampler about 1 hour later:

It’s becoming essential for us to refactor our designs this way, both for more robust concurrency and because these designs are generally more robust in single-threaded code, too.

Fortunately, I think the concerns about copy overhead will largely go away. VM’s construct new objects fairly efficiently already. We also need to build libraries of optimized, immutable data structures. Clojure probably has the best such libraries among the JVM languages, right now.

For example, suppose you have an immutable list and you want to create a new one with a different element in the middle. There’s no need to make a whole new copy of the list. Rather, the new and old lists can share the “sublists” that didn’t change. That is, we can exploit copy-on-write semantics.
Michael Feathers about 3 hours later:

Dean: True. I suspect it will take a while for that to spread, though. I wonder in particular about languages where objects are primary and not represented internally as collections amenable to that. The bad case for ‘Successor Value’ is to use it for large entities which don’t consist primarily of internal collections.
http://agileconsulting.blogspot.com about 4 hours later:

this looks like the “ValueObject” pattern in Eric Evans domain driven design, i.e. the majority of any system should be immutable so that it can be recombined in unanticipated ways better.

Wouldn’t this pattern be harder to do and more complex state is called for? (I.e. the entity pattern) Jeff
Michael Feathers about 4 hours later:

Jeff: Yes, Eric’s Value Object pattern is sort of “use immutable value objects.” ‘Successor Value’ is about using them to replace entities when that’s useful.

Languages with algebraic data types or case classes make it easier to create and reconstruct value objects: they’re tuned for it. But, in general, that seems to be true. There’s a dividend for keeping representations less complex. The bias is toward computing things on need and transforming one representation to another rather than carrying around things we may need in a deep nest.
Cory Foy about 5 hours later:

Jeff – Matt Podwysocki actually worked a bit on trying to use this pattern with FitNesse. We wanted to move away from a mutable object requirement for fixtures, using this sort of a pattern. Ultimately we found that it was just not in the cards – the system didn’t want to let it happen without us having to put in special hooks.

But what we found is that we had the capability of expressing the state as a series of functions – we just couldn’t get early enough in the chain to inject that series.

I’ve been really impressed with the solutions in both the pure functional languages, and even the not-so-pure (F#) which do a good job of being able to handle complex cases, yet keeping rather clear.
James Ladd about 6 hours later:

Very interesting post, I like the successor pattern a lot, but I’m also one of those people who like functional programming and immutable objects.

I’m wondering if you think the successor pattern has similarities to what I have written on orienting code ‘East’ to get the same effects/results ?

http://jamesladdcode.com/?p=12

I’m not sure that the patterns are the same, but I think they lead to the same results.

Your opinion would be great to hear.

Rgs, James.
Michael Hunger about 6 hours later:

what is also nice that you can then use this series of value transformations as an (infinite lazy) sequence and use all the functional operators on that to select the values you’re interested in or to approximate the interesting result.
Tony Morris about 7 hours later:

http://functionaljava.googlecode.com/svn/artifacts/2.17/javadoc/fj/data/Enumerator.html
Jörg W Mittag 1 day later:

Re: GC overhead: Cliff Click from Azul Systems ran Rich Hickey’s Clojure Ant Colony Simulation on one of their big-ass Java machines. The program generated 20 gigs of ephemeral garbage per second! The good news: the GC plowed just right through it, without even breaking a sweat.
unclebob 1 day later:

Notice how endomorphic functions violate tell-dont-ask. Rather than telling an object to change it’s state, we ask that object for a new object in the new state.

This difference alone (commands that change state vs requests for new state) really reduces down to variable-assignment vs functions…

Compare this to REST in which the requests we can make are carried in the answer we recently received. We do not tell the system to change state, we ask for a new state from the options given us by the previous state.
Rebecca Wirfs-Brock 1 day later:

Just want to make one comment about the “Value” pattern. (Eric wasn’t the first to come up w/that BTW. Ward Cunningham wrote about it in his Checks Pattern Language and others did too…)... This value over time function works if there is a logical “next”. Sometimes there is not a next, but a next given some condition expressed in a function arg. Is that a different pattern?
Michael Feathers 1 day later:

unclebob: Yes, to me that’s the most interesting thing about mixing OO and FP. OO, done well, is about telling. FP, done well, is about asking. There’s an inherent tension and a set of interesting choices. Steve Freeman and I are working on a paper about the architectural ramifications of this.
Michael Feathers 1 day later:

rebecca: I think so. In FP, transforming a value of one type to a value of another is extremely common and it happens for so many reasons. I was just trying to write up the pattern where a series of values ends up taking the place of an entity.
Monis Iqbal 1 day later:

I’m always confused when designing a class with both mutable and immutable behavior. By this I mean that the class is mutable as in it’s state can change, has methods that modify the class members directly. On the other hand, there are methods that return a newly created object of that class.

I think the best way to refactor is to strengthen the mutable class within itself and separate out the immutable behaviors (methods) and wrap the mutable class with an immutable wrapper. Would you agree?
Dhananjay Nene 1 day later:

What I was unable to take back from this article was “Why do I need a Successor Value pattern” ? And “why does one even want to write function oriented programs”

I also wonder if Object Orientation is time-oriented as much as it is state oriented. In classic OO there is one intrinsic “current” state which is often encapsulated. Due to a variety of reasons including the necessity to not introduce side effects, FP introduces scenarios where these states are copied endlessly before eventually made consistent once again. Successor Value allows for each function to create a new value object rather than change the earlier one in place and service that no side effect requirement.

I am not sure if programmers are keen to model their typical Business Entity objects (eg. Product, Invoice etc.) using SuccessorValue pattern – these are probably to be found at a lower granularity (eg. InvoiceNumber) or within some computations in progress (eg. total Invoices processed today). So while OO programmers getting their feet wet in FP (me included) could perhaps find it difficult to figure out which states to model using functional constructs, they are imo less likely to choose the entities which do not make sense to be modeled using the FP constructs since the disconnect will very soon be obvious.

Finally in the context of Endomorphic chains, are endomorphic chains necessarily preferable ? In an EAI processing flow, the intermediate computing state objects often change type and they change type based on the underlying processing logic requirements. It is precisely to handle such type shifting that constructs such as Monads which help suppress its effects and handle the type polymorphism for the functions are to be found helpful. So again I am not sure if endomorphism is a desirable feature or simply an attribute of the business logic under consideration.

As I did state earlier, I am attempting to be able to work effectively with FP as well. So these are my observations along the way, and unlikely to be as good as that of someone much further down that path.
Michael Feathers 1 day later:

Monis: I’m not sure. Seems like we’d need a concrete example.
Michael Feathers 1 day later:

Dhananjay: I think the key thing is the reasoning advantage that referential transparency can give you.. that and the fact that computation can become a bit more explicit. I agree, though, that expense could be prohibitive – it depends on the language and the platform. Re domain objects, I notice that in many applications domain models become a bit bulky. You populate some entity and it’s clear that it has much more data and behavior than you need in a particular transaction. In FP, you are always translating, so you can condense down to the essence of what you need in a transaction. It’s not free, however. You can lose a bit of domainish-ness as you move in that direction.

I don’t think there are any clear answers yet, just tradeoffs. When I’ve seen people use successor value, it is for smaller things. I haven’t seen it in production code with something like an Order.

Re endomorphism, that was just an observation. In some functional programming I’ve done, I’ve noticed that when I push something through a series of states, I can often chain on that same time. I agree that type transformation is great and valuable, but I thought it was worth highlighting this concept just because I haven’t seen much widespread discussion of physical dependency in FP yet.
Monis Iqbal 2 days later:
class TimeInterval {
```
private long m_startTime;
private long m_endTime;
```
```
public TimeInterval(long startTime, long endTime) {
    m_startTime = startTime;
    m_endTime = endTime;
}
```
```
setters...
```
```
getters...
```
```
public void expand() {
    m_startTime -= 1000;
    m_endTime += 1000;
}
```
```
public TimeInterval expand2() {
    return new TimeInterval(m_startTime-1000,  m_endTime+1000);
}
```
}

Now this can be a complex data structure with self-manipulation logic defined through it’s methods. However we have another method expand2 that does not alter the state of the calling object i.e. a method without side-effects.

We see this kind of behavior in many places. My point is that we should try to extract out expand2 in another wrapper class that provides such immutable methods over TimeInterval. In this way we can have both mutable and immutable flavors of a single data structure.

I haven’t gone through Scala completely but I think that the Scala collections are built on similar theme.

bernard AMADE 7 months later:

just brainstorming … what about using such patterns when members do not change often and using a special reference to a member that changes often:

class Product {
  String ref ; // immutable
  BigDecimal price ; // changes but not often 
  Stock stock ; // changes quickly and continuously so encapsulated in another special object

han about 1 year later:

I use them and find them helpful, but I feel that they are a bit of a cop-out as a language construct. If an exception could talk, it would say “get me the hell out of here.” And, you have to admit, that’s a bit rude.
latin shoes about 1 year later:

Most problems happens before testing, nice post anyway!
latin shoes about 1 year later:

would you mind updating your blog with more information?
jewellery about 1 year later:

would you mind updating your blog with more information?
wholesale nhl jerseys about 1 year later:

would you mind updating your blog with more information?
baseball jersey about 1 year later:

would you mind updating your blog with more information?
jerseys wholesale about 1 year later:

would you mind updating your blog with more information?
location automobile about 1 year later:

I am happy to find this post very useful for me, as it contains lot of information. I always prefer to read the quality content and this thing I found in you post. Thanks for sharing

Mentor	twitter id
Uncle Bob	unclebobmartin
Brett Schuchert	schuchert
Michael Feathers	mfeathers
Bob Koss	bob_koss

The Successor Value Pattern 27

Comments

Blog Search

Follow us on twitter

Categories

Blogroll

Syndicate