Object Thinking By David West

Coming from a big brain like yours, I don't feel quite as stupid that I haven't had my OO "a-ha moment" either, even after 13 years of programming and building some pretty complex stuff. I always read your blog entries when you approach the topic because I'm hoping you're going to help me get there one of these days. Thanks for your thoughts and book review. I guess me and my little brain will keep waiting...

I think I'm in the same boat where I read a lot about OO and how to design objects themselves with a bunch of generic examples, but I run into the same issues around business logic and constraints and how that fits in with those object models. I'm glad I'm not the only one in that boat and appreciate your sharing.

Is the answer to work in a pure OO language?

@Ben,

You're exactly right - you'd ask the TaskList to instantiate a task. Not sure why that's a problem - if you don't have a list of tasks, then title uniqueness can't be a problem, right? Conversely, if you care about a constraint, you care about it in a particular context. So you instantiate that context as an object and voila! In the case of uniqueness, the context is going to be membership of some collection, even if the collection is just the list of all objects.

What you then get for free is that you get to say things like "OK, task titles don't have to be unique in the universe, they just have to be unique for each task assignee". You move the constraint from TaskList to PersonalTaskList and everything still works. This is important because IMHO real, permanent, constraints on object models tend to be fairly few in number. Constraints tend to be situational and context-dependant.

Sounds like a conference like NCDevCon needs a hands on 2 hour session on OOP...So, time to hit Matt Gifford up and get him there to go through his book in detail, maybe you and many of us would have the ah-ha moment.

@Ben,
One of the things that really helped me get away from writing procedural code was taking an O.O.P. class and being required to write functions no longer than an arbitrarily small number of lines. It can help you see what belongs together, what doesn't belong together, and what can be generalized when you're forced to write like that.

It doesn't necessarily get you all the way to OOP. It gives you a start because it helps get you thinking about how to generalize your code. You start realizing, "I've written something like this already. How do I tweak that code to work here, too?" That's the kind of thinking you want to start with.

What you've exposed of the book is the classic "black box" style of OOP. As with the instrumentation in the plane, you can't simply set the airspeed; the airspeed is read-only. You can affect it by moving the throttle, but there are external forces like turbulence and tailwinds that can affect it, too.

With a "black box" mentality, your object handles all of the logic. One object that I'd written handled attendance-based billing for daycare centers. There was a huge amount of processing within the object, but the only information you provided was, "Which child?" "Which set of rules?" and, "What date range?" The object retrieved the schedule and attendance information for that child during the specified date range, set it against the rules, calculated the bill amount, and flagged any errors or warnings.

I used another example of the "black box" mentality when writing an old-fashioned adventure game (think Zelda of the 1980s). The object handled movement and event logic. All you did was tell it what your character was doing, e.g., "Move north," or "Dig." The object knew where your character was and what the map around him looked like. It handled all the logic: "Can he move there?" "Did he find something?" "Did something find him?" It would return all this information in a structure.

To get to this point, you want to think about what your object can automate, what your object cannot automate, what an external entity must do, and what an external entity should not do. With your tasklist example, you have a collection of tasks: the collection is an object and each task is an object. You want to make sure that your collection of tasks doesn't have any duplicate tasks. The external entity, i.e., the user, should be able to change the name of a task, but the tasklist should ensure it is still unique.

How do you accomplish this? There are a few ways. Certainly, you start by encapsulating the task name and preventing the user from changing that directly. This means that the task would have a setter regardless of how you do it. Of course, the setter also prevents any processing from happening if the old name and the new name are the same; you can run into trouble otherwise.

If you want to make it possible to change the name of the task through a method of the tasklist, there are three different ways to identify the task. You can provide the index, the existing title, or a pointer to the task object itself. You can get any of these three things through other methods of the tasklist.

If you want to make it possible to change the name of the task through a method of the task itself, the task should have a pointer to the encapsulating tasklist. The task checks to see if it's part of a list when you call the setter and, if so, checks in with the list (passing "this" as identification) before setting the task name.

The thing is, the task handles setting the name and the tasklist handles ensuring uniqueness. The task has to realize that it could be part of a tasklist, so you incorporate logic to deal with that. Since the task handles setting the name, even the tasklist has to use that setter to set the name.

var Task = function(taskName) {
var _complete = false;
var _list = null;
var _name = taskName;
this.getTaskName = function() {
	return _name;
};
this.setTaskName = function(newTaskName) {
	if (newTaskName != _name) {
	var okToChange = true;
	if (_list != null) {
		okToChange = (_list.getTaskByName(newTaskName) == null);
	}
	if (okToChange) {
		_name = newTaskName;
	}
	}
	return this;
};
this.addToList = function(taskList) {
	_list = taskList;
	return this;
};
this.dropFromList = function() {
	_list = null;
	return this;
};
this.completeTask = function() {
	_complete = true;
};
this.isComplete = function() {
	return _complete;
};
};
var TaskList = function() {
var _tasks = new Array();
this.getTaskByName = function(taskName) {
	var taskFound = null;
	for (var i = 0; (i < _tasks.length) && (taskFound == null); ++i) {
	if (_tasks[i].getTaskName() == taskName) {
		taskFound = _tasks[i];
	}
	}
	return taskFound;
};
this.getTaskByIndex = function(taskIndex) {
	var taskFound = null;
	if (taskIndex < _tasks.length) {
	taskFound = _tasks[taskIndex];
	}
	return taskFound;
}
this.addTask = function(taskToAdd) {
	var newTask = null;
	if (typeof taskToAdd == "string") {
	if (this.getTaskByName(taskToAdd) == null) {
		newTask = new Task(taskToAdd);
	}
	} else if (typeof taskToAdd == "function") {
	if (this.getTaskByName(taskToAdd.getTaskName()) == null) {
		newTask = taskToAdd;
	}
	}
	if (newTask != null) {
	_tasks[_tasks.length] = newTask;
	newTask.addToList(this);
	}
	return this;
};
... // I think you get the idea at this point.
};

This is a really great discussion. I would make one suggested change to the previous example by which the TaskList uses setTaskName:

In Task:

this.setTaskName = function(newTaskName) {
	if (newTaskName != _name) {
		var okToChange = true;
		if (_list.isValidTaskName(newTaskName)) {
			_name = newTaskName;
		}
	}
	return this;
}

In TaskList:

this.isValidTaskName = function(newTaskName) {
	return this.getTaskByName(newTaskName) == null;
}

This takes the business logic of "uniqueness" out of the task itself and places it in the hands of the TaskList that it is a part of. This allows any subclass of TaskList to determine its own constraints (e.g. names must begin with a capital letter, names cannot be longer than 16 characters, etc.) and makes both Tasks and TaskLists more flexible.

James

@James,
That's a really good catch. You're right: the task shouldn't care what it takes to fit in with the rest of the list. It should leave that up to the list. It should simply say, "Hey, List! Is this change ok with you?" and change the name if the response allows it.

@Ben,
It really comes down to a sound design. As I'm sure you're aware, a huge part of the development process is actually consumed, not by the original development, but by the maintenance of that code and the expansion of it. This is why it is really critical to spend time thinking about the delegation of work and outlining of interactions between objects.

It sounds like a lot of work, for sure, and it can be. The reward is actually somewhat bittersweet. If you design your object library really well and the code is really robust, you find that it is really easy to expand it to do new things. On the other hand, if the code is that well built, if you have to work on the internals and you didn't document the hell out of it, it may take you a while to understand what all you were doing in there.

@Ben,
If you didn't design it well, you have all the benefits of OOP, but it becomes more difficult to extend the functionality. Any immature design (and I've written my share) will eventually reach a point where it becomes difficult to extend the functionality.

Take a look at what James pointed out above. If we had proceeded with the design I'd written out, we would have encountered difficulty if the list wanted a different way to identify or validate the task. Even the fix that James provided potentially limits the list by only providing the new name instead of a potentially altered task.

What's my own experience? I design and write up an object library with the resources available at the time, including: understanding of the intent; time to identify future needs; knowledge of the language and its capabilities; and time to implement. As I work with my object library and extend it, I will encounter an obstacle. At that point, I can either spend the time to rework the object library or simply shoehorn it into doing what I need it to do and remember that when I want to rework the whole library next time.

Each time I rework the library, the design matures and I bask in the glory of having written a better version. I eventually run into the obstacle with that version and go through the process again.

@Ben,

As the one who recommended the book to you, I feel a little bad you didn't find it as revelatory as I did. But I'm glad you got something out of it, and the discussion here is great.

I would say that your critiques, especially about the length, and wanting to see more examples worked through, are valid. My overall feeling, though, was that the insights were so deep that they made up for the book's flaws many times over.

Also, glad you enjoyed Carlo's blog. The Fowler book Patterns of Enterprise Application Architecture is pretty much entirely example based, so you may enjoy that one more. Though I'd warn that it too is a bit of a slog, despite being very good.

For a much more accessible, but still very good non-slog, also completely example based, check out:

Practical Object-Oriented Design in Ruby: An Agile Primer by Sandi Metz

I'd be pretty confident that with your programming experience, even if you don't know any Ruby it wouldn't matter at all, and you'd still be able to follow all the examples. This book is sort of the mirror image of the West book -- all practical advice and examples with very little underlying philosophy and history. So having got the history under your belt already, it might make a good complement.

I've long tried to evaluate the efficacy of development theorem vs. practical application, and I deal mostly in OO vs. procedural.

Not to wax capitalist, but the "right way" is the one that doesn't produce errors, makes clients happy, and gets one paid.

I deal primarily in a seriously undisciplined OOP product, and I would echo what someone else said...there comes a point where the most purposefully designed piece of object oriented programming becomes the victim of its own success.

Developing a web-based sales order process for an ERP system, for instance, one designed principally around batched transactions, and I discover the efficacy of object oriented programming, but then its ultimate shortcomings.

You have your class of customers.
You have your class of addresses.
You possible have a class of sales people.
You have either item pricing or customer-based pricing.

All of these things require attending to business logic that would take place in the bricks and mortar implementation of the ERP system, but you don't have available. I find objects, with properties and constructors that afford that logic, to be extremely helpful.

Combine this with our consistent issue as web developers, the fact that the world of HTTP requests and responses is for all intents and purposes, mostly stateless itself. Almost all of our platforms have mechanisms for introducing statefulness, but there is a certain amount of event modeling or conditioning we still have to place around what we are trying to achieve. Say I have this complex web ordering system, and I merely need to change the shipping method on several line items. For the web in particular, whatever model we use, we either have to isolate our function and play within the DOM, or find a way to target that in a single request and still expect the entire page state in the response.

In an object oriented land, the more a client might inject complexity into those individual pieces ("where is my drop ship option? where are my trade discounts?") the more we have to extend our individual objects to contain them. Which almost always necessitates refactoring the consumptive end. And then, because we're juggling page load times with the complexity of what we're doing, we still have to piecemeal around the transactional reality of our medium.

I try to envision what Albert Camus would write about what amount to doctrinal programming concepts, and realize he may well already have:

"So long as the mind keeps silent in the motionless world of its hopes, everything is reflected and arranged in the unity of nostalgia. but with its first move this world cracks and tumbles: an infinite number of shimmering fragments is offered to the understanding. We must despair of ever reconstructing the familiar, calm surface which would give us peace of heart."