I Built His Cage

Development of the Hydrocon is slow but steady. Though still in its prototype form, the Hydrocon will, in one dramatic move, forever end all shortages–er wrong window, sorry.

I updated the = and hash methods of Room to only look at the RoomID. Room is an Entity and should be treated as such. If I need to do an attribute-based comparison, I will write a separate method for that.

As I was writing some tests, I realized I needed a method on Building to access the Set of Rooms. That test revealed an unimplemented method on Room, unavailableForNewInventory. I added it and added an accessor on Room to find out if the Room is accepting new inventory. I added a hash method for RoomName since I implemented = as well. It’s interesting how = doesn’t require a : after it when specifying the argument. I wonder if that can be done for other method names besides =.

I’m debated for a while whether I should write some real unit tests instead of a script of Transcript show:s. I think I will write a few tests. Now here is a question: do I write one test class per object, or do I write one test script per object? The assert method is available either way. I am leaning towards a script.

Negation in Smalltalk? Didn’t have to look that up either.

I finished two test scripts, for admittedly simple objects. For the Room object, I’m going to refactor the construction of the RoomID and RoomName objects and externalize that on the advice of Misko Hevery. Oh, and I ended up going with a script of objects so I could run one script that would run all of the tester objects.

Transcript clear; show:'Starting all tests...'; cr.

RoomIDTest run.
RoomNameTest run.

Transcript show:'Tests done'; cr.

Who said class methods were useless?

As per my requirements (to be able to filter based on geographic location), it was a no brainer that I should create a BuildingAddress object, with street, state, and ZIP attributes. I thought about how to apply type hiding here: do I need to go crazy and break state and ZIP down? If I do that, I start to drift from the CORE DOMAIN.

And I think I can achieve type hiding if I keep them all strings. The only awkward part of that will be that I will need to force users of the object to call asString on a string if they want to display the ZIP or state of a BuildingAddress. This would be the equivalent of declaring the return types of such methods all as Object in Java. Then again, everything in Smalltalk is like declaring everything as type Object in Java.

I’m revisiting that thought I had earlier: are Aggregates allowed to instantiate their minions? I know I’ll never find the answer in Evans, and I doubt Nilsson touched on it.

I think if the Room object isn’t going to instantiate RoomID and RoomName, then the not-yet-written RoomFactory should. This way, I can keep the “new” keyword out of the domain model, except for factories. Keeping all object construction in factory classes smells right and follows Hevery’s testability advice.

And I have to mention another thing: why wasn’t I taught Smalltalk before C++ or Java? Only after I graduate from college am I now really understanding what object-orientation is about: programming to interfaces, encapsulation, abstraction, and message passing.

I mean, what the hell? We started out functional programming by learning Scheme, another “academic” language, and I think that gave me a solid idea of what ideas like closures and currying are about. We studied procedural programming by studying the granddaddy of them all, C. Why introduce object-orientation with diluted enterprisey languages like C++ and Java?

The reason, I’m afraid, is paradoxical. My very first computer science class had to be petitioned. We were able to get a liberal from the local community college to come by the high school after school had ended three days a week to teach us in the lab. The AP exam was in C++, so that is what we were taught, and that was my first ever exposure to classes, which took me a while to grok.

Why isn’t the APCS exam in an “academic” language like Smalltalk?

But Moff, but Moff, C++ has more practical use in the real world than Smalltalk.

While a die-hard Smalltalker will debate you on that, I will counter that the none examples on the AP exam, when I was a kid at least, couldn’t be expressed in Smalltalk. The case study is currently different, and the language is Java, but the old case study involved data and behavior united. It is puzzling.

But Moff, but Moff, C++ is easier for kids coming from BASIC and C to learn than Smalltalk — you had enough trouble learning it.

That’s the point! OO should feel drastically different from a venerable procedural language like C. That’s why they call it a paradigm.

Then again, while the language can help a lot, it isn’t the silver bullet. It’s a people problem. You can write crappy code in any language, but there are surely no EJB imposters in Smalltalk. Do us a favor, Enterprise JavaBeans: go back to C!

Announcer: You’re reading the EIP web-ring.