Skip to main content
Ben Nadel at cf.Objective() 2013 (Bloomington, MN) with: Steven Neiland
Ben Nadel at cf.Objective() 2013 (Bloomington, MN) with: Steven Neiland ( @sneiland )

Streamlined Object Modeling: Patterns, Rules, And Implementation

Published in , , Comments (17)

Six months ago, I was lamenting the fact (as I have done many times) that I do not know Object Oriented Programming (OOP). In response, my friend, Jonah, recommended that I take a look at the book, Streamlined Object Modeling: Patterns, Rules, and Implementation by Jill Nicola, Mark Mayfield, and Mike Abney. It took me over six months to finish and has left my head swimming in information. I have yet to put any of it into practice; but, I have a sneaking suspicion that it may just be one of the most important computer science books that I have ever read!


Streamlined Object Modeling.  

Streamlined Object Modeling took me six months to read; but, it wasn't six solid months. To be honest, the first five or six chapters completely befuddled me; it was all philosophy and principles without a single line of code. I muscled through the first half, but eventually, out of frustration, I put the book down and didn't touch it again for months. Then, a few weeks ago I picked it back up and read chapters 7 and 8; and lo and behold, there was code!

The code grounded me and put the rest of the book in context. It was an iterative example that grew an object model as more information and business requirements became available. It was utterly fascinating and made object modeling tangible in a way that I have not felt before.

That said, "Object Think," is still a completely new and mysterious topic. In order to get my sea-legs, so to speak, I've created a GitHub project: Streamlined Object Modeling in which I will be using JavaScript code examples to explore the principles outlined in the book. If anyone wants to help me on my journey, that would be a thousand percent awesome!

GitHub Project: Streamlined Object Modeling

After having read the last few chapters, I'm now going back going back through the first half. Already, I'm finding the code (and the later half) is making the first half of the book much more clear. At this point, though, I don't think that I have enough of a handle on the material to confidently relay much about the book other than to say that I found it fascinating. That said, I'd like to quote from the section, "Fundamentals of Streamlined Object Modeling" (Location 821), as I think it gives a nice overview:

At its core, streamlined object modeling includes 12 irreducible patterns that cover all the people, place, thing, and event relationships needed to model any real-world domain. They are irreducible because they cannot be decomposed into smaller constituent patterns. Each pattern consists of two template objects called pattern players, and each pattern player has a unique meaning that determines how it handles business rules, participates in business scenarios, and is implemented in code.

Streamlined object modeling also includes a precise process for mapping business rules into an object model. Two types of business rules are identified: those that regulate data values and those that regulate real-world relationships. The data regulation rules largely become internal rules for checking object property values. More interesting are the rules for regulating relationships; streamlined object modeling recasts these rules as preconditions for creating or dissolving the relationships modeled by its core set of patterns. With this formulation, each business rule is a test between two pattern players and falls into one of five categories: (1) type, (2) multiplicity, (3) property, (4) state, and (5) conflict rules. For each pair of pattern players, streamlined object modeling specifies which category of rules each pattern player has the responsibility of checking.

Lastly, streamlined object modeling recognizes three types of business services: (1) determining current information, (2) determining historical information, and (3) initiating business actions. As with business rules, how to distribute the work of performing business services among objects depends on the pattern player roles each object plays, so that knowing what patterns an object participates in determines how much work it undertakes and how much it delegats to its collaborating objects.

One thing that I love about this approach is that it is very rule oriented. I'm a Virgo, what can I say - I like rules; I don't like "it depends." And, while I understand that principles will be applied based on context, I really like that once the context is known, "it depends" seems to fade to the background. Though, I may be getting ahead of myself.

I don't yet know how this book will influence the way that I write software applications. But, it is definitely a book that I recommend reading. I read it on the Kindle App on my iPad and I noticed that the book makes references to the "CD" that shipped with the book. Clearly, no CD came with my Kindle version; but, I did find a download for the Source Code this morning.

Reader Comments


You...WHAT?!?! You don't know OOP?! Ben Nadel... THE Ben Nadel doesn't know OOP? Man, I just got introduced to OOP about a month ago (I read "Object-Oriented Programming in ColdFusion" by Matt Gifford (who gave a nod to you Ben, as tech advisor) just because it was OOP AND it was related to ColdFusion (to make it easier to absorb).

The concept has caused me to rework a large chunk of a framework I am developing, but as I am doing it, things just make sense and work very well as expected. To have that level of comprehension; I LOVE that, because it means you KNOW something, and are not just flailing in the wind, haphazzardly guessing what does what.

I take it this book is not focused on CF OOP, but just the principles of OOP, which can be utilized by CF, Javascript and a myriad of other languages. I'd love the opportunity to help, and would gladly offer up what knowledge I could, even though as it stands now, much of my time is spent converting my CF to OOP methodologies.

It's neat, though. You start looking at singleton and transient objects, relating OOP Classes to CFC's, and I even document my CFC's with a list of explicit and implict methods, component properties, private VARiables and public THIS variables, just to get my head wrapped around what it does.

It's almost enjoyable when you stop for a moment and think about it. I had some functionality, and I was wondering whether it was responsible for my User object or my Security object. When I thought about it, I figured it was for neither, but instead for my Data object. I wrote a method on getting data by reference. Til then I had so many getFieldByRef() and getOtherFieldByOtherRef() that I replaced them all with a getValueByRef method that took 3 params. A table name, the field name returned, and a structure of fieldname/value pairs used as criteria.

I can see how this OOP stuff is so popular, but wow is it a different mindset completely! :)



Ha ha, I've been trying to learn for a long time. I use ColdFusion components and I try to work with services and gateways and the like. But, I've just never really gotten into Objects as "Entities" before. That's the part where I really get stuck! Using objects is great and I do get a LOT of value at out of how I use them currently in ColdFusion; I just want to see if I can wrap my head around "domain modeling".

This book focuses on patterns in modeling, but doesn't talk about OOP in a technical sense. Meaning, it doesn't talk about object mechanics - public, private, protected, etc. It doesn't talk about the joys of data / implementation encapsulation, except in reference to why they have a given pattern.

So, yes, the stuff they talk about in the book is going to be, in large part, technology independent. The book actually walks through the examples in both Java and something called "Squeak." The two languages have different kinds of implementations; but, you can see how the principles are still being applied.


Hey Ben, funny how some things seem to pop up together!
I just returned from wordcamp RU, and one of the more interesting and tech talks there was on using OOP - with a huge recommendation on the "goose" book - or Growing-Object-Oriented-Software (it is one the third page of AMZ recommendations related to streamlined book)

The presentation slides are here, but they aren't really that standalone, how ever, the video should be coming to in the near future

I was planning on picking it up as soon as get done with two coursers courses eating away my time, and it might be up your alley as well based on the earlier posts you've done and the focus on testing quickly



Sounds like a higher level of abstraction with OOP concepts and methodologies. I admit, though I am slow to grasp those things when I am giving nothing more than a book on the subject, when instead I am presented with a visual training source, I seem to catch on significantly faster and retain the better (of course the issue here is that the visual presentation HAS to be done in such as way as to properly convey the message).

I think abstraction in this manner is both non-traditional and highly beneficial. Sometimes, we become so mired and stagnant in our current understanding of how things are, that we don't ask the "why" in order to see the underlying structure.

I know your design roots show every once in a while, so as an example, if you were shown a white piece of paper and it had a gray circle and a black square, chances are you'd look at the square first. We could just leave it as it is there, or we could ask "Why"?

If you do the latter you end up finding that, as humans, our eyes are drawn to the point of highest contrast first. And with this knowledge, you can then help lead your user's focus through a design using the concept of contrast. One area of study that I am VERY interested in is called HCI (Human-Computer Interaction) and it contains a series of guidelines as to how the human psyche interprets digital interfaces. Truly, some amazing levels of comprehension can be attained once we abstract the concepts.


And, just a shout out to one of the main people responsible for the concepts of patterning and abstraction that informs OOP from a time almost before computers were around! Christopher Alexander (and others) - A Pattern Language, 1977.

It is a book about patterns in architecture and the abstraction of those ideas has informed many other disciplines including computer science.

Interestingly, it is a hyper-linked paper book - each section ("page") has embedded "links" to other sections and sub sections. Very www!

You might find a copy in the library. ;-)

Thanks Ben,



Thanks for the link - I've never read that book, but I have heard really good things. In addition to OO, I'm starting to get into Unit Testing a bit more, so that book sounds like it hits a number of topics that I'm looking at. I'll be sure to put it on the queue!



I read the Gang of Four (GoF) book a number of years ago (maybe 8?). It was pretty intense, most of it went over my head. After I tried that, I went on to try and read Head First Object Oriented Analysis and Design and then also Head First Design Patterns. I really enjoyed the "Head First" books - a little bit more my speed, so to speak. But even then, while I can understand the concepts behind Proxies and Facades and various other patterns, some of the "modeling" concepts really stay out of my reach.

I like to think that I am *technically* very good at the languages I use; but, architecturally, I leave something to be desired. But hopefully, not for long :D



I'm very much the same way - philosophy only gets me so far before my mental model becomes muddled (tongue twister anyone?). That's why the first half of this book felt confusing until I got to the last half -- which had code. Now, re-reading the book (with code as context), it's starting to make more sense.

The contrast stuff sounds very interesting ... very UX related, which is another one of my passions.


Not to bash the book, as I'm sure everyone who reads it comprehends it at a different level; but as with many things, web sites included, if you cannot connect with your viewer, you risk the chance of losing them. They were lucky you came back to the book later.

I went to a handful of ColdFusion framework websites to see what all the fuss was about, and each and everyone immediately spoke over my head, giving me a sense of frustration and confusion, so I backed away from them and have just continued to make my own personal framework better.

I'm kinda proud of what I've made so far, but I understand that it's a crutch in the big scope of things, because if I were to work collaboratively, chances are they'd be using a more public framework.

Though not true for all, I find developers have a hard time speaking in laymans terms and many developer-centric sites suffer heavily from a noticeable lack of accommodating design.

Just read a great OOP article on encapsulation, and for whatever reason, the developer thought that a 9px font was an ample font size for comfortable reading. Needless to say, I had to CTRL and + it a couple times over. People need to learn that great web design is not design OR function, it's design AND function.



I know exactly what you mean. I think this is the forever-difficult part of some topics, like OOP. You don't want people to talk over your head; but, at the same time, people seem to think that in order for OOP to make sense, the problem space has to be sufficiently hard. It's a difficult problem - trying to find the right was to talk about something that is complex.

Plus, I have so many years of thinking a *different* way, that this is a total mind-bend. Which makes it exciting, but all that much harder.



Right now, that's really the only thing on that page. There's not much to see in the demo, since it's just JavaScript that runs a number of unit tests. Maybe I can make the demos a bit more interactive.


I am studying "Streamlined Object Modeling" as well. The entire industry is stuck on Design Patterns. I believe programmers uses design patterns as a crutch because they don't really understand true object thinking (including myself). I think back on the many teams that I have worked on and realize all the programmers I've worked with are lacking this understanding.
This book has opened my eyes and no doubt will raise my game.

I believe in love. I believe in compassion. I believe in human rights. I believe that we can afford to give more of these gifts to the world around us because it costs us nothing to be decent and kind and understanding. And, I want you to know that when you land on this site, you are accepted for who you are, no matter how you identify, what truths you live, or whatever kind of goofy shit makes you feel alive! Rock on with your bad self!
Ben Nadel