Predictive Techniques of Bhrigu Nadi
by Dr.Shanker Adawal
A planet changes its character, depending upon the Sign and the house it occupies, the lordship of that Sign and also the vibrations it receives from the other planets, posited in other Sign. Here, let us study the behavior of Mars.
Significations of Mars
Agriculture, accidents, brothers, blood, carbuncle, commander-in –chief, cracks-in-flesh, courage, debts, fire, goldsmith, hemorrhage, injuries, instant death, sensuality, lacks morale, land, house, liberality, love, madness, passion, rage and strength. Lord Subramanya, vanity, wounds, bold speech, success in efforts, keen interest, bilious an windy complaints, mean life, criminal law, astrology, practice of mantras, atomic energy. Electrical, chemical and mechanical engineering, mining, military, electricity, petrol., ammunition, weapons, lime kilns, brick works, base metals, cruelty, hatred, odium, kitchen, gold, relatives, thieves, falsehood, butchery, red wine, enemy, quadruped, foreign travel, automobiles, machinery, youth, pungent taste, assembly-hall, flesh-eating, summer season, Lord Brahma, Sama Veda, iron, tending wild animals, independence, assertive nature, persistence, restlessness, coral, laboratories, skill in archery, southern direction, calumny, gossip, bakeries, drying of blood, head of a village, leanness.
The various effects produced by Mars, posited in different houses are as follows:
Mars in the ascendant
Wound marks on the body or marks left behind by boils, itches and the like, stealing habit, medium size, cruel hearted, excess of anger, extraordinary, valor, suffers from a peculiar disease, association with low-class people.
* If exalted, or in its own house – Enjoys excellent health, well-built body, reputation, favors from highly-placed people, long life, financial prosperity, learned.
* If in enemy or malefic house – Poor longevity, few children, ugly-looking face.
* If conjunct or aspected by malefic(s) or occupying a malefic house – Eye disease.
Mars in the 2nd House
Poor education.
* If Mars, as the lord of the 11th, is posited in the 6th, the 12th or the 2nd house – Eye trouble. If aspected by a benefic – Good eye sight will result.
* If exalted or in own house – Higher education, good eyesight.
* If in malefic house or aspected by malefic – Eye-related ailments.
Mars in the 3rd House
Native’s wife will be of questionable character.
* If aspected by a benefic – No blemish in wife’s character, no younger brother, poor income.
* If Conjunct Rahu or Ketu – Intimacy with women of questionable character, bitterness with brothers, few brothers.
* If conjunct or aspected by malefics – Loss of brothers.
* If exalted or in own house, aspected by a benefic – Prosperity, longevity for brothers, valorous.
* If aspected by a friendly house – Weak constitution.
* If occupying a friendly house – Courageous
Mars in the 4th House
Domestic adversities, death of father in the 8th year, ill health to mother.
* If conjunct benefics – The native may not own a house; he may have to live in another’s house; he may have to live in an old or indecent house; poor income; failure in agriculture.
* If conjunct benefic and exalted or in own house or in a friendly house – Courageous, property, long life for mother.
* If debilitated or conjunct malefic – Loss of mother, enmity with relatives, staying away from the native place, want of clothes and food.
Mars in the 5th House
Poor income, no children, ungentlemanly actions, official disfavors, suffering from wounds or cuts in the 16th year, very shrewd.
* If exalted or in own house – Good number of children, authoritative position, trouble from enemies.
* Aspected or conjunct malefic – Loss of children, mental disorder and allied diseases.
* If Mars is the lord of the 8th from the ascendant and conjunct malefic – The native will become valorous, may be given away in adoption.
Mars in the 6th House
Reputation, capability to achieve success in undertaking, defeats enemies, marital happiness, acquisition of conveyance in the 27th year.
* In malefic house, in conjunction with a malefic or subject to malefic aspect – The above effects will be enjoyed in full measure. Rheumatic and shooting pains.
* If posited in Virgo or Gemini Signs – Possibility of Leprosy
* If aspected by a benefic – No such diseases as above.
Mars in the 7th House
If mars is in the 7th from the ascendant, in a malefic Sign/ or conjunct malefic (even if the 7 the house happens to be Aries or Scorpio) – Loss of wife.
* If conjunct or aspected by a benefic – The above malefic effects will not occur, Foreign travel.
* If conjunct benefic and in exaltation, own house or friendly house with malefic aspect – Loss of wife or intimacy with a woman, other than his wife, sexual perversions.
* If conjunction with Saturn – Sexual perversion.
* If conjunct Ketu – Contacts with women. If there is also another malefic in conjunction – Loss of more than one wife
* In conjunct ketu, receiving benefic aspect – Good character
* If Mars is conjunct or aspected by its enemy – Loss of wife.
* If conjunct of Rahu – Intimacy with the servant-maid or a widow.
Mars in the 8th House
Eye diseases, longevity below 60, loss of father, urinary diseases, few children.
* If conjunct benefic – Good health, good longevity.
* If occupying a malefic house or conjunct or aspected by malefics – Rheumatic diseases, Tuberculosis.
* If strongly disposed – Full longevity.
Mars in the 9th house
If mars is strong – Prosperity, adultery.
Mars in the 10th house
When favorably disposed, Long- lived brothers, good prosperity, interest in charity and hymns, devotional disposition.
* If conjunct malefic – Failure in understanding, professional reverses, loss of reputation, capable of professional earning from the 18th year, stealing habit, robust constitution.
* If conjunct with lords of the 9th or the 10th – Raja yoga will arise.
* If conjunct Jupiter – Gain of landed property
Mars in the 11th house
Besides enjoying financial prosperity, the native will become a man of manifold activities.
* If conjunct with the lord of 11th – Head of a township.
* If conjunct benefic – - Prosperous brothers, very good Raja yoga is formed, prosperity.
Mars in the 12th House
Rheumatic problems, ungentlemanly actions, sinful deeds, inadequate income.
March 5, 2006
Wednesday, February 17, 2010
Tuesday, February 16, 2010
Understanding Interfaces in .NET
by Nick Harrison
06/30/2003
.NET introduces the concept of an interface. The interface concept is potentially confusing. An interface is a contract that defines the signature of some piece of functionality. Throughout the .NET framework, interfaces are used to define that certain types have well-known behaviors. For example, the ICloneable interface specifies that a .NET type can be cloned and defines a specific programming signature for how cloning is performed. In this way, an interface both advertises a specific functionality or behavior for a .NET type and also defines the method/property signature for the behavior.
In .NET, an object can be derived from a single ancestor, yet implement any number of interfaces. There is no problem with multiple interfaces defining a common method; the object being defined would only implement the common method once. This is the difference between interfaces and inheritance. When a class is derived from another class, it automatically inherits all of the methods and properties of the ancestor. The work for the derived class is to override any methods that will be different and extend the functionality as needed. When a class implements an interface, the compiler is flagged about what methods, properties, etc. the class being defined must include, and ensures that you do so.
In this article, we will review some places where interfaces are used in .NET, talk about why you would want to define your own interface, and step through an example of defining and implementing your very own interface.
==========================================================================
Applications You Never Thought Of
As you learn .NET, you will see interfaces used in many places. In an earlier article, I showed how interfaces are pivotal in building a database access layer independent of the actual database type. As another example, we are all also familiar with the foreach loop:
foreach (type identifier in expression) statement
Related Reading
.NET Framework Essentials
By Thuan L. Thai, Hoang Lam
This simple looping structure is based on interfaces. There are two requirements in using a foreach loop to which most of us never give a second thought.
1. The expression must implement the IEnumerable interface.
2. The items in the collection must be convertible to the type specified.
If you have done any work with data-bound controls, you are no doubt familiar with the DataSource property. If you look at the help for this property, you will see that it expects a value that implements the IEnumerable interface as well.
This means that any class that you create can be used as a DataSource or iterated through using the foreach loop, just like the standard built-in classes, by simply implementing the IEnumerable interface. There are several other interfaces woven into the .NET framework that simplify embedding your custom classes into the .NET framework.
* IComparable is used to ensure that your class is sortable.
* IClonable is used to ensure that your class can be cloned. Cloning simply creates another instance of the class -- a duplicate of the original.
* IFormattable is used to change the behavior when a user of your class invokes the ToString method.
* IDisposable is used to provide functionality to release any unmanaged resources, such as COM objects, that your class may be using.
Properly using these interfaces will make classes that you write integrate more tightly with the .NET framework, which will make them behave more predictably when someone tries to use them. Not only can you implement these and other predefined interfaces, you can also define custom interfaces to use in your design.
===============================================================================
Interfaces of Your Own Design
Before diving into the details of how to define an interface, let's explore why you would want to. One reason might be to further separate the UI from the business logic, or to better define what the UI is doing. For example, imagine an interface called IMemberProfile that simply defines properties for all of the relevant fields in a member profile. Now, a web page that allows your users to view or edit their profile would not only inherit from System.Web.UI.Page, but it may also implement your custom IMemberProfile interface. Not only could a web page implement this interface, but so could a MobilePage, a Windows Form, a UserControl, a CustomControl, etc. Any method that you write expecting an IMemberProfile won't care about the base class used. The only thing that it cares about is that the class fulfills all of the requirements for implementing the interface. These methods won't care whether the property references a local variable, a drop-down menu, a text box, a database, or an XML stream. The only thing that matters is that the required properties are implemented.
If all of your business logic was implemented with methods expecting such custom interfaces, then not only would it be easy to target multiple UIs, but each UI would be protected from changes to the data requirements. If a new data value is ever required in any function call, then in the worst case, a new property would be added to the interface definition and each UI would have to implement that new property. Individual function calls would not have to change, since they are always simply passing "this," or "me" in VB.
Defining the ImemberProfile Interface
Defining an interface is a lot like defining a class, except that you don't have to get involved in the details about how anything will work. It is a lot like the header files in C/C++. For example:
public interface IMemberProfile
{
string FirstName {get;set;}
string LastName {get;set;}
string Email {get;set;}
System.Guid MemberID {get;set;}
}
This example defines an interface that will require that any class implementing it must provide read/write properties for FirstName, LastName, Email, and MemberID.
Implementing the IMemberProfile Interface
To implement an interface, you start by marking that the class you are defining will implement the interface. In C#, this is similar to the syntax for inheritance.
public class MemberProfile: System.Web.UI.Page, IMemberProfile
In VB.NET, the syntax is slightly different.
Public Class MemberProfile
Inherits System.Web.UI.Page
Implements IMemberProfile
The compiler will handle warning you about anything that the interface requires that is not included in your class. For this example, you simply need to include properties for FirstName, LastName, Email, and MemberID.
public string FirstName
{
get{return txtFirstName.Text ;}
set {txtFirstName.Text = value;}
}
public string LastName
{
get{return txtLastName.Text ;}
set {txtLastName.Text = value;}
}
public string Email
{
get{return txtEmail.Text ;}
set {txtEmail.Text = value;}
}
public System.Guid MemberID
{
get
{
if (m_uniqueID.CompareTo (null) == 0)
{
m_uniqueID = System.Guid.NewGuid();
}
return m_uniqueID;
}
set
{
m_uniqueID = value;
}
}
Implementing an interface really requires nothing more than the rules of encapsulation would recommend.
Using Your Interface
Now that we have the interface defined and a UI that implements the interface, we are ready to write some business logic that will use this interface. Here we define two methods that will be used to retrieve the data to populate the UI, as well as a method to retrieve the data currently populated in the UI. In a real-world example, these methods would use a database to store the details. To keep this example simple, we will simply use local variables. To truly appreciate what is happening in this example, I recommend stepping through the code with the debugger and watching the properties being accessed.
The method to retrieve the current member profile details would be similar to this:
public static void RetrieveMemberProfile (IMemberProfile Profile)
{
Profile.FirstName = "John";
Profile.LastName = "Doe";
Profile.Email = "jdoe@email.com";
Profile.MemberID =
new System.Guid
("{65C38236-CA96-4FF1-9142-00873B8BD333}");
}
The method to update the member profile details would be similar to this:
public static void UpdateMemberProfile (IMemberProfile Profile)
{
string _FirstName;
string _LastName;
string _Email;
string _MemberID;
_FirstName = Profile.FirstName;
_LastName = Profile.LastName;
_Email = Profile.Email;
_MemberID = Profile.MemberID.ToString();
}
In the Page_Load event, we will call the RetrieveMemberProfile method like this:
private void Page_Load(object sender, System.EventArgs e)
{
// Put user code to initialize the page here
if (!Page.IsPostBack)
{
BusinessRules.RetrieveMemberProfile (this);
}
}
The click event handler for the button will look similar to this:
private void btnUpdate_Click(object sender, System.EventArgs e)
{
BusinessRules.UpdateMemberProfile (this);
}
Conclusion
From this simple example, we have seen the advantages of using the built-in interfaces. We have also seen how easy it is to define and implement a custom interface, as well as a practical example of doing so and how this process can lead to a stronger separation between the UI and the business logic.
Nick Harrison UNIX-programmer-turned-.NET-advocate currently working in Charlotte, North Carolina using .NET to solve interesting problems in the mortgage industry.
06/30/2003
.NET introduces the concept of an interface. The interface concept is potentially confusing. An interface is a contract that defines the signature of some piece of functionality. Throughout the .NET framework, interfaces are used to define that certain types have well-known behaviors. For example, the ICloneable interface specifies that a .NET type can be cloned and defines a specific programming signature for how cloning is performed. In this way, an interface both advertises a specific functionality or behavior for a .NET type and also defines the method/property signature for the behavior.
In .NET, an object can be derived from a single ancestor, yet implement any number of interfaces. There is no problem with multiple interfaces defining a common method; the object being defined would only implement the common method once. This is the difference between interfaces and inheritance. When a class is derived from another class, it automatically inherits all of the methods and properties of the ancestor. The work for the derived class is to override any methods that will be different and extend the functionality as needed. When a class implements an interface, the compiler is flagged about what methods, properties, etc. the class being defined must include, and ensures that you do so.
In this article, we will review some places where interfaces are used in .NET, talk about why you would want to define your own interface, and step through an example of defining and implementing your very own interface.
==========================================================================
Applications You Never Thought Of
As you learn .NET, you will see interfaces used in many places. In an earlier article, I showed how interfaces are pivotal in building a database access layer independent of the actual database type. As another example, we are all also familiar with the foreach loop:
foreach (type identifier in expression) statement
Related Reading
.NET Framework Essentials
By Thuan L. Thai, Hoang Lam
This simple looping structure is based on interfaces. There are two requirements in using a foreach loop to which most of us never give a second thought.
1. The expression must implement the IEnumerable interface.
2. The items in the collection must be convertible to the type specified.
If you have done any work with data-bound controls, you are no doubt familiar with the DataSource property. If you look at the help for this property, you will see that it expects a value that implements the IEnumerable interface as well.
This means that any class that you create can be used as a DataSource or iterated through using the foreach loop, just like the standard built-in classes, by simply implementing the IEnumerable interface. There are several other interfaces woven into the .NET framework that simplify embedding your custom classes into the .NET framework.
* IComparable is used to ensure that your class is sortable.
* IClonable is used to ensure that your class can be cloned. Cloning simply creates another instance of the class -- a duplicate of the original.
* IFormattable is used to change the behavior when a user of your class invokes the ToString method.
* IDisposable is used to provide functionality to release any unmanaged resources, such as COM objects, that your class may be using.
Properly using these interfaces will make classes that you write integrate more tightly with the .NET framework, which will make them behave more predictably when someone tries to use them. Not only can you implement these and other predefined interfaces, you can also define custom interfaces to use in your design.
===============================================================================
Interfaces of Your Own Design
Before diving into the details of how to define an interface, let's explore why you would want to. One reason might be to further separate the UI from the business logic, or to better define what the UI is doing. For example, imagine an interface called IMemberProfile that simply defines properties for all of the relevant fields in a member profile. Now, a web page that allows your users to view or edit their profile would not only inherit from System.Web.UI.Page, but it may also implement your custom IMemberProfile interface. Not only could a web page implement this interface, but so could a MobilePage, a Windows Form, a UserControl, a CustomControl, etc. Any method that you write expecting an IMemberProfile won't care about the base class used. The only thing that it cares about is that the class fulfills all of the requirements for implementing the interface. These methods won't care whether the property references a local variable, a drop-down menu, a text box, a database, or an XML stream. The only thing that matters is that the required properties are implemented.
If all of your business logic was implemented with methods expecting such custom interfaces, then not only would it be easy to target multiple UIs, but each UI would be protected from changes to the data requirements. If a new data value is ever required in any function call, then in the worst case, a new property would be added to the interface definition and each UI would have to implement that new property. Individual function calls would not have to change, since they are always simply passing "this," or "me" in VB.
Defining the ImemberProfile Interface
Defining an interface is a lot like defining a class, except that you don't have to get involved in the details about how anything will work. It is a lot like the header files in C/C++. For example:
public interface IMemberProfile
{
string FirstName {get;set;}
string LastName {get;set;}
string Email {get;set;}
System.Guid MemberID {get;set;}
}
This example defines an interface that will require that any class implementing it must provide read/write properties for FirstName, LastName, Email, and MemberID.
Implementing the IMemberProfile Interface
To implement an interface, you start by marking that the class you are defining will implement the interface. In C#, this is similar to the syntax for inheritance.
public class MemberProfile: System.Web.UI.Page, IMemberProfile
In VB.NET, the syntax is slightly different.
Public Class MemberProfile
Inherits System.Web.UI.Page
Implements IMemberProfile
The compiler will handle warning you about anything that the interface requires that is not included in your class. For this example, you simply need to include properties for FirstName, LastName, Email, and MemberID.
public string FirstName
{
get{return txtFirstName.Text ;}
set {txtFirstName.Text = value;}
}
public string LastName
{
get{return txtLastName.Text ;}
set {txtLastName.Text = value;}
}
public string Email
{
get{return txtEmail.Text ;}
set {txtEmail.Text = value;}
}
public System.Guid MemberID
{
get
{
if (m_uniqueID.CompareTo (null) == 0)
{
m_uniqueID = System.Guid.NewGuid();
}
return m_uniqueID;
}
set
{
m_uniqueID = value;
}
}
Implementing an interface really requires nothing more than the rules of encapsulation would recommend.
Using Your Interface
Now that we have the interface defined and a UI that implements the interface, we are ready to write some business logic that will use this interface. Here we define two methods that will be used to retrieve the data to populate the UI, as well as a method to retrieve the data currently populated in the UI. In a real-world example, these methods would use a database to store the details. To keep this example simple, we will simply use local variables. To truly appreciate what is happening in this example, I recommend stepping through the code with the debugger and watching the properties being accessed.
The method to retrieve the current member profile details would be similar to this:
public static void RetrieveMemberProfile (IMemberProfile Profile)
{
Profile.FirstName = "John";
Profile.LastName = "Doe";
Profile.Email = "jdoe@email.com";
Profile.MemberID =
new System.Guid
("{65C38236-CA96-4FF1-9142-00873B8BD333}");
}
The method to update the member profile details would be similar to this:
public static void UpdateMemberProfile (IMemberProfile Profile)
{
string _FirstName;
string _LastName;
string _Email;
string _MemberID;
_FirstName = Profile.FirstName;
_LastName = Profile.LastName;
_Email = Profile.Email;
_MemberID = Profile.MemberID.ToString();
}
In the Page_Load event, we will call the RetrieveMemberProfile method like this:
private void Page_Load(object sender, System.EventArgs e)
{
// Put user code to initialize the page here
if (!Page.IsPostBack)
{
BusinessRules.RetrieveMemberProfile (this);
}
}
The click event handler for the button will look similar to this:
private void btnUpdate_Click(object sender, System.EventArgs e)
{
BusinessRules.UpdateMemberProfile (this);
}
Conclusion
From this simple example, we have seen the advantages of using the built-in interfaces. We have also seen how easy it is to define and implement a custom interface, as well as a practical example of doing so and how this process can lead to a stronger separation between the UI and the business logic.
Nick Harrison UNIX-programmer-turned-.NET-advocate currently working in Charlotte, North Carolina using .NET to solve interesting problems in the mortgage industry.
Sunday, February 14, 2010
Abstract Factory
Abstract Factory
The Gang of Four defintion for this design pattern is: "Provide an interface for creating families of related or dependant objects without specifying their concrete classes.".
A VB example of the Abstract Factory Design Pattern
' This code could be run at the page behind level
Dim aCarFactory As CarFactory
' Ideally we would use the Factory Design pattern
' but I omitted this for simplicity
If aVariable = "Ford" Then
aCarFactory = New FordCarFactory
Else
aCarFactory = New VauxhallCarFactory
End If
' Build 2 family cars
Dim aFamilyCar1 As ICar = aCarFactory.CreateFamilyCar
Dim aFamilyCar2 As ICar = aCarFactory.CreateFamilyCar
' Build a City Car
Dim aCityCar As ICar = aCarFactory.CreateCityCar
' The base class Car Factory
Public MustInherit Class CarFactory
Public MustOverride Function CreateFamilyCar() As ICar
Public MustOverride Function CreateCityCar() As ICar
End Class
' The concrete Ford car factory
Public Class FordCarFactory
Inherits CarFactory
Public Overrides Function CreateCityCar() As ICar
Return New FordCityCar
End Function
Public Overrides Function CreateFamilyCar() As ICar
Return New FordFamilyCar
End Function
End Class
' The concrete Vauxhall car factory
Public Class VauxhallCarFactory
Inherits CarFactory
Public Overrides Function CreateCityCar() As ICar
Return New VauxhallCityCar
End Function
Public Overrides Function CreateFamilyCar() As ICar
Return New VauxhallFamilyCar
End Function
End Class
' The Car Interface, all cars must implement these methods
Public Interface ICar
Sub Drive()
Function Desc() As String
End Interface
' The concrete Ford Family Car
Public Class FordFamilyCar
Implements ICar
Public Sub Drive() Implements ICar.Drive
' Drive car
End Sub
Public Function Desc() As String Implements ICar.Desc
Return "Ford Family Car seats 8"
End Function
End Class
' The concrete Ford City Car
Public Class FordCityCar
Implements ICar
Public Sub Drive() Implements ICar.Drive
' Drive car
End Sub
Public Function Desc() As String Implements ICar.Desc
Return "Ford Ciy Car seats 2"
End Function
End Class
' The concrete Vauxhall City Car
Public Class VauxhallCityCar
Implements ICar
Public Sub Drive() Implements ICar.Drive
' Drive car
End Sub
Public Function Desc() As String Implements ICar.Desc
Return "Vauxhall Ciy Car seats 4"
End Function
End Class
' The concrete Vauxhall Family Car
Public Class VauxhallFamilyCar
Implements ICar
Public Sub Drive() Implements ICar.Drive
' Drive car
End Sub
Public Function Desc() As String Implements ICar.Desc
Return "Vauxhall Family Car seats 6"
End Function
End Class
The Gang of Four defintion for this design pattern is: "Provide an interface for creating families of related or dependant objects without specifying their concrete classes.".
A VB example of the Abstract Factory Design Pattern
' This code could be run at the page behind level
Dim aCarFactory As CarFactory
' Ideally we would use the Factory Design pattern
' but I omitted this for simplicity
If aVariable = "Ford" Then
aCarFactory = New FordCarFactory
Else
aCarFactory = New VauxhallCarFactory
End If
' Build 2 family cars
Dim aFamilyCar1 As ICar = aCarFactory.CreateFamilyCar
Dim aFamilyCar2 As ICar = aCarFactory.CreateFamilyCar
' Build a City Car
Dim aCityCar As ICar = aCarFactory.CreateCityCar
' The base class Car Factory
Public MustInherit Class CarFactory
Public MustOverride Function CreateFamilyCar() As ICar
Public MustOverride Function CreateCityCar() As ICar
End Class
' The concrete Ford car factory
Public Class FordCarFactory
Inherits CarFactory
Public Overrides Function CreateCityCar() As ICar
Return New FordCityCar
End Function
Public Overrides Function CreateFamilyCar() As ICar
Return New FordFamilyCar
End Function
End Class
' The concrete Vauxhall car factory
Public Class VauxhallCarFactory
Inherits CarFactory
Public Overrides Function CreateCityCar() As ICar
Return New VauxhallCityCar
End Function
Public Overrides Function CreateFamilyCar() As ICar
Return New VauxhallFamilyCar
End Function
End Class
' The Car Interface, all cars must implement these methods
Public Interface ICar
Sub Drive()
Function Desc() As String
End Interface
' The concrete Ford Family Car
Public Class FordFamilyCar
Implements ICar
Public Sub Drive() Implements ICar.Drive
' Drive car
End Sub
Public Function Desc() As String Implements ICar.Desc
Return "Ford Family Car seats 8"
End Function
End Class
' The concrete Ford City Car
Public Class FordCityCar
Implements ICar
Public Sub Drive() Implements ICar.Drive
' Drive car
End Sub
Public Function Desc() As String Implements ICar.Desc
Return "Ford Ciy Car seats 2"
End Function
End Class
' The concrete Vauxhall City Car
Public Class VauxhallCityCar
Implements ICar
Public Sub Drive() Implements ICar.Drive
' Drive car
End Sub
Public Function Desc() As String Implements ICar.Desc
Return "Vauxhall Ciy Car seats 4"
End Function
End Class
' The concrete Vauxhall Family Car
Public Class VauxhallFamilyCar
Implements ICar
Public Sub Drive() Implements ICar.Drive
' Drive car
End Sub
Public Function Desc() As String Implements ICar.Desc
Return "Vauxhall Family Car seats 6"
End Function
End Class
Factory
The job of the Factory design pattern is to create concrete sub classes. You can see the Factory design pattern used throughout the .NET Framework.
The essence of the Factory Pattern is to "Define an interface for creating an object, but let the subclasses decide which class to instantiate. The Factory method lets a class defer instantiation to subclasses." Factory methods encapsulate the creation of objects. This can be useful if the creation process is very complex, for example if it depends on settings in configuration files or on user input.
A C# example of the Factory Pattern
// A Simple Interface
public interface IVehicle
{
void Drive(int miles);
}
// The Vehicle Factory
public class VehicleFactory
{
public static IVehicle getVehicle(string Vehicle)
{
switch (Vehicle) {
case "Car":
return new Car();
case "Lorry":
return new Lorry();
default:
throw new ApplicationException(string.Format("Vehicle '{0}' cannot be created", Vehicle));
break;
}
}
}
// A Car Class that Implements the IVehicle Interface
public class Car : IVehicle
{
public void IVehicle.Drive(int miles)
{
// Drive the Car
}
}
// A Lorry Class that Implements the IVehicle Interface
public class Lorry : IVehicle
{
public void IVehicle.Drive(int miles)
{
// Drive the Lorry
}
}
A VB example of the Factory Pattern
' A Simple Interface
Public Interface IVehicle
Sub Drive(ByVal miles As Integer)
End Interface
' The Vehicle Factory
Public Class VehicleFactory
Public Shared Function getVehicle(ByVal Vehicle As String) As IVehicle
Select Case Vehicle
Case "Car"
Return New Car
Case "Lorry"
Return New Lorry
Case Else
Throw New ApplicationException(String.Format("Vehicle '{0}' cannot be created", Vehicle))
End Select
End Function
End Class
' A Car Class that Implements the IVehicle Interface
Public Class Car
Implements IVehicle
Public Sub Drive(ByVal miles As Integer) Implements IVehicle.Drive
' Drive the Car
End Sub
End Class
' A Lorry Class that Implements the IVehicle Interface
Public Class Lorry
Implements IVehicle
Public Sub Drive(ByVal miles As Integer) Implements IVehicle.Drive
' Drive the Lorry
End Sub
End Class
UML
Factory Design Pattern
The essence of the Factory Pattern is to "Define an interface for creating an object, but let the subclasses decide which class to instantiate. The Factory method lets a class defer instantiation to subclasses." Factory methods encapsulate the creation of objects. This can be useful if the creation process is very complex, for example if it depends on settings in configuration files or on user input.
A C# example of the Factory Pattern
// A Simple Interface
public interface IVehicle
{
void Drive(int miles);
}
// The Vehicle Factory
public class VehicleFactory
{
public static IVehicle getVehicle(string Vehicle)
{
switch (Vehicle) {
case "Car":
return new Car();
case "Lorry":
return new Lorry();
default:
throw new ApplicationException(string.Format("Vehicle '{0}' cannot be created", Vehicle));
break;
}
}
}
// A Car Class that Implements the IVehicle Interface
public class Car : IVehicle
{
public void IVehicle.Drive(int miles)
{
// Drive the Car
}
}
// A Lorry Class that Implements the IVehicle Interface
public class Lorry : IVehicle
{
public void IVehicle.Drive(int miles)
{
// Drive the Lorry
}
}
A VB example of the Factory Pattern
' A Simple Interface
Public Interface IVehicle
Sub Drive(ByVal miles As Integer)
End Interface
' The Vehicle Factory
Public Class VehicleFactory
Public Shared Function getVehicle(ByVal Vehicle As String) As IVehicle
Select Case Vehicle
Case "Car"
Return New Car
Case "Lorry"
Return New Lorry
Case Else
Throw New ApplicationException(String.Format("Vehicle '{0}' cannot be created", Vehicle))
End Select
End Function
End Class
' A Car Class that Implements the IVehicle Interface
Public Class Car
Implements IVehicle
Public Sub Drive(ByVal miles As Integer) Implements IVehicle.Drive
' Drive the Car
End Sub
End Class
' A Lorry Class that Implements the IVehicle Interface
Public Class Lorry
Implements IVehicle
Public Sub Drive(ByVal miles As Integer) Implements IVehicle.Drive
' Drive the Lorry
End Sub
End Class
UML
Factory Design Pattern
Design Patterns
Refer :http://wiki.asp.net/page.aspx/276/design-patterns/
Design patterns are recognized solutions to common problems defined originally by the Gang of Four programmers. Design patterns are used throughout the ASP.NET Framework. The various patterns are commonly divided into several different groups depending on the nature of the design problem they intend to solve.
Creational Patterns
* Factory - This pattern is used to create concrete class instances without specifying the exact class type.
* Abstract Factory - This pattern is used to create concrete class instances without specifying the exact class type. The Abstract Factory Pattern provides a way to encapsulate a group of individual factories that have a common theme.
* Flyweight - A pattern used to maximize the sharing of objects resulting in reduced memory consumption.
* Singleton - This pattern insures that only a single instance of a given object can exist.
* Builder - This pattern separate the construction of a complex object from its representation so that the same construction process can create different representations..
Structural Patterns
* Adapter - Convert the interface of a class into another interface clients expect. Adapter lets the classes work together that couldn't otherwise because of incompatible interfaces
* Bridge - Decouples an abstraction from its implementation so that the two can vary independantly.
* Composite - Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly.
* Decorator - Allows an objects behavior to be altered at runtime.
* Facade - Used to provide a simpler interface into a more complicated portion of code.
* Proxy - Provides a Placeholder for another object to control access to it.
Behavioral Patterns
* Chain of Responsibility - The chain of responsibility pattern is a way of communicating between objects.
* Command - Encapsulates a request as an object, thereby letting you parameterize clients with different requests, queue or log requests, and support undoable operations.
* Iterator - Provides a way to sequentially access aggregate objects without exposing the structure of the aggregate.
* Mediator - The mediator pattern encapsulate the interaction between a set of objects.
* Memento - Allows you to save the state of an object externally from that object.
* Observer - Allows a single object to notify many dependent objects that its state has changed.
* State - Allows an object to change its behaviour when its internal state changes.
* Strategy - Allows multiple algorithms to be used interchangeably at runtime.
* Visitor - The visitor design pattern enables us to create new operations to be performed on an existing structure.
* Template Method - Defines the skeleton of an algorithm then lets subclasses implement the behaviour that can vary.
Antipatterns
Antipatterns are misapplied design patterns. Common Antipatterns include:
*
The Blob/God Object - When one class contains all of the methods, operations and logic of your application
*
Re-coupling - building an unnecessary dependency between objects
*
Poltergeists - object whose main purpose in life is to pass messages to another object
*
Sequential Coupling - a class that imposes a particular order on its method calls.
Other patterns
* Aggregator Provider Pattern
* Lazy loading
Design patterns are recognized solutions to common problems defined originally by the Gang of Four programmers. Design patterns are used throughout the ASP.NET Framework. The various patterns are commonly divided into several different groups depending on the nature of the design problem they intend to solve.
Creational Patterns
* Factory - This pattern is used to create concrete class instances without specifying the exact class type.
* Abstract Factory - This pattern is used to create concrete class instances without specifying the exact class type. The Abstract Factory Pattern provides a way to encapsulate a group of individual factories that have a common theme.
* Flyweight - A pattern used to maximize the sharing of objects resulting in reduced memory consumption.
* Singleton - This pattern insures that only a single instance of a given object can exist.
* Builder - This pattern separate the construction of a complex object from its representation so that the same construction process can create different representations..
Structural Patterns
* Adapter - Convert the interface of a class into another interface clients expect. Adapter lets the classes work together that couldn't otherwise because of incompatible interfaces
* Bridge - Decouples an abstraction from its implementation so that the two can vary independantly.
* Composite - Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly.
* Decorator - Allows an objects behavior to be altered at runtime.
* Facade - Used to provide a simpler interface into a more complicated portion of code.
* Proxy - Provides a Placeholder for another object to control access to it.
Behavioral Patterns
* Chain of Responsibility - The chain of responsibility pattern is a way of communicating between objects.
* Command - Encapsulates a request as an object, thereby letting you parameterize clients with different requests, queue or log requests, and support undoable operations.
* Iterator - Provides a way to sequentially access aggregate objects without exposing the structure of the aggregate.
* Mediator - The mediator pattern encapsulate the interaction between a set of objects.
* Memento - Allows you to save the state of an object externally from that object.
* Observer - Allows a single object to notify many dependent objects that its state has changed.
* State - Allows an object to change its behaviour when its internal state changes.
* Strategy - Allows multiple algorithms to be used interchangeably at runtime.
* Visitor - The visitor design pattern enables us to create new operations to be performed on an existing structure.
* Template Method - Defines the skeleton of an algorithm then lets subclasses implement the behaviour that can vary.
Antipatterns
Antipatterns are misapplied design patterns. Common Antipatterns include:
*
The Blob/God Object - When one class contains all of the methods, operations and logic of your application
*
Re-coupling - building an unnecessary dependency between objects
*
Poltergeists - object whose main purpose in life is to pass messages to another object
*
Sequential Coupling - a class that imposes a particular order on its method calls.
Other patterns
* Aggregator Provider Pattern
* Lazy loading
What Are Design Patterns and Do I Need Them?
Software professionals may be familiar with the term "Design Patterns," but many have no idea of where they come from and what they truly are. Consequently, some do not see the value and benefits design patterns bring to the software development process, especially in the areas of maintenance and code reuse. This article will bridge this gap by defining design patterns from a historical perspective. It will also summarize the salient features of a typical design pattern and arrive at a working definition so that you will know what they are and what to expect when you incorporate them into your designs. Finally, it will explicitly summarize the benefits design patterns bring to software development and why you should incorporate them into your work. Subsequent articles will present more detailed descriptions of some of the more common design patterns, and how they can be applied to software development on the .NET platform.
What Are Design Patterns and Where Do They Come From?
Design patterns are commonly defined as time-tested solutions to recurring design problems. The term refers to both the description of a solution that you can read, and an instance of that solution as used to solve a particular problem. (I like the analogy of comparing design patterns to a class and an object instance of the class. Each is a different way to represent a thing.) Design patterns have their roots in the work of Christopher Alexander, a civil engineer who wrote about his experience in solving design issues as they related to buildings and towns. It occurred to Alexander that certain design constructs, when used time and time again, lead to the desired effect. He documented and published the wisdom and experience he gained so that others could benefit. About 15 years ago, software professionals began to incorporate Alexander's principles into the creation of early design pattern documentation as a guide to novice developers. This early work led others to also write about design patterns and culminated in the publication of Design Patterns: Elements of Reusable Object-Oriented Software in 1995 by Eric Gamma, Richard Helm, Ralph Johnson, and John Vlissides. This book is considered to be the "coming out" of design patterns to the software community at large and has been influential in the evolution of design patterns since. Design Patterns described 23 patterns that were based on the experience of the authors at that time. These patterns were selected because they represented solutions to common problems in software development. Many more patterns have been documented and cataloged since the publishing of Design Patterns. However, these 23 are probably the best known and certainly the most popular.
Design patterns are represented as relationships between classes and objects with defined responsibilities that act in concert to carry out the solution. To illustrate a design pattern, consider the Adapter pattern, one of the original 23 patterns described in Design Patterns. Adapter provides a solution to the scenario in which a client and server need to interact with one another, but cannot because their interfaces are incompatible. To implement an Adapter, you create a custom class that honors the interface provided by the server and defines the server operations in terms the client expects. This is a much better solution than altering the client to match the interface of the server.
* Post a comment
* Email Article
* Print Article
* Share Articles
o Digg
o del.icio.us
o Slashdot
o DZone
o Reddit
o StumbleUpon
o Facebook
o FriendFeed
o Furl
o Newsvine
o Google
o LinkedIn
o MySpace
o Technorati
o Twitter
o Windows Live
o YahooBuzz
The design pattern community is growing both in membership and coverage. The pattern literature describes new patterns that solve emerging issues related to technical advancements. As a software professional, you are the beneficiary of this body of knowledge. To use these patterns, you will need to learn them and become familiar with them so you will know which pattern to pull from your toolbox when a design issue arises. Many patterns have been documented over the years. They have been classified in different ways by different authors. Take the time to learn different ways to classify design patterns because you will gain greater insight into them. As you learn more and more patterns, it would be a good idea to develop your own classification system; one reflecting the way you utilize them.
Structure of a Design Pattern
Design pattern documentation is highly structured. The patterns are documented from a template that identifies the information needed to understand the software problem and the solution in terms of the relationships between the classes and objects necessary to implement the solution. There is no uniform agreement within the design pattern community on how to describe a pattern template. Different authors prefer different styles for their pattern templates. Some authors prefer to be more expressive and less structured, while others prefer their pattern templates to be more precise and high grain in structure. We will use the template first described by the authors of Design Patterns to illustrate a template.
Term Description
Pattern Name Describes the essence of the pattern in a short, but expressive, name
Intent Describes what the pattern does
Also Known As List any synonyms for the pattern
Motivation Provides an example of a problem and how the pattern solves that problem
Applicability Lists the situations where the pattern is applicable
Structure Set of diagrams of the classes and objects that depict the pattern
Participants Describes the classes and objects that participate in the design pattern and their responsibilities
Collaborations Describes how the participants collaborate to carry out their responsibilities
Consequences Describes the forces that exist with the pattern and the benefits, trade-offs, and the variable that is isolated by the pattern
This template captures the essential information required to understand the essence of the problem and the structure of the solution. Many pattern templates have less structure than this, but basically cover the same content.
Benefits of Design Patterns
Design patterns have two major benefits. First, they provide you with a way to solve issues related to software development using a proven solution. The solution facilitates the development of highly cohesive modules with minimal coupling. They isolate the variability that may exist in the system requirements, making the overall system easier to understand and maintain. Second, design patterns make communication between designers more efficient. Software professionals can immediately picture the high-level design in their heads when they refer the name of the pattern used to solve a particular issue when discussing system design.
What Are Design Patterns and Where Do They Come From?
Design patterns are commonly defined as time-tested solutions to recurring design problems. The term refers to both the description of a solution that you can read, and an instance of that solution as used to solve a particular problem. (I like the analogy of comparing design patterns to a class and an object instance of the class. Each is a different way to represent a thing.) Design patterns have their roots in the work of Christopher Alexander, a civil engineer who wrote about his experience in solving design issues as they related to buildings and towns. It occurred to Alexander that certain design constructs, when used time and time again, lead to the desired effect. He documented and published the wisdom and experience he gained so that others could benefit. About 15 years ago, software professionals began to incorporate Alexander's principles into the creation of early design pattern documentation as a guide to novice developers. This early work led others to also write about design patterns and culminated in the publication of Design Patterns: Elements of Reusable Object-Oriented Software in 1995 by Eric Gamma, Richard Helm, Ralph Johnson, and John Vlissides. This book is considered to be the "coming out" of design patterns to the software community at large and has been influential in the evolution of design patterns since. Design Patterns described 23 patterns that were based on the experience of the authors at that time. These patterns were selected because they represented solutions to common problems in software development. Many more patterns have been documented and cataloged since the publishing of Design Patterns. However, these 23 are probably the best known and certainly the most popular.
Design patterns are represented as relationships between classes and objects with defined responsibilities that act in concert to carry out the solution. To illustrate a design pattern, consider the Adapter pattern, one of the original 23 patterns described in Design Patterns. Adapter provides a solution to the scenario in which a client and server need to interact with one another, but cannot because their interfaces are incompatible. To implement an Adapter, you create a custom class that honors the interface provided by the server and defines the server operations in terms the client expects. This is a much better solution than altering the client to match the interface of the server.
* Post a comment
* Email Article
* Print Article
* Share Articles
o Digg
o del.icio.us
o Slashdot
o DZone
o Reddit
o StumbleUpon
o Facebook
o FriendFeed
o Furl
o Newsvine
o Google
o LinkedIn
o MySpace
o Technorati
o Twitter
o Windows Live
o YahooBuzz
The design pattern community is growing both in membership and coverage. The pattern literature describes new patterns that solve emerging issues related to technical advancements. As a software professional, you are the beneficiary of this body of knowledge. To use these patterns, you will need to learn them and become familiar with them so you will know which pattern to pull from your toolbox when a design issue arises. Many patterns have been documented over the years. They have been classified in different ways by different authors. Take the time to learn different ways to classify design patterns because you will gain greater insight into them. As you learn more and more patterns, it would be a good idea to develop your own classification system; one reflecting the way you utilize them.
Structure of a Design Pattern
Design pattern documentation is highly structured. The patterns are documented from a template that identifies the information needed to understand the software problem and the solution in terms of the relationships between the classes and objects necessary to implement the solution. There is no uniform agreement within the design pattern community on how to describe a pattern template. Different authors prefer different styles for their pattern templates. Some authors prefer to be more expressive and less structured, while others prefer their pattern templates to be more precise and high grain in structure. We will use the template first described by the authors of Design Patterns to illustrate a template.
Term Description
Pattern Name Describes the essence of the pattern in a short, but expressive, name
Intent Describes what the pattern does
Also Known As List any synonyms for the pattern
Motivation Provides an example of a problem and how the pattern solves that problem
Applicability Lists the situations where the pattern is applicable
Structure Set of diagrams of the classes and objects that depict the pattern
Participants Describes the classes and objects that participate in the design pattern and their responsibilities
Collaborations Describes how the participants collaborate to carry out their responsibilities
Consequences Describes the forces that exist with the pattern and the benefits, trade-offs, and the variable that is isolated by the pattern
This template captures the essential information required to understand the essence of the problem and the structure of the solution. Many pattern templates have less structure than this, but basically cover the same content.
Benefits of Design Patterns
Design patterns have two major benefits. First, they provide you with a way to solve issues related to software development using a proven solution. The solution facilitates the development of highly cohesive modules with minimal coupling. They isolate the variability that may exist in the system requirements, making the overall system easier to understand and maintain. Second, design patterns make communication between designers more efficient. Software professionals can immediately picture the high-level design in their heads when they refer the name of the pattern used to solve a particular issue when discussing system design.
Design Patterns
Design patterns are recurring solutions to software design problems you find again and again in real-world application development. Patterns are about design and interaction of objects, as well as providing a communication platform concerning elegant, reusable solutions to commonly encountered programming challenges.
The Gang of Four (GoF) patterns are generally considered the foundation for all other patterns. They are categorized in three groups: Creational, Structural, and Behavioral. Here you will find information on these important patterns.
To give you a head start, the C# source code is provided in 2 forms: 'structural' and 'real-world'. Structural code uses type names as defined in the pattern definition and UML diagrams. Real-world code provides real-world programming situations where you may use these patterns.
A third form, '.NET optimized' demonstrates design patterns that exploit built-in .NET 3.5 features, such as, generics, attributes, delegates, object and collection initializers, automatic properties, and reflection. These and much more are available in our Design Pattern Framework 3.5TM. See our Singleton page for a .NET 3.5 Optimized code sample.
Creational Patterns
Abstract Factory Creates an instance of several families of classes
Builder Separates object construction from its representation
Factory Method Creates an instance of several derived classes
Prototype A fully initialized instance to be copied or cloned
Singleton A class of which only a single instance can exist
Structural Patterns
Adapter Match interfaces of different classes
Bridge Separates an object’s interface from its implementation
Composite A tree structure of simple and composite objects
Decorator Add responsibilities to objects dynamically
Facade A single class that represents an entire subsystem
Flyweight A fine-grained instance used for efficient sharing
Proxy An object representing another object
Behavioral Patterns
Chain of Resp. A way of passing a request between a chain of objects
Command Encapsulate a command request as an object
Interpreter A way to include language elements in a program
Iterator Sequentially access the elements of a collection
Mediator Defines simplified communication between classes
Memento Capture and restore an object's internal state
Observer A way of notifying change to a number of classes
State Alter an object's behavior when its state changes
Strategy Encapsulates an algorithm inside a class
Template Method Defer the exact steps of an algorithm to a subclass
Visitor Defines a new operation to a class without change
The Gang of Four (GoF) patterns are generally considered the foundation for all other patterns. They are categorized in three groups: Creational, Structural, and Behavioral. Here you will find information on these important patterns.
To give you a head start, the C# source code is provided in 2 forms: 'structural' and 'real-world'. Structural code uses type names as defined in the pattern definition and UML diagrams. Real-world code provides real-world programming situations where you may use these patterns.
A third form, '.NET optimized' demonstrates design patterns that exploit built-in .NET 3.5 features, such as, generics, attributes, delegates, object and collection initializers, automatic properties, and reflection. These and much more are available in our Design Pattern Framework 3.5TM. See our Singleton page for a .NET 3.5 Optimized code sample.
Creational Patterns
Abstract Factory Creates an instance of several families of classes
Builder Separates object construction from its representation
Factory Method Creates an instance of several derived classes
Prototype A fully initialized instance to be copied or cloned
Singleton A class of which only a single instance can exist
Structural Patterns
Adapter Match interfaces of different classes
Bridge Separates an object’s interface from its implementation
Composite A tree structure of simple and composite objects
Decorator Add responsibilities to objects dynamically
Facade A single class that represents an entire subsystem
Flyweight A fine-grained instance used for efficient sharing
Proxy An object representing another object
Behavioral Patterns
Chain of Resp. A way of passing a request between a chain of objects
Command Encapsulate a command request as an object
Interpreter A way to include language elements in a program
Iterator Sequentially access the elements of a collection
Mediator Defines simplified communication between classes
Memento Capture and restore an object's internal state
Observer A way of notifying change to a number of classes
State Alter an object's behavior when its state changes
Strategy Encapsulates an algorithm inside a class
Template Method Defer the exact steps of an algorithm to a subclass
Visitor Defines a new operation to a class without change
C# Design Patterns
gang-of-four design patterns and beyond
available dates
course highlights
prerequisites
what you will take home
what you will learn
Design patterns are recurring solutions to software design problems you find again and again in real-world application development. Design patterns are about design and interaction of objects, as well as about providing a communication platform concerning elegant, reusable solutions to commonly encountered programming challenges.
C# Design Patterns is a practical, hands-on course where you'll learn how to write C# applications using the most common design patterns. The course is structured as a series of modules each focusing on a particular design pattern. Each module also presents the UML (Unified Modeling Language) diagram illustrating how the classes interact. In subsequent labs you will discover how to implement working example programs that use that pattern under consideration.
You will walk away from this class with the knowledge and the skills necessary to implement and benefit from design patterns in your next project.
available dates
Clicking on a date will bring you to the registration page. w = waiting list
feb mar apr may jun jul
Austin -- -- -- -- -- --
Dallas -- -- -- -- -- --
Atlanta -- -- -- -- -- --
Amsterdam -- -- -- -- -- --
If no public courses are currently scheduled then please remember that on-site courses can be arranged. Click here to contact us for details.
course highlights
* Design Pattern Universe
* UML Diagram Overview
* Design Pattern Categories
* Application Frameworks
* Factory Pattern
* Abstract Factory Pattern
* Singleton Pattern
* Builder Pattern
* Prototype Pattern
* Adapter Pattern
* Bridge Pattern
* Composite Pattern
* Decorator Pattern
* Facade Pattern
* Flyweight Pattern
* Proxy Pattern
* Chain of Responsibility Pattern
* Command Pattern
* Interpreter Pattern
* Iterator Pattern
* Mediator Pattern
* Memento Pattern
* Observer Pattern
* State Pattern
* Strategy Pattern
* Template Pattern
* Visitor Pattern
* Design Patterns in .Net Libraries
* Case Studies
* Future of Design Patterns
prerequisites
This course is designed for programmers familiar with C# and object-oriented programming.
available dates
course highlights
prerequisites
what you will take home
what you will learn
Design patterns are recurring solutions to software design problems you find again and again in real-world application development. Design patterns are about design and interaction of objects, as well as about providing a communication platform concerning elegant, reusable solutions to commonly encountered programming challenges.
C# Design Patterns is a practical, hands-on course where you'll learn how to write C# applications using the most common design patterns. The course is structured as a series of modules each focusing on a particular design pattern. Each module also presents the UML (Unified Modeling Language) diagram illustrating how the classes interact. In subsequent labs you will discover how to implement working example programs that use that pattern under consideration.
You will walk away from this class with the knowledge and the skills necessary to implement and benefit from design patterns in your next project.
available dates
Clicking on a date will bring you to the registration page. w = waiting list
feb mar apr may jun jul
Austin -- -- -- -- -- --
Dallas -- -- -- -- -- --
Atlanta -- -- -- -- -- --
Amsterdam -- -- -- -- -- --
If no public courses are currently scheduled then please remember that on-site courses can be arranged. Click here to contact us for details.
course highlights
* Design Pattern Universe
* UML Diagram Overview
* Design Pattern Categories
* Application Frameworks
* Factory Pattern
* Abstract Factory Pattern
* Singleton Pattern
* Builder Pattern
* Prototype Pattern
* Adapter Pattern
* Bridge Pattern
* Composite Pattern
* Decorator Pattern
* Facade Pattern
* Flyweight Pattern
* Proxy Pattern
* Chain of Responsibility Pattern
* Command Pattern
* Interpreter Pattern
* Iterator Pattern
* Mediator Pattern
* Memento Pattern
* Observer Pattern
* State Pattern
* Strategy Pattern
* Template Pattern
* Visitor Pattern
* Design Patterns in .Net Libraries
* Case Studies
* Future of Design Patterns
prerequisites
This course is designed for programmers familiar with C# and object-oriented programming.
Wednesday, February 10, 2010
Tuesday, February 9, 2010
Sample trend line study
Sample trend line study
10-year Exxon chart
By looking at the 10-year chart of this company we get an idea of it's past performance and overall trend. We can see that generally this stock has been in an uptrend for most of it's 10 year history. There is a short downtrend in the last third of the chart followed by a strong uptrend.
In this case, a buy and hold trader would have done quite well. Trading with the trend would have increased the profit significantly. For the first six years of the chart, we see a strong uptrend, then a two-year downtrend followed by a two-year uptrend. By trading with the trend we would have only been in the market for eight of the six years and reduced our exposure as well as increased our profitability.
When looking at our trading strategy, this long-term view should apply to all types of traders. Ultimately, a trader who is buying should be interested in purchasing stocks that are trending up. Even though the most recent movement indicates a strong uptrend, several market factors have influenced this price movement, specifically, the cost of oil. It would be expected that when the price of oil drops so will the revenue of this company. As long as this trend stays on track this chart still has potential for profit. If the trend breaks then we will exit our position.
5-Year Exxon chart
The 5-year chart gives us some insight into the secondary trend correction that was seen in the earlier chart. At the top of the last trend we can see a clear double top and 1 1/2 year down trend. The stock forms a period of consolidation and then breaks out into an uptrend. In the consolidation period a series of higher lows and lower highs can be seen and is similar to a triangle formation. A triangle formation indicates that when the two trends cross a breakout will occur (in either direction).
2-Year Exxon chart
For the last two years the stock has maintained a steady uptrend. In this time frame we can see some small secondary trend corrections, but nothing significant. The price keeps forming new highs.
6 mo Exxon chart
Looking at the short term, we can see that the stock is uptrending. It has recently had a short period of consolidation, followed by another upward breakout. Trading in this time frame would be considered the domain of the swing trader.
As stated in Dow Theory, there are secondary trends contained within the primary trend. In this chart we can see that the long-term trend (major trend) is up, there is a correction/secondary trend (the short term down movement), and then the trend is continued. We can also see a period of consolidation when a new 5-year high is formed. This period of consolidation could be caused by profit taking and uncertainty of price value. The price then moves sideways before forming a new high indicating that the major trend is still intact. Until the new high is formed it would be wise to assume that this could be a trend reversal. As seen in the 5-year chart and the first high, a double top is formed before the major trend is broken downward. According to the 2-year chart, this stock is in a clear uptrend and at this time period (or greater) small corrections are easier to ignore.
Note:
• Always trade with the trend.
• It is always worthwhile to look at the long-term trend so as to not accidentally enter in a small secondary trend/small correction/consolidation. The goal is to trade with the trend (preferably the major trend)
• Stick to your rules.
10-year Exxon chart
By looking at the 10-year chart of this company we get an idea of it's past performance and overall trend. We can see that generally this stock has been in an uptrend for most of it's 10 year history. There is a short downtrend in the last third of the chart followed by a strong uptrend.
In this case, a buy and hold trader would have done quite well. Trading with the trend would have increased the profit significantly. For the first six years of the chart, we see a strong uptrend, then a two-year downtrend followed by a two-year uptrend. By trading with the trend we would have only been in the market for eight of the six years and reduced our exposure as well as increased our profitability.
When looking at our trading strategy, this long-term view should apply to all types of traders. Ultimately, a trader who is buying should be interested in purchasing stocks that are trending up. Even though the most recent movement indicates a strong uptrend, several market factors have influenced this price movement, specifically, the cost of oil. It would be expected that when the price of oil drops so will the revenue of this company. As long as this trend stays on track this chart still has potential for profit. If the trend breaks then we will exit our position.
5-Year Exxon chart
The 5-year chart gives us some insight into the secondary trend correction that was seen in the earlier chart. At the top of the last trend we can see a clear double top and 1 1/2 year down trend. The stock forms a period of consolidation and then breaks out into an uptrend. In the consolidation period a series of higher lows and lower highs can be seen and is similar to a triangle formation. A triangle formation indicates that when the two trends cross a breakout will occur (in either direction).
2-Year Exxon chart
For the last two years the stock has maintained a steady uptrend. In this time frame we can see some small secondary trend corrections, but nothing significant. The price keeps forming new highs.
6 mo Exxon chart
Looking at the short term, we can see that the stock is uptrending. It has recently had a short period of consolidation, followed by another upward breakout. Trading in this time frame would be considered the domain of the swing trader.
As stated in Dow Theory, there are secondary trends contained within the primary trend. In this chart we can see that the long-term trend (major trend) is up, there is a correction/secondary trend (the short term down movement), and then the trend is continued. We can also see a period of consolidation when a new 5-year high is formed. This period of consolidation could be caused by profit taking and uncertainty of price value. The price then moves sideways before forming a new high indicating that the major trend is still intact. Until the new high is formed it would be wise to assume that this could be a trend reversal. As seen in the 5-year chart and the first high, a double top is formed before the major trend is broken downward. According to the 2-year chart, this stock is in a clear uptrend and at this time period (or greater) small corrections are easier to ignore.
Note:
• Always trade with the trend.
• It is always worthwhile to look at the long-term trend so as to not accidentally enter in a small secondary trend/small correction/consolidation. The goal is to trade with the trend (preferably the major trend)
• Stick to your rules.
Sample trend line study
Sample trend line study
10-year Exxon chart
By looking at the 10-year chart of this company we get an idea of it's past performance and overall trend. We can see that generally this stock has been in an uptrend for most of it's 10 year history. There is a short downtrend in the last third of the chart followed by a strong uptrend.
In this case, a buy and hold trader would have done quite well. Trading with the trend would have increased the profit significantly. For the first six years of the chart, we see a strong uptrend, then a two-year downtrend followed by a two-year uptrend. By trading with the trend we would have only been in the market for eight of the six years and reduced our exposure as well as increased our profitability.
When looking at our trading strategy, this long-term view should apply to all types of traders. Ultimately, a trader who is buying should be interested in purchasing stocks that are trending up. Even though the most recent movement indicates a strong uptrend, several market factors have influenced this price movement, specifically, the cost of oil. It would be expected that when the price of oil drops so will the revenue of this company. As long as this trend stays on track this chart still has potential for profit. If the trend breaks then we will exit our position.
5-Year Exxon chart
The 5-year chart gives us some insight into the secondary trend correction that was seen in the earlier chart. At the top of the last trend we can see a clear double top and 1 1/2 year down trend. The stock forms a period of consolidation and then breaks out into an uptrend. In the consolidation period a series of higher lows and lower highs can be seen and is similar to a triangle formation. A triangle formation indicates that when the two trends cross a breakout will occur (in either direction).
2-Year Exxon chart
For the last two years the stock has maintained a steady uptrend. In this time frame we can see some small secondary trend corrections, but nothing significant. The price keeps forming new highs.
6 mo Exxon chart
Looking at the short term, we can see that the stock is uptrending. It has recently had a short period of consolidation, followed by another upward breakout. Trading in this time frame would be considered the domain of the swing trader.
As stated in Dow Theory, there are secondary trends contained within the primary trend. In this chart we can see that the long-term trend (major trend) is up, there is a correction/secondary trend (the short term down movement), and then the trend is continued. We can also see a period of consolidation when a new 5-year high is formed. This period of consolidation could be caused by profit taking and uncertainty of price value. The price then moves sideways before forming a new high indicating that the major trend is still intact. Until the new high is formed it would be wise to assume that this could be a trend reversal. As seen in the 5-year chart and the first high, a double top is formed before the major trend is broken downward. According to the 2-year chart, this stock is in a clear uptrend and at this time period (or greater) small corrections are easier to ignore.
Note:
• Always trade with the trend.
• It is always worthwhile to look at the long-term trend so as to not accidentally enter in a small secondary trend/small correction/consolidation. The goal is to trade with the trend (preferably the major trend)
• Stick to your rules.
10-year Exxon chart
By looking at the 10-year chart of this company we get an idea of it's past performance and overall trend. We can see that generally this stock has been in an uptrend for most of it's 10 year history. There is a short downtrend in the last third of the chart followed by a strong uptrend.
In this case, a buy and hold trader would have done quite well. Trading with the trend would have increased the profit significantly. For the first six years of the chart, we see a strong uptrend, then a two-year downtrend followed by a two-year uptrend. By trading with the trend we would have only been in the market for eight of the six years and reduced our exposure as well as increased our profitability.
When looking at our trading strategy, this long-term view should apply to all types of traders. Ultimately, a trader who is buying should be interested in purchasing stocks that are trending up. Even though the most recent movement indicates a strong uptrend, several market factors have influenced this price movement, specifically, the cost of oil. It would be expected that when the price of oil drops so will the revenue of this company. As long as this trend stays on track this chart still has potential for profit. If the trend breaks then we will exit our position.
5-Year Exxon chart
The 5-year chart gives us some insight into the secondary trend correction that was seen in the earlier chart. At the top of the last trend we can see a clear double top and 1 1/2 year down trend. The stock forms a period of consolidation and then breaks out into an uptrend. In the consolidation period a series of higher lows and lower highs can be seen and is similar to a triangle formation. A triangle formation indicates that when the two trends cross a breakout will occur (in either direction).
2-Year Exxon chart
For the last two years the stock has maintained a steady uptrend. In this time frame we can see some small secondary trend corrections, but nothing significant. The price keeps forming new highs.
6 mo Exxon chart
Looking at the short term, we can see that the stock is uptrending. It has recently had a short period of consolidation, followed by another upward breakout. Trading in this time frame would be considered the domain of the swing trader.
As stated in Dow Theory, there are secondary trends contained within the primary trend. In this chart we can see that the long-term trend (major trend) is up, there is a correction/secondary trend (the short term down movement), and then the trend is continued. We can also see a period of consolidation when a new 5-year high is formed. This period of consolidation could be caused by profit taking and uncertainty of price value. The price then moves sideways before forming a new high indicating that the major trend is still intact. Until the new high is formed it would be wise to assume that this could be a trend reversal. As seen in the 5-year chart and the first high, a double top is formed before the major trend is broken downward. According to the 2-year chart, this stock is in a clear uptrend and at this time period (or greater) small corrections are easier to ignore.
Note:
• Always trade with the trend.
• It is always worthwhile to look at the long-term trend so as to not accidentally enter in a small secondary trend/small correction/consolidation. The goal is to trade with the trend (preferably the major trend)
• Stick to your rules.
Introduction to Dow Theory
Introduction to Dow Theory
When Charles Dow published his observations at the end of the 19th century in the Wall Street Journal he, unfortunately, did not name his observations. His theory was named "Dow Theory" by later chartists and it is Dow Theory in which modern technical analysis has its roots.
Dow Theory is based on the philosophy that market prices reflect every significant factor that affects supply and demand - volume of trade, fluctuations in exchange rates, commodity prices, bank rates, and so on. In other words, the daily closing price reflects the psychology of all players involved in a particular marketplace - or the combined judgment of all market participants.
The goal of the theory is to determine changes in the major trends or movements of the market. Markets tend to move in the direction of a trend once it becomes established, until it demonstrates a reversal. Dow theory is interested in the direction of a trend and doesn't offer any forecasting ability for determining the ultimate duration of a trend.
Dow's original "trend following' system highlighted the following points
* Classification of a trend
* Principles of confirmation or divergence
* Use of volume to confirm trends
* Use of percentage retracement
* Recognition of major bull and bear markets
* Signaling the large central section of important market moves
* Dow theory has been successful in identifying 68% the major trends over the years
It is these observations where the understanding of trend becomes one of the most important concepts in technical analysis (or the most important concept for the trader is to be on the right side of the trend).
Trends
There are three directions a trend can have:
1. Uptrend: successively higher peaks (highs) and higher troughs (lows)
2. Downtrend: successively lower peaks and troughs
3. Sideways Channel: peaks and troughs don't successively rise or fall
Each market trend has three parts compared to tides, waves and ripples.
1. The primary (major) trend or tide is a long term trend lasting from a year to several years.
2. The secondary trend (or mid-term trend) or wave lasts three weeks to three months and represents corrections of one third to two thirds of the previous movement - most often fifty percent of the movement.
3. The minor trends (short-term trends) or insignificant ripples last less than three weeks and represent fluctuations in the secondary trend.
Shortcomings of the Dow Theory:
The major criticism of the Dow Theory is its slowness: It misses about 25% of a move before giving a signal, primarily because it is a trend following system designed to identify existing trends.
When Charles Dow published his observations at the end of the 19th century in the Wall Street Journal he, unfortunately, did not name his observations. His theory was named "Dow Theory" by later chartists and it is Dow Theory in which modern technical analysis has its roots.
Dow Theory is based on the philosophy that market prices reflect every significant factor that affects supply and demand - volume of trade, fluctuations in exchange rates, commodity prices, bank rates, and so on. In other words, the daily closing price reflects the psychology of all players involved in a particular marketplace - or the combined judgment of all market participants.
The goal of the theory is to determine changes in the major trends or movements of the market. Markets tend to move in the direction of a trend once it becomes established, until it demonstrates a reversal. Dow theory is interested in the direction of a trend and doesn't offer any forecasting ability for determining the ultimate duration of a trend.
Dow's original "trend following' system highlighted the following points
* Classification of a trend
* Principles of confirmation or divergence
* Use of volume to confirm trends
* Use of percentage retracement
* Recognition of major bull and bear markets
* Signaling the large central section of important market moves
* Dow theory has been successful in identifying 68% the major trends over the years
It is these observations where the understanding of trend becomes one of the most important concepts in technical analysis (or the most important concept for the trader is to be on the right side of the trend).
Trends
There are three directions a trend can have:
1. Uptrend: successively higher peaks (highs) and higher troughs (lows)
2. Downtrend: successively lower peaks and troughs
3. Sideways Channel: peaks and troughs don't successively rise or fall
Each market trend has three parts compared to tides, waves and ripples.
1. The primary (major) trend or tide is a long term trend lasting from a year to several years.
2. The secondary trend (or mid-term trend) or wave lasts three weeks to three months and represents corrections of one third to two thirds of the previous movement - most often fifty percent of the movement.
3. The minor trends (short-term trends) or insignificant ripples last less than three weeks and represent fluctuations in the secondary trend.
Shortcomings of the Dow Theory:
The major criticism of the Dow Theory is its slowness: It misses about 25% of a move before giving a signal, primarily because it is a trend following system designed to identify existing trends.
XSLT Programing
XML Schema - Research by Ashok Maurya
Introduction:
1. XML Schema is an XML-based alternative to DTD.
2. An XML schema describes the structure of an XML document.
3. The XML Schema language is also referred to as XML Schema Definition (XSD)
4. The purpose of an XML Schema is to define the legal building blocks of an XML document, just like a DTD.
5. XML Schemas are much more powerful than DTDs.
An XML Schema:
• defines elements that can appear in a document
• defines attributes that can appear in a document
• defines which elements are child elements
• defines the order of child elements
• defines the number of child elements
• defines whether an element is empty or can include text
• defines data types for elements and attributes
• defines default and fixed values for elements and attributes
XML Schemas are the Successors of DTDs:
We think that very soon XML Schemas will be used in most Web applications as a replacement for DTDs. Here are some reasons:
• XML Schemas are extensible to future additions
• XML Schemas are richer and more powerful than DTDs
• XML Schemas are written in XML
• XML Schemas support data types
• XML Schemas support namespaces
XML Schemas Support Data Types
One of the greatest strength of XML Schemas is the support for data types.
With support for data types:
• It is easier to describe allowable document content
• It is easier to validate the correctness of data
• It is easier to work with data from a database
• It is easier to define data facets (restrictions on data)
• It is easier to define data patterns (data formats)
• It is easier to convert data between different data types
ML Schemas use XML Syntax
Another great strength about XML Schemas is that they are written in XML.
Some benefits of that XML Schemas are written in XML:
• You don't have to learn a new language
• You can use your XML editor to edit your Schema files
• You can use your XML parser to parse your Schema files
• You can manipulate your Schema with the XML DOM
• You can transform your Schema with XSLT
XML Schemas Secure Data Communication
When sending data from a sender to a receiver, it is essential that both parts have the same "expectations" about the content.
With XML Schemas, the sender can describe the data in a way that the receiver will understand.
A date like: "03-11-2004" will, in some countries, be interpreted as 3.November and in other countries as 11.March.
However, an XML element with a data type like this:
2004-03-11
Ensures a mutual understanding of the content, because the XML data type "date" requires the format "YYYY-MM-DD".
XML Schemas are Extensible
XML Schemas are extensible, because they are written in XML.
With an extensible Schema definition you can:
• Reuse your Schema in other Schemas
• Create your own data types derived from the standard types
• Reference multiple schemas in the same document
Well-Formed is not Enough
A well-formed XML document is a document that conforms to the XML syntax rules, like:
• it must begin with the XML declaration
• it must have one unique root element
• start-tags must have matching end-tags
• elements are case sensitive
• all elements must be closed
• all elements must be properly nested
• all attribute values must be quoted
• entities must be used for special characters
Even if documents are well-formed they can still contain errors, and those errors can have serious consequences.
Think of the following situation: you order 5 gross of laser printers, instead of 5 laser printers. With XML Schemas, most of these errors can be caught by your validating software.
Introduction:
1. XML Schema is an XML-based alternative to DTD.
2. An XML schema describes the structure of an XML document.
3. The XML Schema language is also referred to as XML Schema Definition (XSD)
4. The purpose of an XML Schema is to define the legal building blocks of an XML document, just like a DTD.
5. XML Schemas are much more powerful than DTDs.
An XML Schema:
• defines elements that can appear in a document
• defines attributes that can appear in a document
• defines which elements are child elements
• defines the order of child elements
• defines the number of child elements
• defines whether an element is empty or can include text
• defines data types for elements and attributes
• defines default and fixed values for elements and attributes
XML Schemas are the Successors of DTDs:
We think that very soon XML Schemas will be used in most Web applications as a replacement for DTDs. Here are some reasons:
• XML Schemas are extensible to future additions
• XML Schemas are richer and more powerful than DTDs
• XML Schemas are written in XML
• XML Schemas support data types
• XML Schemas support namespaces
XML Schemas Support Data Types
One of the greatest strength of XML Schemas is the support for data types.
With support for data types:
• It is easier to describe allowable document content
• It is easier to validate the correctness of data
• It is easier to work with data from a database
• It is easier to define data facets (restrictions on data)
• It is easier to define data patterns (data formats)
• It is easier to convert data between different data types
ML Schemas use XML Syntax
Another great strength about XML Schemas is that they are written in XML.
Some benefits of that XML Schemas are written in XML:
• You don't have to learn a new language
• You can use your XML editor to edit your Schema files
• You can use your XML parser to parse your Schema files
• You can manipulate your Schema with the XML DOM
• You can transform your Schema with XSLT
XML Schemas Secure Data Communication
When sending data from a sender to a receiver, it is essential that both parts have the same "expectations" about the content.
With XML Schemas, the sender can describe the data in a way that the receiver will understand.
A date like: "03-11-2004" will, in some countries, be interpreted as 3.November and in other countries as 11.March.
However, an XML element with a data type like this:
Ensures a mutual understanding of the content, because the XML data type "date" requires the format "YYYY-MM-DD".
XML Schemas are Extensible
XML Schemas are extensible, because they are written in XML.
With an extensible Schema definition you can:
• Reuse your Schema in other Schemas
• Create your own data types derived from the standard types
• Reference multiple schemas in the same document
Well-Formed is not Enough
A well-formed XML document is a document that conforms to the XML syntax rules, like:
• it must begin with the XML declaration
• it must have one unique root element
• start-tags must have matching end-tags
• elements are case sensitive
• all elements must be closed
• all elements must be properly nested
• all attribute values must be quoted
• entities must be used for special characters
Even if documents are well-formed they can still contain errors, and those errors can have serious consequences.
Think of the following situation: you order 5 gross of laser printers, instead of 5 laser printers. With XML Schemas, most of these errors can be caught by your validating software.
Subscribe to:
Posts (Atom)