Wednesday, December 31, 2003

Top New Year Resolutions


I just heard on a radio show that the top two resolutions are 1) lose weight and 2) get out of debt.

Here are my answers to these:

1) Lose Weight
First of all you need a target weight. Use the calculator I gave a link to yesterday to determine your ideal weight. Next you have to face the facts that if you are overweight it is probably because you eat the wrong foods, you eat too much food and/or you don't exercise enough. From my own experience the main problems are eating the wrong foods and insufficient exercise. From what I've seen the usual reason people eat too much is because they don't get the nutrients they need from what they are eating, so eating too much is usually a result of eating the wrong foods. So what are the right foods? Well, that's a tough one. For myself I've figured it out over a period of years. I read the following books:

In Fitness and In Health by Dr. Philip Maffetone (There is also another version available on Amazon: The Maffetone Method. Dr. Maffetone educates you on how to figure out what your body needs and how to exercise and burn fat in a low stress manner. Great book. For a taste of what is in the book here is the Two Week Test.

Eat Right for Your Type by Peter J. D'Adamo. This book helped me to figure out what to eat and what to avoid. You should also get the updated list of foods in the Food, Beverage and Supplement Lists from Eat Right for Your Type and you can check the Eat Right 4 Your Type Web site.

Next is the good old Atkins Diet.

Finally there is the possibility that the problem is not physical. If that is the case then the answer is Dianetics. Get the book Dianetics: The Modern Science of Mental Health and check out the Dianetics Web site.

Next: Get out of Debt

Tuesday, December 30, 2003

Useful calculator


I just found a calculator that takes your height and weight and calculates what your "lean" and "ideal" weights should be and what your current state is (e.g., overweight, normal, etc.).

Body Surface Area, Body Mass Index

This should help give you a target for your "lose weight" New Year Resolution.

Monday, December 29, 2003

This is hilarious


Jim Meskimen is one of the most talented people I've ever met. As an improv actor and impressionist he is second to none. If you don't know of Jim or doubt my impeccable taste then just check out his latest: go to Applied Silliness then click on the picture of Saddam.

Warning: if you have a heart condition or are allergic to falling off your chair laughing then get medical advice before following the above link.

Tuesday, December 23, 2003

No one can claim that Saddam is being maltreated


When the US captures someone we treat 'em right, no matter what kind of evil dictator they may be: Saddam's Makeover

Sweetie, that beard has just got to go!

Monday, December 15, 2003

Another Blog to add to your list


I just discovered the blog of my good friend Michael Duff. He has invented a new blogging term "Blirgin". It means someone who has never blogged :)

Check out his blog at Duff Blog

Wednesday, December 10, 2003

Interface and Abstract Class - Part 3


When to use an Interface

The most obvious place you'd need to use an interface rather than an abstract class is when you need to use the functionality defined in the interface across many different classes. For example, one of the techniques in Java for implementing threads is the Runnable interface, which has a single "run()" method. It is a method that will be used by who knows how many different classes so it is best implemented as an interface.

Next would be when you know you are going to have to derive things needed in your classes from several sources. Classes can only inherit from one parent class but can implement multiple interfaces. For example, the SqlCommand class in .NET has to be a child of the Component class but it also needs to implement standard methods for database commands and methods needed so it can be cloned. So it inherits from the Component class and implements the IDbCommand and ICloneable interfaces.

There are situations in some languages where you cannot use inheritance, such as in .NET when you are defining a structure. For example, the Int32 structure in .NET implements three interfaces, IComparable, IFormattable and IConvertible.

The last place you would use an interface is similar to the first rule. You would use an interface where you don't need (or don't want) to inherit from a base class. For example, you want a set of "command" classes to run the piece of functionality you have encapsulated in them, you have one that runs an FTP upload, another runs a database query, another copies some files across the network, etc. They are not similar enough to create a super-class so instead you would use an interface so they provide a standard method for accessing their functionality.

Thursday, December 04, 2003

Interface and Abstract Class - Part 2


What is an Abstract Class?

An abstract class has a couple of features that are similar to an interface: You can't instantiate an abstract class and it can contain method and property signatures. The main difference from an interface is that the abstract class can provide implementation to methods, etc.

An example abstract class could be one used for encrypting files:


Public MustInherit Class AbstractFileEncryptor
 
Public Property Key() As String
'code for the property
End Property
 
Public Property Source() As String
'code for the property
End Property
 
Public Property Target() As String
'code for the property
End Property
 
'An abstract method
Public MustOverride Sub Encrypt()
 
End Class

We give implementation to the Key, Source and Target properties because they will be used in all sub-classes and they will all have the same functionality. However we have no clue how the Encrypt() method will be implemented because the sub-classes will be for different encryption algorithms. For example:


Public Class RSAFileEncryptor : Inherits AbstractFileEncryptor
Public Overrides Sub Encrypt()
'code to implement RSA encryption
End Sub
End Class

Tomorrow: When to use which.

Tuesday, December 02, 2003

Interface and Abstract Class - Part 1


The next pattern (adapter) uses an Interface and I thought I'd have a go at simply describing what an interface is, what an abstract class is and what the difference between them is. My main reason is for the benefit of programmers who are not familiar with object oriented concepts or who had worked with Visual Basic 6, which has some strange ideas of what Interfaces and Abstract Classes are.

When .NET first came out I took a course in it to get up to speed. I had done a good bit of programming in Java so I was familiar with object oriented programming and was happy to see that the ".NET" changes that had been made to Microsoft's languages were basically a copy of Java. Suddenly VB was a real language and no longer a three-legged mongrel with a missing ear. The guy giving the course was a long term VB programmer and unfortunately it was quite plain from early on that he had a poor understanding of object oriented concepts. He told us that there was no real difference between an Interface and an Abstract Class and when I (big mouth that I am) told him they were different he said, "that may be the case in Java but not in .NET." I think his misunderstanding stemmed from the fact that VB6 didn't have class inheritance but sort of "interface inheritance" so he was stuck with the idea that inheritance had to come from something that had no code in it but just signatures.

What is an Interface?

Simply put, an interface is a sort of class with method signatures but no code. It could be described as a class with no implementation. It can contain method, event and property signatures and any class that implements the interface must implement those members. It's as if the Interface is a legal contract that says what the agreement is on how a class implementing the Interface will present itself to the world. For example if the Interface has a method "Execute()" then the implementing class must have a method with the same signature and must add the code to do whatever "Execute()" is supposed to do.

Because the Interface is just a contract you cannot instantiate an object of that type. Let's say we have an interface like this:


Public Interface InterfaceX
Property Command() As String
Sub Execute()
End Interface

You may think you can do this with it:


Dim myVar As New InterfaceX
myVar.Command = "Select * from Whatever"
myVar.Execute()

Unfortunately it won't work because an Interface is just a contract and you can't instantiate it.

So how can we use the Interface? Let's create a class that implements the Interface:


Public Class ClassX : Implements InterfaceX
Public Property Command() As String Implements InterfaceX.Command
'code goes here
End Property
 
Public Sub Execute() Implements InterfaceX.Execute
'code goes here
End Sub
End Class

Now we can do this:


Dim myVar As InterfaceX
myVar = New ClassX
myVar.Command = "Select * from Whatever"
myVar.Execute()

Well great, you say, but why didn't you just do this:


Dim myVar as New ClassX
myVar.Command = "Select * from Whatever"
myVar.Execute()

If you had one class with an Execute() method then there would be no need for an Interface, but what if you have a situation where you are going to have a collection containing many objects of 10 different classes and all will need to be processed? Are you going to write code like this?


Dim myVar1 as Class1
Dim myVar2 as Class2
'etc ...
Dim myVar10 as Class10
For n = 0 to CollectionX.Length - 1
If Typeof CollectionX(n) is Class1 then
myVar1 = CType(CollectionX(n), Class1)
myVar1.Execute()
ElseIf Typeof CollectionX(n) is Class2 then
myVar2 = CType(CollectionX(n), Class2)
myVar2.ExecuteProc()
'etc ...
ElseIf Typeof CollectionX(n) is Class10 then
myVar10 = CType(CollectionX(n), Class10)
myVar10.ExecuteStatement()
End If
Next

Wouldn't you rather do something like this?


Dim myVar as InterfaceX
For Each myVar in CollectionX
myVar.Execute()
Next

That is the beauty of an Interface.

Tomorrow: Abstract Classes

Monday, December 01, 2003

Facade Pattern (Façade Pattern)


Description

This is a very useful pattern. It is used to create a simple interface to a set of classes. Instead of having to deal with all the classes involved you just deal with the Facade class.

Example

Let's say we have a set of classes that allow us to encrypt and decrypt byte streams. What we want to do is encrypt and decrypt files, folders and entire folder trees. Any application we create will have to deal with files, folders, trees and the byte streams, that's about 8 classes right there - encrypt file, decrypt file, encrypt folder, decrypt folder, encrypt tree, decrypt tree, encryption stream and decryption stream. Well maybe if you were only going to do this sort of thing once you could just do it and to hell with the complexity. But what if you were going to have to do it in several programs or even several places within the current program, and worse still, what if you built the whole complex mess and then had to modify it? This is looking ugly. So how can we simplify it?

We create a class that has a simple public interface and we put all the logic for dealing with the other classes into this "Facade". Now any application we create only has to deal with one class with a simple interface. It doesn't have to care about the details of files, streams, etc. Now if we have to make modifications we can change the internals of the many encrytion classes without affecting the client program at all.


Public Class CryptoFacade
 
Public Property Key() As String
 
Public Property Source() As String
 
Public Property Target() As String
 
Public Property Type() As String
 
Public Sub Encrypt()
 
Public Sub Decrypt()
 
End Class

We hide the other classes in the assembly by giving them "Friend" visibilty.


Friend Class EncryptFile
'code to encrypt a file
End Class
 
Friend Class DecryptFile
'code to decrypt a file
End Class

So the Facade class provides a sort of API to the other classes, thus keeping things simple for the client class that wants to use its functionality.

References

Wikipedia - Facade Pattern
Data & Object Factory - Facade Pattern
Bob Tarr University of Maryland - Facade Pattern
Bob Tarr - Design Patterns