Showing posts with label Design Patterns. Show all posts
Showing posts with label Design Patterns. Show all posts

Thursday 23 September 2010

Tip of the day – A good use of auto implemented properties.

A very practical use of auto implemented properties could be to create a immutable lightweight class. An auto implemented property is a ‘property’ in C# without fields. The C# JIT Compiler generates the IL with a field for the auto implemented properties. (hence the name). The IL also replaces the Get and Set accessor stubs in the Properties to return and set the automatically generated field.

Take a look at the below code ( class ‘Books’). There are Title, Author and PublshedYear auto implemented properties. Notice the set is private, This makes the ‘Books’ class immutable.

autoprop

The tip is to use this kind of construct to replace structs when ever a reference type is required. Also notice that the constructor is made ‘private’. Simply because i find the factory method ‘CreateBook’  semantically appealing to call the private constructor rather than having to use the auto implemented property directly in the constructor for initializing the Books object.

Take a look at the IL for Books.,  Notice the ‘k__BackingField’ feild generated by the C# Compiler.

image

//////////////get_Author: string() IL////////////////////

.method public hidebysig specialname instance string
        get_Author() cil managed
{
  .custom instance void [mscorlib]System.Runtime.CompilerServices.CompilerGeneratedAttribute::.ctor() = ( 01 00 00 00 )
  // Code size       11 (0xb)
  .maxstack  1
  .locals init (string V_0)
  IL_0000:  ldarg.0
  IL_0001:  ldfld      string ConsoleApplication1.Books::'<Author>k__BackingField'
  IL_0006:  stloc.0
  IL_0007:  br.s       IL_0009
  IL_0009:  ldloc.0
  IL_000a:  ret
} // end of method Books::get_Author

 

//////////////////set_Author:void(string) IL////////////////

.method private hidebysig specialname instance void
        set_Author(string 'value') cil managed
{
  .custom instance void [mscorlib]System.Runtime.CompilerServices.CompilerGeneratedAttribute::.ctor() = ( 01 00 00 00 )
  // Code size       8 (0x8)
  .maxstack  8
  IL_0000:  ldarg.0
  IL_0001:  ldarg.1
  IL_0002:  stfld      string ConsoleApplication1.Books::'<Author>k__BackingField'
  IL_0007:  ret
} // end of method Books::set_Author

Now, a demo of using the above immutable lightweight class

democode

Happy patterns discovery..

I’ve used the MSDN example here to illustrate.

Sunday 19 September 2010

Design Patterns – Types

Design patterns are proven practises and principles for building enterprise software. They generalize solutions to common problems.  By adapting design patterns in our software architecture, we leverage the proven solutions and concepts. This makes the code easier to maintain / understand / relate to.

Design patterns are broadly classified into the following categories.

1] Structural Patterns

- Focus on building flexibility,maintainability and security

2] Creational Patterns

- Focus on increasing flexibility,i.e what , who, how and when of object creation.

3] Behavioural Patterns

- Focus on algorithms and communication between them.

I’ll start with the Structural Patterns in my next post.

Saturday 18 September 2010

My love for patterns and discovery of them..

It all started in my undergraduate days back in 2003 when i used to work a lot on VB & C++. I had no idea that patterns existed then!. One fine day a friend of mine suggested using a ‘Singleton’. Since than I've had the hunger for discovering more and more of ‘patterns’ and their usage.

After i moved to the managed world (.Net) it started appealing more and more and today, i cannot think of an application without it. I’ve moved on to application architecture and business processes all the way realizing how vital the role of patterns in real world development (civil engineering  to software engineering). Apart from all the other stuff that still interests me., I’ve decided to take a rather focussed approach to patterns, software design and application architecture from now. I look forward to a sound discussion with you all on them.

Sunday 4 October 2009

Sunday 24 August 2008

Behold!, Strategy Pattern will take care of it..!

We developers often have the common problem of programming the implementation and NOT the interface when we hurriedly develop software. Now, there are instances where 'test first code later' approach also might fail. This might happen when we misjudge the design issues and jump straight into what we want to achieve, but failing to consider issues like scalability, asking questions as to how easy will it be to accommodate changes in the future etc. Now, I believe, this is where experience comes for a cost !

Hmm.. until the day comes when your code needs to prove it's worth when changes or features are requested. It might seem rather easy at first until you start breaking feature after feature just by trying to add a tiny little feature.

Problems!!, After all, How would the world run without them!

Now, consider the following class hierarchy. I've taken a really trivial example here. The idea is to focus on the pattern and not on the problem!, remember we're building software that is ready for change in other words easily maintainable. maintenance is cost!.

ClassHeirarchy_Original

The abstract class 'Graph' has an abstract 'DrawGraph()' method. It also has a protected member List<int>> data. This is intended to be used by the DrawGraph() method. The abstract class also has implementations for SetUpGraphics(), which sets up the graphics device with double buffering mechanism let's say and a SetData() method which initialises the member variable 'data'.

The subclasses (sub-types: according to the design principle - sub class it iff the subclass is a subtype) PieGraph, LineGraph and BarGraph have their own implementations for 'DrawGraph()'. Each of which has it's own algorithm to draw the graph.

------------------------------------------------------------------------------------------------

For instance, the PieGraph's DrawGraph() method will draw a 360 degrees pie chart and map every value of data to an angle.

For example

data[0] maps to a 60 degrees spread.

data[1] maps to a 45 degrees spread and so on..

------------------------------------------------------------------------------------------------

The LineGraph's DrawGraph() method will draw a line graph indicating points on the xy-plane for every value of 'List<int>data'.

------------------------------------------------------------------------------------------------

The BarGraph's DrawGraph() method will draw a bar graph (column) for every value in 'List <int> data'. Let's also assume that it has flexibility to show graphs as columns or rows.

------------------------------------------------------------------------------------------------

It's clear that the 'DrawGraph()' method varies across all three implementations and every implementation has it's own algorithm. Now, Time to ask yourself questions.. Assume this structure has met the requirements and is working as expected. That's where most of us would stop the design and go home singing 'sweet home alabama', only to come back to it a few months later when we cannot escape the inevitable, CHANGE !!, It would be a new feature request by the client or porting it to a different platform, you never know, it's the business which grows and impacts the software or brings about change. (another favourite topic of mine ). Now, let's say you need to put in 3 new features

1] A mechanism to draw XY Axis scale dynamically.

Here X and Y unit values depend on a provided data set. Let's say the data set used to plot the graph are the values of used homes in the UK. ( in thousands) data set = {115.8,113,183.5,142.7,144.2,85.9,170.1,129.3}. Now, Given the data set, the graph should generate 8 Units on the X-Axis and a proportionate scale on Y-Axis (0-200 would be fine in this case).

2] Calculate Range,Variance and Standard Deviation of the data set.

3] Users should be able to resize the graph dynamically - Automating Scaling.

Ok,let's start reworking our class structure to add these features.

Let's start with feature 1]. Auto generating Units for XY based on Data. By looking at the structure, It's very clear that by adding a method in Graph Class (Virtual Method), the classes LineGraph and BarGraph can override it and implement automatic generating of XY units. But what would happen to PieGraph ?. It will have to do nothing. In other words, override to give no implementation.

PieGraph.AutoGenerateXYUnits() { //no implementation }

Now, to overcome this **side effect ** , we can think of sub classing LineGraph and BarGraph further. i.e, it can be derived from a class called CordinateGraph. CoordinateGraph derives from Graph. AutoGenerating XY Units feature can then be implemented in the Co-ordinateGraph class as a virtual method. So that it can be overridden in the LineGraph and BarGraph Classes. Notice as we try to do such modifications, the behaviours become very tightly coupled to it's implementations and it will eventually become harder and harder to maintain such code simply because adding a feature to the base class Graph will break the system, introduce side effects as we saw above.

Ok,

How about 'interfacing' the AutoScaleXYUnit behaviour ?. This might sound interesting as only the required classes implement the behaviour.

ClassHeirarchy_Mod1

But, notice carefully, you will have to repeat implementations for all the classes which implements the IAutoGenXYUnits interface. Lets say in the future, if there were to arise a situation where 10 different classes need to implement this behaviour , then there will be 10 implementations, and you introduced another maintenance nightmare.. no code reuse. I'll come back to this.

Think of the possible implementations for feature 2] Calculating Range,Variance and Standard Deviation for the data set. It could be a very straight forward implementation. add it to the base class {as a feature} ?, Yes, it would do the job for all the 3 Subclasses and if the method is virtual, it would be even better. Let's agree that this is pretty straight forward virtual method implementation in the Class 'Graph'. (and it would do it's job )

And finally, possible implementations for 3] Automatic scaling of the graph at runtime. This behaviour varies across all there sub classes. If you were to think that adding a method to scale the graph in the Graph Class would be sufficient. What if PieChart needed no scaling at all ? , LineGraph and BarGraph needed vertical and horizontal scaling respectively ?, Side effects would occur, code would break..

A good solution to 1] and 3] would be to use the strategy pattern. Some general design principles that I've considered when re factoring this to use a strategy pattern. And most of them would work for behavioural patterns***

- The open closed principle: open to extension but closed for modification.

- Program the interface

- Use Composition over inheritance

- Cohesion

- Tight coupling vs Loose coupling

Caution: It might be argued that some of the design principles do not apply to every kind of a problem. For e.g. Huge Enterprise Applications with millions of users. See Enterprise Application Patterns. Here, the design would primarily focus on issues like Scalable architecture, Service oriented design, concurrency, minimizing round trips to the server etc. and it can be noticed that what seems a perfect solution for a stand alone app might be dreadful and disastrous one for Enterprise Apps.

Identifying what 'changes' and what 'remains'. A general trick is to encapsulate what changes and keep what stays. The Draw method clearly varies across all three implementations. So, Let's make a 'IDrawable' interface out of it. Similarly for scaling the graphs dynamically, we could think of an 'IScalable' interface. We go ahead and provide concrete implementations to them. The concrete implementations to the IDrawable interface would be

--o IDrawable { DrawBar, DrawLine , DrawPoint, DrawPie }, This also takes care of feature request 1]. Similarly, the IScalable would have

--o IScalable { VScale, HScale, VHScale, NoScale } concrete implementations. Now, We can add the interface references to the 'Graph' class so that the classes BarGraph, LineGraph and PieGraph are free to chose their implementations dynamically at runtime. Cool innit ? . ( This is the open closed principle). We are giving the interface, but not the modifiable implementation to the 'Graph' class.

The strategy pattern oriented solution will look like the following.

The IScalable interface and it's concrete implementations

IScalable

The IDrawable and it's concrete implementations

IDrawable

The Graph Class hierarchy

MainClasses

The Final Solution

Strategy

The conclusion.

------------------------------------------------------------------------------------------------

I'll leave the Pros and Cons to the reader to decide and evaluate. But the strategy pattern's promise for sure is that it will allow your algorithms to evolve independently of your main class hierarchy. So there won't be any side effects or breaking up of the hierarchy.

------------------------------------------------------------------------------------------------

Finally some generalizations..

------------------------------------------------------------------------------------------------

If you are not inviting change, I'm sure you're not in software development. This is where experience comes for a cost!!! it counts where it matters most!!! I've always felt there are 2 kind of developers in this world. Developers who know what to do AND the incapable or often 'confused' mutts. The incapable mutts fall into a zillion multi-disciplinary categories. So, think of the design principles while writing or re factoring code. Keep it flexible, easy to maintain and above all watch out for patterns.

------------------------------------------------------------------------------------------------

*** Behavioural Patterns: Patterns that are most concerned with communication between objects. They are also concerned with encapsulating behaviours in an object and delegating requests to it.

------------------------------------------------------------------------------------------------

Some Links:

1] A claim that Java's extend is evil

2] Classes in the .NET BCL. Also take a look at .NET 3.5 LINQ Classes.

3] Java 2 API: Take a look at Line,Line2D.Double and Line2D.Float Classes. A more comprehensive study (to make life hell) would be to consider

java.lang.Object

-java.util.AbstractCollection

-java.util.AbstractList

-java.util.AbstractSequentialList

- java.util.LinkedList

SourceCode: Here

Comments / Criticisms / Discussions are welcome.

Friday 25 July 2008

Designing an Enumerator for Business Objects

Following is my elegant enumerator design which can be used for enumerating business objects from the database. Designing an enumerator with C#, .Net 3.5 will be much more elegant simply because of LINQ and LINQ to SQL. I will write about it in my future posts. LINQ has made it extremely easy to do such things, and i will prove my point in the future posts. This is also mostly based on Enterprise patterns (Check out the most famous Martin Fowler's book) . I've used a Table Gateway and a normal Iterator pattern.

BusinessObjectEnumerator

 

Product - Business Object

Product.cs

public class Product
{
int id;

public int Id {
get {
return id;
}
set {
id = value;
}
}
string name;

public string Name {
get {
return name;
}
set {
name = value;
}
}
double price;

public double Price {
get {
return price;
}
set {
price = value;
}
}

public override bool Equals(object obj) {
if (null==obj)
return false;
else
{
Product p = obj as Product;
return (p.id == this.id);
}
}

public override int GetHashCode() {
return id.GetHashCode();
}

public override string ToString() {
return name.ToString();
}



 



DBEnumerator.cs



    public abstract class DBEnumerator<T>:IEnumerator,IEnumerable
{
private int position;
protected List<T> list;
protected TableGateway tablegateway;
protected abstract void Read(string sql);
public virtual void Add(T item) {
if (!list.Contains(item))
{
list.Add(item);
}
}

#region IEnumerable Members

public IEnumerator GetEnumerator() {
return (IEnumerator)this;
}

#endregion

#region IEnumerator Members

public object Current {
get {
return (object)list[position];
}
}

public bool MoveNext() {
position++;
return (position < list.Count);
}

public void Reset() {
position = -1;
}

#endregion
}



ProductEnumerator.cs



    public class ProductEnumerator:DBEnumerator<Product>
{
public ProductEnumerator(string sql) {
this.tablegateway = new TableGateway();
this.list = new List<Product>();
Read(sql);
this.Reset();
}

internal TableGateway TableGateway {
get {
return tablegateway;
}
}

protected override void Read(string sql) {
DataTable dt = new DataTable();
dt = tablegateway.ExecuteNonQuery(sql);
foreach (DataRow row in dt.Rows)
{
Product p = new Product();
p.Id = Convert.ToInt32(row["Id"].ToString());
p.Name = row["Name"].ToString();
p.Price = Convert.ToDouble(row["Price"].ToString());
Add(p);
}
}
}



TableGateway.cs



   public class TableGateway
{
private string connstring;
private IDbCommand command;
private Collection<IDataParameter> parameters;

public TableGateway() {
connstring = "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=C:\\Projects\\C#Projects"+
"\\BusinessObjectEnumerator\\Inventory.mdb;";
parameters = new Collection<IDataParameter>();
}

public void AddParameters(string parameterName, string parameterValue) {
IDataParameter param = command.CreateParameter();
param.ParameterName = parameterName;
param.Value = parameterValue;
}


public string TableName{
get {return "Tablegateway";}
}

public DataTable ExecuteNonQuery(string sql)
{
using (IDbConnection conn = GetConnection())
{
command = conn.CreateCommand();
foreach (IDataParameter param in parameters){
command.Parameters.Add(param);
}

OleDbDataAdapter oledbdataadapter = new OleDbDataAdapter(sql,(OleDbConnection) conn);
DataSet dataset = new DataSet();
try
{
oledbdataadapter.Fill(dataset, this.TableName);
}
catch
{
throw;

}
finally
{
conn.Close();
}
return dataset.Tables[TableName];
}
}

private IDbConnection GetConnection() {
return new OleDbConnection(connstring);
}

}



Putting the ProductEnumerator to test



  static void Main(string[] args) {

ProductEnumerator myproducts = new ProductEnumerator ("select * from products");

Console.WriteLine("Enumerating products..\n");

foreach (Product p in myproducts){
Console.WriteLine("ID: ,"+p.Id+
"Name: ,"+ p.Name+
"Price: ,"+p.Price);
}

Console.WriteLine("\nPress any key to exit..");
Console.ReadKey();
}



Notice, Since we have implemented the IEnumerable and IEnumerator interfaces, we can use the ProductEnumerator in a foreach statement. This will be the cool part of Enumerators. The MSIL generation for the foreach statement would do something like the following:



IEnumerator ienum = myproducts.GetEnumerator();



while(ienum.MoveNext()) {



...



}



Also, We can  provide mechanisms to add stuff into the List<T> of the DBEnumerator. By doing this we will need to have some mechanisms to persist the newly added object to the DB. In other words instantaneously serialize the object. This will require some kind of an EventHandler to track the List<T> added event. Hmm... reminds me of a 1000 patterns from Martin Fowler , just to do this.. :) (Oh, my brave attempt to write a DataMapper in 3 days, i paid the price in the ACW..Thanks to Dr.Grey for enlightening me about my deed)



Output



Enumerating products..



ID: ,1Name: ,Product APrice: ,10.99

ID: ,2Name: ,Product BPrice: ,12.99


ID: ,3Name: ,Product CPrice: ,10.99


ID: ,4Name: ,Product DPrice: ,14.99


ID: ,5Name: ,Product EPrice: ,19


ID: ,6Name: ,Product FPrice: ,19.99


ID: ,7Name: ,Product GPrice: ,7.99


ID: ,8Name: ,Product HPrice: ,5.45


ID: ,9Name: ,Product IPrice: ,3.44


ID: ,10Name: ,Product JPrice: ,0.99



Press any key to exit..



The DB (for proof)



image



Tuesday 10 June 2008

The Decorator Pattern Part I

The Need for the Decorator Pattern:

Decorators can be used to decorate classes at runtime using a form of object composition.This is a good pattern which helps to minimize overuse of inheritance for adding special behaviours to classes. Decorators are primarily used to add flexibility to design. They are used to add more behaviours to existing classes by adding a wrapper around them,without changing the existing code. One needs to be careful in writing a decorator. Too much decoration can make the code lousy,difficult to read,modify and maintain. For instance, consider Java's I/O libraries. They are notoriously difficult for people to understand at first. But if they just saw the classes as a set of wrappers around the abstract class InputStream, life would be simpler..

Learning by example..

1. Recognising the decorators from the Java.IO classes

Decorator1

The InputStream is the abstract component. The FilterInputStream, ByteArrayInputStream, StringBufferInputStream and the FileInputStream are abstract decorators.

Now, PushbackInputStream, BufferedInputStream, DataInputStream and LineNumberInputStream are all concrete decorators.

Now, think about the decorators and the flexibility it adds to the design of Java.IO in the following sentences..(Classes are open for extension but closed for modification)

InputStream in = new BufferedInputStream(new FileInputStream("aFile.txt"));

BufferedInputStream bis =  new BufferedInputStream ( new DataInputStream ( new FileInputStream ( "aFile.txt" )  )  ) ;

 

2. An example of decorating our beverage component by using an abstract decorator 'CondimentDecorator' and a single concrete decorator 'Mocha'. The concrete components add specialized classes (HouseBlend, Espreso). We will see this in more detail in Part II. Consider the following class diagram.

 

image

The Beverage is the component which we are interested in decorating here. The CondimentDecorator is the abstract decorator. The Classes Expresso and HouseBlend are concrete components. The Mocha class is a concrete decorator.

Now, look at the following code to understand the power of concrete decorators and the Decorator Pattern itself.

Beverage b1 = new Espresso();      // A type of Beverage, Concrete component

Beverage b2 = new HouseBlend(); //A type of Beverage, Concrete component

b2 = new Mocha(b2); //wrap the beverage with Mocha

 

Decorators Rule!, More reasons and justifications in Part II..

Tuesday 3 June 2008

The Observer Pattern

Before we understand what an observer does, we need to define and understand the following.

The Subject     :  An object which does something...(verb) like publishing an Event, changing it's state etc. This object is the subject object. The observers are interested in getting a notification when The Subject 'does something'

The Observers :   Objects which are to be kept notified when the Subject Object's Event,State has Changed. Examples of Subject Object 'doing something' :

                - Subject Object publishes an event

                - Subject Object's State changed etc.

The publisher and the subscriber model is a good example to understand an observer pattern. (Check out Java's Action Listeners) The publisher publishes the event. Now, Let's say, a set of objects are interested in this Event and they need to perform an action based on this Event. Therefore they subscribe to this event to get a notification (callback) from the Publisher, which notifies them when the event occurs or about the event  itself.

To Give a real-life example, Consider a File Reader (program written in C# of course), which reads a file line by line to EOF. Now, let's say a list of Observers/Listeners should be notified after every line is read by the File Reader. Therefore, they register with the Subscriber (File Reader in our case), After which, they get notifications from the Subscriber whenever the File Reader finishes reading a line from the file. Let's say it also gives them the line which it has currently read in the notification mechanism.

The Observer Design

Observer

 

 

 

 

 

 

 

( really don't like the way the class designer associations behave in visual studio, MS please do something about it yaar! )

FileReader associated to IFileListener by the ListIFileListners property in the above figure. FileReader has a List<IFileListeners> field, which is used to maintain the list of registered listeners.

Now, the Code..

public interface IFileListener
{
//callback after every line is read.
void ILineRead(string LineRead);
}


public class FileReader
{
private List<IFileListener> listeners;

public FileReader()
{
listeners = new List<IFileListener>();
}

public List<IFileListener> ListIFileListener
{
get
{
return listeners;
}
set
{
listeners = value;
}
}

public void Register(IFileListener lis)
{
if (listeners.Contains(lis)) {
throw new Exception("Listener already registered..");
}
else {
listeners.Add(lis);
}
}

public void Unregister(IFileListener lis)
{
if(listeners.Contains(lis)){
listeners.Remove(lis);
}
else{
throw new Exception("Listener not registered..");
}
}
/// <summary>
///
Reads a line of text from the input file and
/// sends a callback to all registered listeners.
/// </summary>
/// <param name="filename"></param>

public void ReadFile(string filename)
{
if (File.Exists(filename)) {
TextReader txtReader = File.OpenText(filename);
string line = "";
while ((line=txtReader.ReadLine())!=null) {
foreach (IFileListener lis in listeners) {
//send callbacks to registered listeners
lis.ILineRead(line);
}
}
}
else {
throw new Exception("Input file does not exist..");
}
}

}



The Usage:



class Program:IFileListener
{
public Program()
{
FileReader reader = new FileReader();
reader.Register(this);
reader.ReadFile("textfile.txt");
}

static void Main(string[] args)
{
Console.WriteLine("testing observers..");
Program pgm = new Program();
Console.WriteLine("\npress any key to exit..");
Console.ReadKey();
}


#region IFileListener Members
/// <summary>
///
This method gets automatic call back with
/// the string line which is currently read.
/// </summary>
/// <param name="LineRead"></param>
public void ILineRead(string LineRead)
{
Console.WriteLine("Read Line: " + LineRead);
}

#endregion
}



The Text File Contents..



AAVARANA AND DA VINCI CODE: A COMPARISON

N.S. Rajaram


http://rajeev2004.blogspot.com/2007/02/literary-phenomenon-historical-novel.html


Like Dan Brown's Da Vinci Code, S.L. Bhyrappa's Aavarana is likely to have far-reaching social and political fallout that goes beyond its literary niche. In reading S.L. Bhyrappa's latest Kannada novel Aavarana, Dan Brown's best selling novel Da Vinci Code springs naturally to mind. Both have as their subject the suppression of true history and the propagation of a myth by powerful interests. In Da Vinci Code, the villain is the Catholic Church and its modern secret and sinister arm the Opus Dei. In Bhyrappa's novel, the villain is the collective of politically correct historians and 'intellectuals' who out a combination of greed and fear have suppressed the truth about Islam and its record in India. While these intellectuals—called dhimmis by the Egypt-born scholar Bat Ye'or—can boast of no Vatican or Opus Dei, they do form a powerful clique enjoying the support of successive governments who find it politically expedient to appease Islam and conceal the truth about its record and teachings. As this phenomenon is by no means limited to India, Bhyrappa's Aavarana, and the public reaction to it should be of interest far beyond its intended readership..



Dr.S.L.Byrappa is a living legend of Kannada litereature. Dr.S.L.Byrappa is one of the most popular writer and Kannada novelist. He has a Phd in Philosophy; his doctoral dissertation entitled “Satya Mattu Soundarya” (Truth and Beauty) explores complex relationships between truth, ethics, beauty, art, existence, and philosophy. He has written some of the celebrated novels like “Vamsha Vruksha”, “Daatu”, most notably his magnum opus,“Parva”.



The present novel “Avarana” meaning “veil” or “truth masking”, is his second historical novel covering the time period between 8th - 14th centuries of India. His first historical novel 'SArTa' covered the time up to 8th century. The latest novel Avarana is already going for its 10th edition2. The novel has seen nine editions

in four months after it was first published in February last. The conflict of truth v/s untruth is the topic explored in his previous novel Sakshi at individual level. AvaraNa explores the same problem at the global level. The twin objectives of the novel- explore history and expose historians, who are distorting it. In the book


Byrappa tries to show the real history of India under Moghuls. The Marxists and Seculars have created the myth that Muslim rulers were tolerant. They deny that there was mass temple destruction and mass Killing of Hindus. But, Dr.Koenraad Elst in his book “Negationism in India Concealing the record of Islam”3 writes- “The Muslim conquests,down to the 16th century, were for the Hindus a pure struggle of life and death. Entire cities were burnt down and the populations massacred, with hundreds of thousands killed in every campaign, and similar numbers deported


as slaves. Every new invader made (often literally) his hills of Hindus skulls. Thus, the conquest of Afghanistan in the year 1000 was followed by the annihilation of the Hindu population; the region is still called the Hindu Kush,i.e. Hindu slaughter. The Bahmani sultans (1347-1480) in central India made it a rule to kill 100,000 captives in a single day, and many more on other occasions. The conquest of the Vijayanagar empire in 1564 left the capital plus large areas of Karnataka depopulated. And so on.”



The Output of Program



testing observers..

Read Line: AAVARANA AND DA VINCI CODE: A COMPARISON


Read Line: N.S. Rajaram


Read Line: http://rajeev2004.blogspot.com/2007/02/literary-phenomenon-historical-novel.html


Read Line: Like Dan Brown's Da Vinci Code, S.L. Bhyrappa's Aavarana is likely to


have far-reaching



.



.



.

Read Line: large areas of Karnataka depopulated. And so on.?



press any key to exit..