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.17 Wed
Because I keep reminding people that Smalltalk (and C) begat Objective-C, and Objective-C (and C++) begat Java, James Bullock let me know of a good article on reasons to love and hate Objective C. Check it out: http://rentzsch.com/papers/loveHateObjC.
All of the writer's points are good, except #14 "id should be id*" is really a quibble, not worthy of "hate". He mentions PyObjC, which allows writing Cocoa apps in Python, and don't forget RubyCocoa as well.
On hate #1, "Method-call Syntax", I'd like to see Objective-C's brackets become optional (I think it could be done, and still have a simpler parser than C++), but I think more people should be forced to love Smalltalk, and so of course they will then love Objective-C by extension. ;-)
In regards to Hate #8, "Hard to Write Good Getters/Setters," part of the problem is Cocoa's semi-automated memory management - hopefully someday solved by using real garbage collection. The other part of this problem happens in any language where objects variables are only references (in other words, just about any language other than C++, which can copy objects around on the stack "by value"). You have to decide if you want to share references to your class's private members with the outside world, or make copies to give to the outside world. At least Cocoa/Objective-C has an immutable string class, so you can return references to member string variables without risk, like Java. More programmers should be writing immutable value classes to avoid copying objects in getters and setters.
This getter/setter issue reminds me of a the distinction between "value objects" and "entity objects" described in the book Domain-Driven Design by Eric Evans. "Entity" objects have the responsibility of maintaining an identity representing real-world thing, like a person. A person's age changes, weight changes, names changes; they change jobs, they change addresses, and so on, but their "identity" -- as far some software is concerned -- doesn't change.
Few programmers make the distinction between value and entity objects, and failing to make this distinction can create problematic OO designs/implementations. Unfortunately, no programming language is helping us here. It would be great if we could tag a class as an "entity," and have the compiler/run-time system let us know if we ever try to create non-identical duplicates of what is supposed to be a unique object. Tagging a class as "value" and "immutable value" would also be nice, and better than C++'s "const" syntax, which only tags variables and methods, not classes and objects.