About
Exploring Solution Spaces, Keith Ray's blog on Software development and other topics.
Send comments to:
keithray@mac.com
| For Agile Training, eLearning, or Coaching contact: |
| Industrial Logic, Inc. |
| 866-540-8336 (toll free) |
| 510-540-8336 (Berkeley, California) |
| Links |
| xpminifaq |
| Résumé |
| “Adopting XP” Article 2002 (pdf) |
| “ Refactoring” Article 2006 |
| AYE Conference |
| Lucien W. Dupont |
| Elisabeth Hendrickson |
| Johanna Rothman's Managing Product Development |
| Brian Marick's Exploration Through Example |
| Esther Derby's Insights You Can Use |
| Laurent Bossavit's Incipient(thoughts) |
| Dale Emery's Conversations with Dale |
| Martin Fowler's Bliki |
| Creating Passionate Users |
Archives
Subscribe
RSS Exploring Solution Spaces XML
2003.Dec.23 Tue
Regarding Value objects and Entity objects mentioned in Eric Evan's Domain Driven Design...
I think of value objects (mutable and immutable), entity objects, and "Other" including "stateless" objects...
For example, a "configuration object" may be a platform-independent wrapper for the Registry API on Windows, the User Defaults API on MacOS X, and reading/writing ~/.somefile on unix/linux. None of the platform-dependent versions of this object necessarily need to have their own state, though caching the state might be useful if profiling determines that there's too much overhead in using the native APIs all the time. I like the stateless object for this particular case, because we can have many of them, possibly in multiple threads, without having to synchronize them -- the APIs we're calling are already synchronized (at least on Windows and MacOS X). Being a normal object, we can pass around Mock versions in our tests.
Note that a generic preferences object would not be in the Domain layer - it would be part of the infrastructure layer.
Eric does mention Policy objects as stateless objects implementing the Strategy pattern in examples of the freight-routing model; these would neither be Value objects nor Entity objects, as far as I can tell, but they would reside in the Domain layer.
SWIG allows Java code (etc.) call C/C++ code, not the other way 'round. That's the opposite of JACE, which lets C/C++ call Java. Maybe SWIG can be extended...
"Doctor, it hurts when I do this," says the patient. "Don't do it," replies the doctor. Here's a language translation task that makes me say "double-ouch" - some guy in India has to translate legacy (undocumented, untested) C++ into COBOL!
So much of language trends in the software industry come from marketing and price. Objective-C is a language that easily allows mixing Object Oriented programming with C. Back in the day when the major languages were C, Pascal, FORTRAN, BASIC, and COBOL, and they were interoperable, Objective-C continued to be interoperable. Unfortunately Objective-C was initially rather expensive, and had the reputation for being slow, because of one or two poor implementations. At the same time, C++ was gaining ground, because it was essentially being given away for free to universities and cheaply to companies that licensed CFront from AT&T; it was often used as a "better C" and had a (not always deserved) reputation for high performance. By the time that Objective-C had a free (gcc) implementation, the momentum for commercial compiler vendors and GUI programming environments (other than NeXTStep/Cocoa) was firmly in the C++ camp.
Xerox didn't market Smalltalk well, and later the Smalltalk vendors had a meltdown from mergers and loss of focus, and many people decided the language was dead. Smalltalk also didn't encourage interoperability - mixing C and Smalltalk is difficult in many Smalltalk environments. (Dolphin Smalltalk seems to be one of the exceptions, though their use of the phrase "Pure Object Oriented Programming" may be scaring away potential customers.) Now there are some free versions of Smalltalk, and several good commercial versions, but no major company (like Sun, IBM, or Microsoft) is hyping Smalltalk, even though IBM has a commercial Smalltalk implementation, and Sun and Microsoft are hawking virtual-machine-based languages that owe a large debt to Smalltalk virtual-machine research.
Like Smalltalk of old, Java makes it difficult to interoperate with C. I've used JNI fairly extensively for calling Java from C and vice-versa, and it is incredibly painful to use. Calling Java from C seems to be particularly problematic on MacOS 9 - all the threads that are supposed to be running inside the JVM are only active during the course of the call into the JVM, and maybe not even then, and one of those threads is the garbage-collection thread.
One tool for making JNI work easier is JACE, by generating (and using) C++ template-based code. Unfortunately, the most recent version of JACE is using templates that I can't compile properly with CodeWarrior -- when I told the author this, he told me to get a better compiler! I tried to suggest to the author that instead of relying on templates so much he could generate code without templates, because templates essentially are code-generators after all. He said something about wanting type-safety, which completely misses the point -- if you specify types as part of the code-generation process, then you can have exactly as much type-safety as you would get from templates. Given the arrogance of the author ("get a better compiler!"), I am not going to link to JACE, and would recommend that you use SWIG instead, for your JNI and other language-interoperability tasks. Once you've gotten SWIG as an executable tool, it generates C code, compatible with a large number of compilers.