So I am back from my trip. My family went with me this time. We had a great time. It was a vacation for us. Just before we left I had heard that one of my study partner passed the exam. I think my chances just went up. If he passed it I surely did. I feel we are at least equal in our understanding of the subject. It has sure taken a long time to get my results. On Friday it will have been 9 weeks. You are usually told 4 to 6 weeks. My study partner would have been told in 7 weeks. I wonder how long it takes to grade these tests. I have complained in the past that it should not be so subjective. With my trouble with memory and writing and reading I hope that it is easy for them to see that I know this stuff. I hope that I get my results this week. I hope and pray I passed.

I was thinking more about what I said about patterns. I was thinking about another example of how my comments last time about them were justified in frameworks that I have seen. The BREW API strives for consistency but it uses a couple of different patterns for callbacks from methods. These amount to style. The language that a developers uses to talk with each other never covers style. We always just talk about the callback and worry about the implementation later. The implementation has different names for the pattern used for the callbacks in the API. In fact even in our shop we give a name to the style based on the project it came from. That may be unusual but it works. We say something like, "You should use the style of callback used in the GIR project." We never use the pattern names for this stuff. Pattern names are confusing they don`t clue a developer into an implementation of a pattern. Different languages and different implementations of languages is MS C++ or GNU C++, is it on Solaris, is it on the emulator, is it on the device...all these things muddy the waters about patterns. On Solaris we use roguewave. On the device we use BREW. In windows we have to deal with what part of emulation. All affect patterns. It is to difficult to talk about patterns of implementations. So patterns like in the GOF book are not used. This is like discussing style at a time when you need to dispense with the structure and talk about the high level behavior. So API structure like in the GOF book is not practical for use as a communication mechanism or for reuse of well known implementations because these things depend on too many other things. The objective is to have one codebase with conditional compiles for different environments. This is so that the same code used for load generation on Solaris, is the same code used for handset emulation on windows, is the same code used for firmware implementations on the handset device even though the implementation of some of the behavior is different and conditionally compiled in. GOF patterns are not used the way that they are taught they are used in the real world. They are not as generic as they seem they have implementation dependencies even though they may seem that they don`t. This is evident in the multiple implementations I saw for `Visitor` and the arguing over what was better. GOF cannot be the definitive reference on patterns. Patterns of implementation don`t make sense. Patterns of behavior do make sense but with different implementations. As I said in the last post you would not talk about the sentence structure of a message that you were trying to relay to another person when you could say that sentence in a couple of million different ways. Look at your SPAM folder sometime. Did they say that message in a couple of different ways? Did they come of with those sentences on their own or did they have to look in a book for them? Did the first caveman read about the wheel in a book or did he slip on a log and it rolled? I am sure implementation of a wheel does not mean you talk about the spokes. So saying a singleton is a class that only every has one instance is sufficient to talk about. You don`t have to go into that it has a private member with a reference to itself and a private constructor and a static get instance method that returns a new reference to a new instance on the first request and the same reference on subsequent requests. The implementation may be different in other environments. For instance in BREW you are not allowed to have static data. Singletons look totally different but the idea of a singleton looks the same. An yes a developer can come up with an implementation on his own. I like the first caveman creating a wheel have had times where I wanted to use a pattern but had to come up with my own implementation because of the restrictions of the environment.