Shahzad Bhatti Welcome to my ramblings and rants!

Law of Demeter (LoD)
The Law of Demeter was originally formulated as a style rule for
designing object-oriented systems. “Only talk to your immediate friends”
is the motto. The style rule was discovered at Northeastern University
in the fall of 1987 by Ian Holland.
A more general formulation of the Law of Demeter is: Each unit should
have only limited knowledge about other units: only units “closely”
related to the current unit. Or: Each unit should only talk to its
friends; Don’t talk to strangers.

In this general form, the LoD is a more specific case of the Low
Coupling Principle well-known in software engineering. The Low Coupling
Principle is very general and we tried to make it more specific. The
benefit of the specific Law of Demeter shown below is that it makes the
notion of unnecessary coupling very explicit.

The main motivation for the Law of Demeter is to control information
overload; we can only keep a limited set of items in short-term memory
and it is easier to keep them in memory if they are closely related. The
definition of “closely related” is intentionally left vague so that it
can be adapted to particular circumstances.

In the application of LoD to object-oriented design and programming we
have:
unit = method f
closely related = methods of class of this/self of f and other argument
classes of f and methods of immediate part classes (both computed and
stored) of class of f (classes that are return types of methods of class
of this/self (= computed) and the classes of data members (= stored))
and methods of classes of objects that are created in f.

Bayesian Filter
Finished implementation of Bayesian Filter to detect SPAM. Now, I need to gather couple of thousand emails (good and bad) to test it.

Few interesting articles today (June 16, 2003):

1. J2EE Clustering with JBoss: Singleton and Scheduler Services
2. ONJava Article on JBoss 3 Clustering
3. Make the Java-Oracle9i connection Put Oracle9i’s object-oriented features to work

Well, I am not at the JavaOne, but plan to read each day’s highlights.
Hopefully, sun will release PDF and powerpoint slides.

OO Summary

OO Principles:

1. Encapsulation – information and implementation hiding
2. Inheritance – interface and implementation inheritance
3. Polymorphism – ability of different objects to respond differently
   to the same message. Inheritance polymorphism, operational polymorphism.

Design Principles:

1. Single Responsibility Principle (SRP) – cohesion
2. Open/Closed Principle – open to extension but closed to modification
3. Liskov Substitution Principle – subclass can be substitute for their
   base classes. Design by contract – polymorphic method of a subclass
   can only replace its pre-condition by a weaker one and its
   post condition by a stronger one.

4. Dependency Inversion Principle (DIP) – high level modules shouldn’t depend
   on low-level modules. abstraction should not depend on details.
   
   dependencies should point in the direction of abstraction.

5. Interface Separation Principle

Stability and Instability

1. Acyclic Dependency Principle – prohibits cyclic dependencies among packages
   
   The dependencies among mdoules must be arranged in Directed Acyclic Graph

2. Package Cohesion
   1. Common Closure Principle – classes that change together belong together
      
      Code with different kinds of volatility should be placed in different modules.
      Modules should not depend on other modules that are more volatile than they
      are.
      volatile code goes into instable modules, vice verse.

   2. Reuse/Release Equivalency Principle – release granularity equal to reuse granularity
   3. Common Reuse Principle – classes that aren’t reused jointly shouldn’t be grouped together
3. Stable Dependency Principle – reinforce package stability
   
   no modules should depend on a module that is less stable than it is
   
   Ce # of modules that this module depend on
   
   Ca # of modules that depend on this module
   
   Instability (I) = Ce / (Ca – Ce)
   
   If I is 1 the module is instable and 0 means module is very stable.

4. Stable Abstraction Principle – stable packages should be abstract
   
   more stable module is, the more abstract it should be
   
   Abstractness = Na / Nc, where Na is the number of abstract/interfaces and Nc
   is number of classes in the module
   
   D = |A + I – 1|
   
   0 means module is on the main sequence and 1 means it is far from the sequence

Golden Rules

1. it contains no dependencies cycles (ADP)
2. Every dependency between modules should terminate on a module whose I metric is less than or equal to the depending mdoules’ I metric (SDP).
3. Every dependency between modules should terminate on a module whose A metric is greater than or equal to the depending module’s A metric (SAP).

With JSP, there are two different kinds of content to include: static and dynamic. The include directive shown here:

<%@ include file=”include/copyright.inc” %>
includes the source of the target page at translation/compile time. Therefore, it’s not possible to include runtime content using the include directive. The JSP include directive treats a resource as a static object, and the context of the resource is included literally in the page.

In direct contrast, the include action

handles the resource as a dynamic object. The request is sent to the resource, and the result of the processing is included. Templates use a dynamic approach so that runtime expressions can be evaluated and included.