Builder (97) Design Pattern, Part 2

Builder (97) Design Pattern, Part 1 has an introduction to the “Gang of Four” Design Patterns book and gives an example where the builder pattern may be useful. Where I left off, we have a code snippet like this where the “Validator” class and its associated methods (setRequiredFields and validate) don’t yet exist.

The context around this is that we need a flexible way to validate the form. Continue reading “Builder (97) Design Pattern, Part 2”

Builder (97) Design Pattern, Part 1

Design Patterns by Gamma, Helm, Johnson, and Vlissides could possibly be the “holy grail” of software development books. Most practitioners of the software craft have read it and a good many have it sitting on their bookshelves. It has even spawned the “rock star” t-shirt seen here. Robert C. Martin has talked about it, and so has Martin Fowler, Joshua Bloch, Grady Booch, and many others.

Of the design patterns, I would guess that Singleton (127) or Abstract Factory (87) are the most widely used. Perhaps Strategy (315) is also in there somewhere. Not far behind, I would think, is Builder (97). Yet I would argue that Builder (97) is still an underused pattern. I see a lot of code around that would benefit from Builder (97).

By the way, for those of you wondering, yes that is the way these design patterns are commonly notated. The parenthetical number is the page in Design Patterns where the pattern can be found! Builder (97) means the builder pattern, found on page 97 of Design Patterns.

A quick, easy, and widely applicable example of when to use the builder pattern in web development is in form validation. Fair warning, though! It is going to take some time to get around to demonstrating the need for the builder pattern in this example. Read on and we’ll get there, eventually!
Continue reading “Builder (97) Design Pattern, Part 1”

Streams in Scala: Part 1

scala-logo-cropedLists and other collections in Scala are great, but I think there is real power in Scala streams. Jason Swartz explains them well in the below paragraphs from Learning Scala: Practical Functional Programming for the JVM:

The Stream type is a lazy collection, generated from one or more starting elements and a recursive function. Elements are added to the collection only when they are accessed for the first time, in constrast to other immutable collections which receive 100% of their contents at instantiation time. The elements that a Stream generates are cached for later retrieval, ensuring that each element is only generated once.

Because there is no set limit, a Stream is also considered an unbounded collection.

The largest advantage is probably that “elements are added to the collection only when they are accessed for the first time.”
Continue reading “Streams in Scala: Part 1”

How important is the Core Domain?

Great quote here from the book Domain Driven Design Quickly. It probably makes the most sense after reading all the pages leading up to it but those with some DDD exposure prior will probably get the gist.

It is important to assign the best developers to the task of implementing the Core Domain. Developers usually tend to like technologies, to learn the best and latest language, being driven more to the infrastructure rather than the business logic. The business logic of a domain seems to be boring to them, and of little reward. After all, what’s the point in learning specifics about plane trajectories? When the project is done, all that knowledge becomes a thing of the past with very little benefit. But the business logic of the domain is the heart of the domain. Mistakes in the design and implementation of the core can lead to the entire abandonment of the project. If the core business logic does not do its job, all the technological bells and whistles will amount to nothing.

A Core Domain is not usually created in one final step. There is a process of refinement and successive refactorings are necessary before the Core emerges more clearly. We need to enforce the Core as central piece of the design, and delimitate its boundaries.

~ Domain Driven Design Quickly, p. 87

Robert C. Martin on TDD

Yes, there have been lots of controversial blogs and articles written about TDD over the years and there still are. In the early days they were serious attempts at critique and understanding. Nowadays, however, they are just rants. The bottom line is that TDD works, and everybody needs to get over it.

I know this sounds strident and unilateral, but given the record I don’t think surgeons should have to defend hand-washing, and I don’t think programmers should have to defend TDD.

Clean Coder, page 79