A Watch – from an OOP perspective

A watch might be one of the most common types of objects, but it remains also one of the earliest pieces of human craftmanship to show an extreme level of complexity, all contained in a small amount of space. Since the late 1700s, artisan watchmakers in Switzerland and elsewhere have shown their pride and skills creating watches called “Grande Complications”, containing thousands of individual parts and performing incredible functions:

The most complicated watch ever made, known in watch enthusiasts’ circles as “The Ultimate Watch,” is Patek Philippe’s “Calibre 89. The incredibly precise operation of 1728 parts in this really ultimate masterpiece of watchmaking allows to perform no less than 33 (thirty-three!) complicated functions, among them a correction for the 400-year-rule, an Easter date indication, a star chart, a tourbillon, a perpetual calendar, a sidereal time indication, and, and, and … This watch was sold in 1989 for the nice round sum of about four million Swiss francs.”

(Ozdoba, 2005)

(Source: CNN.com, 2005)

More information about the “Calibre 89″ can be found here and in the Patek Philippe Museum website.

However, the same watchmakers that made these fine pieces were also aware of the basic information that their creations were to provide: time. As such, their watches remained extremely easy to use, and they set up the basic standard for analog watches, in such timeless designs that the latest Swatch models show the same basic layout and functionality.

The underlying concept is the very same used in today’s object-oriented abstraction and encapsulation. Even Apple uses the idea of the watch to show this characteristic:

All programming languages provide devices that help express abstractions. In essence, these devices are ways of grouping implementation details, hiding them, and giving them, at least to some extent, a common interface—much as a mechanical object separates its interface from its implementation, as illustrated in Figure 2-1.

(Source: Apple Developer Connection, 2006)

In this article I will provide my view about how different OOP concepts apply to a real-life object such as a watch, in all its forms. Continue reading

The beauty of Cocoa

(Highly geeky post ahead. You’ve been warned!)

I have found the very message that summarizes the beauty of Cocoa in a single word; see by yourselves, hereunder in line 47:

[source:c]

import

// The interface of a person @interface Person : NSObject { NSString* firstName; NSString* lastName; int age; } @end

// The implementation of the Person @implementation Person -(id)init { if (self = [super init]) { firstName = @”"; lastName = @”"; age = 0; } return self; }

-(void)dealloc { [firstName release]; [lastName release]; [super dealloc]; }

-(NSString*)description { return [[NSString alloc] initWithFormat:@”Name: %@ %@, %d years old”, firstName, lastName, age]; } @end

// Some code using the Person class int main (int argc, const char * argv[]) { NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];

NSMutableDictionary* dict = [[[NSMutableDictionary alloc] init] autorelease];
[dict setObject:@"Teto" forKey:@"firstName"];
[dict setObject:@"Rodriguez" forKey:@"lastName"];
[dict setObject:[[NSNumber alloc] initWithInt:34] forKey:@"age"];
Person* person = [[[Person alloc] init] autorelease];
// The beauty of Cocoa can be resumed to this very line:
[person setValuesForKeysWithDictionary:dict];
// Now sit back and relax:
NSLog([person description]);
[pool drain];
return 0;

} [/source]

Basic vs. Digest

In the series of highly boring posts ;) here’s another one; in this case, a simple explanation of two different authentication protocols available in the HTTP standard.

HTTP Basic Authentication Protocol

This is the simplest HTTP Authentication protocol available:

  1. The browser sends a request to a protected resource: GET /index.html
  2. The server looks for the “Authenticated” header in the request; since it does not find it, it replies back with a response with the 401 code (“Unauthorized”). The response contains a “WWW-Authenticate” header, with the value “Basic”. This response is called a “challenge”, and it also contains a “realm” text, which describes the protected resource in clear text (the “realm” is shown in the pop-up window that usually appears for you to type your password when this protocol is used).
  3. The browser creates a new request GET /index.html that contains an HTTP_AUTHORIZATION header, whose value is the word “Basic” followed by the ‘username:password’ string encoded in base 64. This algorithm is a two-way algorithm: you can retrieve the username and password from the base 64-encoded string.
  4. The server receives this response, and since base 64 is a two-way algorithm, it compares the MD5 (or SHA1) password hash to the one stored in the database. If they are the same, the request is processed. Otherwise, the user gets a 401 again.

Continue reading