Principles to follow while coding

❑ Simplicity leads to better code.
Keep-It-Simple-Stupid (KISS)

❑ Don’t optimize prematurely.
It is much better to get the design of your code right and leave performance improvement as a separate task requiring separate skills,

❑ Interfaces promote flexibility of design.
Interfaces enable us to define the contract without regard to the underlying implementation. Because of this, they give us flexibility in our design by facilitating pluggability of implementation.

❑ All production code should be covered by automated unit and functional tests.
Modern development practices demand that our software be rigorously united and functionally tested to ensure the ongoing integrity of the code. In keeping with this approach, after defining the interface, but before defining any concrete implementation, we translate our functional requirements into test cases, ensuring that every assumption has been covered and confirmed.

This approach, also known as test-driven development (TDD), forces us to concentrate on the contract, the published behavior, of our classes, rather than the implementation.

❑ Assertions are a developer’s best friend.
 Check for null pointers; assert that objects are in the correct state at the start of a method, and so on.

COM

COM is totally independent of location because objects are registered in the operating system with their location.  

Now with DCOM, you can distribute your application across a network, such as your company intranet without extra code writing. And finally COM+, in the Windows 2000 OS, is the latest incarnation of COM that adds COM functionality into the operating system and provides advanced functionality, such as the Microsoft Transaction Server (MTS) and Dynamic HTML (DHTML) and other Web services.

How does this happen and what do we mean by the client and server? The client is defined by where the functionality of the server or object is needed. Thus the client calls the server to get the required functionality using the COM architecture. The server or object is defined by where the COM developer puts his/her work. COM servers can be either DLLs or EXEs. The server provides one or more objects for the client and also provides the relationship or hierarchy of the internal object functionality.

Clients view objects as black boxes that provide the functionality they require. Clients communicate with objects through interfaces, and objects, or servers, can handle more than one interface. COM interfaces are a set of related methods or functions. An interface does not describe the implementation underneath, giving the developer the option of changing how something is accomplished without having to change the whole application. Interfaces cannot be changed after they have been published. Because COM defines a standard for in memory layout of interfaces, the objects are compiler and language neutral, meaning objects can communicate without having to be written in the same language. Interfaces help with versioning and updating of objects, in that a developer can place the new functionality of an updated version in a new interface. Newer clients can query for the newer interface and use it if present, but still function with the older functionality.

Law of Demeter

Source: 
http://en.wikipedia.org/wiki/Law_of_Demeter

The Law of Demeter (LoD), or Principle of Least Knowledge, is a simple design style for developing software, particularly object-oriented programs. In this general form, the LoD is a more specific case of the Low Coupling Principle.

Each unit should have only limited knowledge about other units: only units "closely" related to the current unit.

Each unit should only talk to its friends; don't talk to strangers.

Only talk to your immediate friends.

More formally, the Law of Demeter for functions requires that a method M of an object O may only invoke the methods of the following kinds of objects:

1. O itself
2. M's parameters
3. any objects created/instantiated within M
4. O's direct component objects
5. a global variable, accessible by O, in the scope of M

The advantage of following the Law of Demeter is that the resulting software tends to be more maintainable and adaptable. Since objects are less dependent on the internal structure of other objects, object containers can be changed without reworking their callers.
A disadvantage of the Law of Demeter is that it sometimes requires writing a large number of small “wrapper” methods (sometimes referred to as Demeter Transmogrifiers) to propagate method calls to the components

UI Concepts

A user interface is well designed when the program behaves exactly how the user thought it would.

A user interface is well designed when the program model conforms to the user model.

A new user who sits down to use a program does not come with a completely blank slate. They have some expectations of how they think the program is going to work. This is called the user model: it is their mental understanding of what the program will do for them.

The program, too, has a model, only this one is encoded in bits and will be faithfully executed by the CPU. This is called the program model, and it is The Law. Nothing short of electrical storms and cosmic rays can convince a CPU to disobey the program model.

Let's look at another example. In Microsoft Word (and most word processors), when you put a picture in your document, the picture is actually embedded in the same file as the document itself. You can create the picture, drag it into the document, then delete the original picture file, but the picture will still remain in the document.
Now, HTML doesn't let you do this. HTML documents must store their pictures in a separate file. If you take a user who is used to word processors and doesn't know anything about HTML, then sit them down in front of a nice WYSIWYG HTML editor like Microsoft FrontPage, they will almost certainly think that the picture is going to be stored in the file. 

Call this user model inertia, if you will. So, we have an unhappy conflict of user model (the picture will be embedded) versus program model (the picture must be in a separate file), and the UI is bound to cause problems.