SOLID Principles

Leave a reply

Disclaimer:
The data in this site is for personal use only. It may contain the images,text etc from other site and credits go to their respective sites:
csharpconer
DotnetCurry

Why need for SOLID principles?
The following are the design flaws that cause the damage in software, mostly.
Putting more stress on classes by assigning more responsibilities to them. (A lot of functionality not related to a class.)
Forcing the classes to depend on each other. If classes are dependent on each other (in other words tightly coupled), then a change in one will affect the other.
Spreading duplicate code in the system/application.

Solution
Choosing the correct architecture (in other words MVC, 3-tier, Layered, MVP, MVVP and so on).
Following Design Principles.
Choosing correct Design Patterns to build the software based on its specifications.
Now we go through the Design Principles first and will cover the rest soon.

Intro to SOLID principles

SOLID principles are the design principles that enable us to manage with most of the software design problems. Robert C. Martin compiled these principles in the 1990s. These principles provide us ways to move from tightly coupled code and little encapsulation to the desired results of loosely coupled and encapsulated real needs of a business properly. SOLID is an acronym of the following.

S: Single Responsibility Principle (SRP)
O: Open closed Principle (OSP)
L: Liskov substitution Principle (LSP)
I: Interface Segregation Principle (ISP)
D: Dependency Inversion Principle (DIP)

S: Single Responsibility Principle (SRP)

SRP says “Every software module should have only one reason to change”.
This means that every class, or similar structure, in your code should have only one job to do. Everything in that class should be related to a single purpose. Our class should not be like a Swiss knife wherein if one of them needs to be changed then the entire tool needs to be altered. It does not mean that your classes should only contain one method or property. There may be many members as long as they relate to the single responsibility.

The Single Responsibility Principle gives us a good way of identifying classes at the design phase of an application and it makes you think of all the ways a class can change. A good separation of responsibilities is done only when we have the full picture of how the application should work. Let us check this with an example.

public class UserService
{
public void Register(string email, string password)
{
if (!ValidateEmail(email))
throw new ValidationException(“Email is not an email”);
var user = new User(email, password);
SendEmail(new MailMessage(“mysite@nowhere.com”, email) { Subject=“HEllo foo” });
}
public virtual bool ValidateEmail(string email)
{
return email.Contains(“@”);
}
public bool SendEmail(MailMessage message)
{
_smtpClient.Send(message);
}
}

It looks fine, but it is not following SRP. The SendEmail and ValidateEmail methods have nothing to do within the UserService class. Let’s refract it.

public class UserService
{
EmailService _emailService;
DbContext _dbContext;
public UserService(EmailService aEmailService, DbContext aDbContext)
{
_emailService = aEmailService;
_dbContext = aDbContext;
}
public void Register(string email, string password)
{
if (!_emailService.ValidateEmail(email))
throw new ValidationException(“Email is not an email”);
var user = new User(email, password);
_dbContext.Save(user);
emailService.SendEmail(new MailMessage(“myname@mydomain.com”, email) {Subject=“Hi. How are you!”});
}
}
public class EmailService
{
SmtpClient _smtpClient;
public EmailService(SmtpClient aSmtpClient)
{
_smtpClient = aSmtpClient;
}
public bool virtual ValidateEmail(string email)
{
return email.Contains(“@”);
}
public bool SendEmail(MailMessage message)
{
_smtpClient.Send(message);
}
}

O: Open/Closed Principle

The Open/closed Principle says “A software module/class is open for extension and closed for modification”.
Here “Open for extension” means, we need to design our module/class in such a way that the new functionality can be added only when new requirements are generated. “Closed for modification” means we have already developed a class and it has gone through unit testing. We should then not alter it until we find bugs. As it says, a class should be open for extensions, we can use inheritance to do this. Okay, let’s dive into an example.
Suppose we have a Rectangle class with the properties Height and Width.

public class Rectangle{
public double Height {get;set;}
public double Wight {get;set; }
}

Our app needs the ability to calculate the total area of a collection of Rectangles. Since we already learned the Single Responsibility Principle (SRP), we don’t need to put the total area calculation code inside the rectangle. So here I created another class for area calculation.

public class AreaCalculator {
public double TotalArea(Rectangle[] arrRectangles)
{
double area;
foreach(var objRectangle in arrRectangles)
{
area += objRectangle.Height * objRectangle.Width;
}
return area;
}
}
Hey, we did it. We made our app without violating SRP. No issues for now. But can we extend our app so that it could calculate the area of not only Rectangles but also the area of Circles as well? Now we have an issue with the area calculation issue, because the way to do circle area calculation is different. Hmm. Not a big deal. We can change the TotalArea method a bit, so that it can accept an array of objects as an argument. We check the object type in the loop and do area calculation based on the object type.
public class Rectangle{
public double Height {get;set;}
public double Wight {get;set; }
}
public class Circle{
public double Radius {get;set;}
}
public class AreaCalculator
{
public double TotalArea(object[] arrObjects)
{
double area = 0;
Rectangle objRectangle;
Circle objCircle;
foreach(var obj in arrObjects)
{
if(obj is Rectangle)
{
area += obj.Height * obj.Width;
}
else
{
objCircle = (Circle)obj;
area += objCircle.Radius * objCircle.Radius * Math.PI;
}
}
return area;
}
}
Wow. We are done with the change. Here we successfully introduced Circle into our app. We can add a Triangle and calculate it’s area by adding one more “if” block in the TotalArea method of AreaCalculator. But every time we introduce a new shape we need to alter the TotalArea method. So the AreaCalculator class is not closed for modification. How can we make our design to avoid this situation? Generally we can do this by referring to abstractions for dependencies, such as interfaces or abstract classes, rather than using concrete classes. Such interfaces can be fixed once developed so the classes that depend upon them can rely upon unchanging abstractions. Functionality can be added by creating new classes that implement the interfaces. So let’s refract our code using an interfacepublic abstract class Shape
{
public abstract double Area();
}
Inheriting from Shape, the Rectangle and Circle classes now look like this:
public class Rectangle: Shape
{
public double Height {get;set;}
public double Width {get;set;}
public override double Area()
{
return Height * Width;
}
}
public class Circle: Shape
{
public double Radius {get;set;}
public override double Area()
{
return Radius * Radus * Math.PI;
}
}
Every shape contains its area with its own way of calculation functionality and our AreaCalculator class will become simpler than before.
public class AreaCalculator
{
public double TotalArea(Shape[] arrShapes)
{
double area=0;
foreach(var objShape in arrShapes)
{
area += objShape.Area();
}
return area;
}
}
Now our code is following SRP and OCP both. Whenever you introduce a new shape by deriving from the “Shape” abstract class, you need not change the “AreaCalculator” class. Awesome. Isn’t it?

L: Liskov Substitution Principle

The Liskov Substitution Principle (LSP) states that “you should be able to use any derived class instead of a parent class and have it behave in the same manner without modification”. It ensures that a derived class does not affect the behavior of the parent class, in other words that a derived class must be substitutable for its base class.

This principle is just an extension of the Open Close Principle and it means that we must ensure that new derived classes extend the base classes without changing their behavior. I will explain this with a real world example that violates LSP.

A father is a doctor whereas his son wants to become a cricketer. So here the son can’t replace his father even though they both belong to the same family hierarchy.

Now jump into an example to learn how a design can violate LSP. Suppose we need to build an app to manage data using a group of SQL files text. Here we need to write functionality to load and save the text of a group of SQL files in the application directory. So we need a class that manages the load and saves the text of group of SQL files along with the SqlFile Class.
public class SqlFile
{
public string FilePath {get;set;}
public string FileText {get;set;}
public string LoadText()
{
/* Code to read text from sql file */
}
public string SaveText()
{
/* Code to save text into sql file */
}
}
public class SqlFileManager
{
public List<SqlFile> lstSqlFiles {get;set}
public string GetTextFromFiles()
{
StringBuilder objStrBuilder = new StringBuilder();
foreach(var objFile in lstSqlFiles)
{
objStrBuilder.Append(objFile.LoadText());
}
return objStrBuilder.ToString();
}
public void SaveTextIntoFiles()
{
foreach(var objFile in lstSqlFiles)
{
objFile.SaveText();
}
}
}
OK. We are done with our part. The functionality looks good for now. After some time our lead might tell us that we may have a few read-only files in the application folder, so we need to restrict the flow whenever it tries to do a save on them.OK. We can do that by creating a “ReadOnlySqlFile” class that inherits the “SqlFile” class and we need to alter the SaveTextIntoFiles() method by introducing a condition to prevent calling the SaveText() method on ReadOnlySqlFile instances.
public class SqlFile
{
public string LoadText()
{
/* Code to read text from sql file */
}
public void SaveText()
{
/* Code to save text into sql file */
}
}
public class ReadOnlySqlFile: SqlFile
{
public string FilePath {get;set;}
public string FileText {get;set;}
public string LoadText()
{
/* Code to read text from sql file */
}
public void SaveText()
{
/* Throw an exception when app flow tries to do save. */
throw new IOException(“Can’t Save”);
}
}
To avoid an exception we need to modify “SqlFileManager” by adding one condition to the loop.
public class SqlFileManager
{
public List<SqlFile? lstSqlFiles {get;set}
public string GetTextFromFiles()
{
StringBuilder objStrBuilder = new StringBuilder();
foreach(var objFile in lstSqlFiles)
{
objStrBuilder.Append(objFile.LoadText());
}
return objStrBuilder.ToString();
}
public void SaveTextIntoFiles()
{
foreach(var objFile in lstSqlFiles)
{
//Check whether the current file object is read only or not.If yes, skip calling it’s
// SaveText() method to skip the exception.
if(! objFile is ReadOnlySqlFile)
objFile.SaveText();
}
}
}
Here we altered the SaveTextIntoFiles() method in the SqlFileManager class to determine whether or not the instance is of ReadOnlySqlFile to avoid the exception. We can’t use this ReadOnlySqlFile class as a substitute of its parent without altering SqlFileManager code. So we can say that this design is not following LSP. Let’s make this design follow the LSP. Here we will introduce interfaces to make the SqlFileManager class independent from the rest of the blocks.
public interface IReadableSqlFile
{
string LoadText();
}
public interface IWritableSqlFile
{
void SaveText();
}
Now we implement IReadableSqlFile through the ReadOnlySqlFile class that reads only the text from read-only files.
public class ReadOnlySqlFile: IReadableSqlFile
{
public string FilePath {get;set;}
public string FileText {get;set;}
public string LoadText()
{
/* Code to read text from sql file */
}
}
Here we implement both IWritableSqlFile and IReadableSqlFile in a SqlFile class by which we can read and write files.
public class SqlFile: IWritableSqlFile,IReadableSqlFile
{
public string FilePath {get;set;}
public string FileText {get;set;}
public string LoadText()
{
/* Code to read text from sql file */
}
public void SaveText()
{
/* Code to save text into sql file */
}
}
Now the design of the SqlFileManager class becomes like this:
public class SqlFileManager
{
public string GetTextFromFiles(List<IReadableSqlFile> aLstReadableFiles)
{
StringBuilder objStrBuilder = new StringBuilder();
foreach(var objFile in aLstReadableFiles)
{
objStrBuilder.Append(objFile.LoadText());
}
return objStrBuilder.ToString();
}
public void SaveTextIntoFiles(List<IWritableSqlFile> aLstWritableFiles)
{
foreach(var objFile in aLstWritableFiles)
{
objFile.SaveText();
}
}
}
Here the GetTextFromFiles() method gets only the list of instances of classes that implement the IReadOnlySqlFile interface. That means the SqlFile and ReadOnlySqlFile class instances. And the SaveTextIntoFiles() method gets only the list instances of the class that implements the IWritableSqlFiles interface, in other words SqlFile instances in this case. Now we can say our design is following the LSP. And we fixed the problem using the Interface segregation principle by (ISP) identifying the abstraction and the responsibility separation method.

I: Interface Segregation Principle (ISP)

The Interface Segregation Principle states “that clients should not be forced to implement interfaces they don’t use. Instead of one fat interface many small interfaces are preferred based on groups of methods, each one serving one sub module.”.

We can define it in another way. An interface should be more closely related to the code that uses it than code that implements it. So the methods on the interface are defined by which methods the client code needs rather than which methods the class implements. So clients should not be forced to depend upon interfaces that they don’t use.

Like classes, each interface should have a specific purpose/responsibility (refer to SRP). You shouldn’t be forced to implement an interface when your object doesn’t share that purpose. The larger the interface, the more likely it includes methods that not all implementers can do. That’s the essence of the Interface Segregation Principle. Let’s start with an example that breaks ISP. Suppose we need to build a system for an IT firm that contains roles like TeamLead and Programmer where TeamLead divides a huge task into smaller tasks and assigns them to his/her programmers or can directly work on them.

Based on specifications, we need to create an interface and a TeamLead class to implement it.
public Interface ILead
{
void CreateSubTask();
void AssginTask();
void WorkOnTask();
}
public class TeamLead : ILead
{
public void AssignTask()
{
//Code to assign a task.
}
public void CreateSubTask()
{
//Code to create a sub task
}
public void WorkOnTask()
{
//Code to implement perform assigned task.
}
}
OK. The design looks fine for now. Later another role like Manager, who assigns tasks to TeamLead and will not work on the tasks, is introduced into the system. Can we directly implement an ILead interface in the Manager class, like the following?
public class Manager: ILead
{
public void AssignTask()
{
//Code to assign a task.
}
public void CreateSubTask()
{
//Code to create a sub task.
}
public void WorkOnTask()
{
throw new Exception(“Manager can’t work on Task”);
}
}
Since the Manager can’t work on a task and at the same time no one can assign tasks to the Manager, this WorkOnTask() should not be in the Manager class. But we are implementing this class from the ILead interface, we need to provide a concrete Method. Here we are forcing the Manager class to implement a WorkOnTask() method without a purpose. This is wrong. The design violates ISP. Let’s correct the design.Since we have three roles, 1. Manager, that can only divide and assign the tasks , 2. TeamLead that can divide and assign the tasks and can work on them as well, 3. Programmer that can only work on tasks, we need to divide the responsibilities by segregating the ILead interface. An interface that provides a contract for WorkOnTask().
1. public interface IProgrammer
2. {
3. void WorkOnTask();
4. }
An interface that provides contracts to manage the tasks:
1. public interface ILead
2. {
3. void AssignTask();
4. void CreateSubTask();
5. }
Then the implementation becomes:
1. public class Programmer: IProgrammer
2. {
3. public void WorkOnTask()
4. {
5. //code to implement to work on the Task.
6. }
7. }
8. public class Manager: ILead
9. {
10. public void AssignTask()
11. {
12. //Code to assign a Task
13. }
14. public void CreateSubTask()
15. {
16. //Code to create a sub taks from a task.
17. }
18. }
TeamLead can manage tasks and can work on them if needed. Then the TeamLead class should implement both of the IProgrammer and ILead interfaces.
1. public class TeamLead: IProgrammer, ILead
2. {
3. public void AssignTask()
4. {
5. //Code to assign a Task
6. }
7. public void CreateSubTask()
8. {
9. //Code to create a sub task from a task.
10. }
11. public void WorkOnTask()
12. {
13. //code to implement to work on the Task.
14. }
15. }
Wow. Here we separated responsibilities/purposes and distributed them on multiple interfaces and provided a good level of abstraction too.

D: Dependency Inversion Principle

The Dependency Inversion Principle (DIP) states that high-level modules/classes should not depend on low-level modules/classes. Both should depend upon abstractions. Secondly, abstractions should not depend upon details. Details should depend upon abstractions.

High-level modules/classes implement business rules or logic in a system (application). Low-level modules/classes deal with more detailed operations; in other words they may deal with writing information to databases or passing messages to the operating system or services.

A high-level module/class that has dependency on low-level modules/classes or some other class and knows a lot about the other classes it interacts with is said to be tightly coupled. When a class knows explicitly about the design and implementation of another class, it raises the risk that changes to one class will break the other class. So we must keep these high-level and low-level modules/classes loosely coupled as much as we can. To do that, we need to make both of them dependent on abstractions instead of knowing each other. Let’s start with an example.

Suppose we need to work on an error logging module that logs exception stack traces into a file. Simple, isn’t it? The following are the classes that provide functionality to log a stack trace into a file.
1. public class FileLogger
2. {
3. public void LogMessage(string aStackTrace)
4. {
5. //code to log stack trace into a file.
6. }
7. }
8. public class ExceptionLogger
9. {
10. public void LogIntoFile(Exception aException)
11. {
12. FileLogger objFileLogger = new FileLogger();
13. objFileLogger.LogMessage(GetUserReadableMessage(aException));
14. }
15. private GetUserReadableMessage(Exception ex)
16. {
17. string strMessage = string. Empty;
18. //code to convert Exception’s stack trace and message to user readable format.
19. ….
20. ….
21. return strMessage;
22. }
23. }
A client class exports data from many files to a database.
1. public class DataExporter
2. {
3. public void ExportDataFromFile()
4. {
5. try {
6. //code to export data from files to database.
7. }
8. catch(Exception ex)
9. {
10. new ExceptionLogger().LogIntoFile(ex);
11. }
12. }
13. }
Looks good. We sent our application to the client. But our client wants to store this stack trace in a database if an IO exception occurs. Hmm… okay, no problem. We can implement that too. Here we need to add one more class that provides the functionality to log the stack trace into the database and an extra method in ExceptionLogger to interact with our new class to log the stack trace.
1. public class DbLogger
2. {
3. public void LogMessage(string aMessage)
4. {
5. //Code to write message in database.
6. }
7. }
8. public class FileLogger
9. {
10. public void LogMessage(string aStackTrace)
11. {
12. //code to log stack trace into a file.
13. }
14. }
15. public class ExceptionLogger
16. {
17. public void LogIntoFile(Exception aException)
18. {
19. FileLogger objFileLogger = new FileLogger();
20. objFileLogger.LogMessage(GetUserReadableMessage(aException));
21. }
22. public void LogIntoDataBase(Exception aException)
23. {
24. DbLogger objDbLogger = new DbLogger();
25. objDbLogger.LogMessage(GetUserReadableMessage(aException));
26. }
27. private string GetUserReadableMessage(Exception ex)
28. {
29. string strMessage = string.Empty;
30. //code to convert Exception’s stack trace and message to user readable format.
31. ….
32. ….
33. return strMessage;
34. }
35. }
36. public class DataExporter
37. {
38. public void ExportDataFromFile()
39. {
40. try {
41. //code to export data from files to database.
42. }
43. catch(IOException ex)
44. {
45. new ExceptionLogger().LogIntoDataBase(ex);
46. }
47. catch(Exception ex)
48. {
49. new ExceptionLogger().LogIntoFile(ex);
50. }
51. }
52. }
Looks fine for now. But whenever the client wants to introduce a new logger, we need to alter ExceptionLogger by adding a new method. If we continue doing this after some time then we will see a fat ExceptionLogger class with a large set of methods that provide the functionality to log a message into various targets. Why does this issue occur? Because ExceptionLogger directly contacts the low-level classes FileLogger and DbLogger to log the exception. We need to alter the design so that this ExceptionLogger class can be loosely coupled with those class. To do that we need to introduce an abstraction between them, so that ExcetpionLogger can contact the abstraction to log the exception instead of depending on the low-level classes directly.
1. public interface ILogger
2. {
3. void LogMessage(string aString);
4. }
Now our low-level classes need to implement this interface.
1. public class DbLogger: ILogger
2. {
3. public void LogMessage(string aMessage)
4. {
5. //Code to write message in database.
6. }
7. }
8. public class FileLogger: ILogger
9. {
10. public void LogMessage(string aStackTrace)
11. {
12. //code to log stack trace into a file.
13. }
14. }
Now, we move to the low-level class’s initiation from the ExcetpionLogger class to the DataExporter class to make ExceptionLogger loosely coupled with the low-level classes FileLogger and EventLogger. And by doing that we are giving provision to DataExporter class to decide what kind of Logger should be called based on the exception that occurs.
1. public class ExceptionLogger
2. {
3. private ILogger _logger;
4. public ExceptionLogger(ILogger aLogger)
5. {
6. this._logger = aLogger;
7. }
8. public void LogException(Exception aException)
9. {
10. string strMessage = GetUserReadableMessage(aException);
11. this._logger.LogMessage(strMessage);
12. }
13. private string GetUserReadableMessage(Exception aException)
14. {
15. string strMessage = string.Empty;
16. //code to convert Exception’s stack trace and message to user readable format.
17. ….
18. ….
19. return strMessage;
20. }
21. }
22. public class DataExporter
23. {
24. public void ExportDataFromFile()
25. {
26. ExceptionLogger _exceptionLogger;
27. try {
28. //code to export data from files to database.
29. }
30. catch(IOException ex)
31. {
32. _exceptionLogger = new ExceptionLogger(new DbLogger());
33. _exceptionLogger.LogException(ex);
34. }
35. catch(Exception ex)
36. {
37. _exceptionLogger = new ExceptionLogger(new FileLogger());
38. _exceptionLogger.LogException(ex);
39. }
40. }
41. }
We successfully removed the dependency on low-level classes. This ExceptionLogger doesn’t depend on the FileLogger and EventLogger classes to log the stack trace. We don’t need to change the ExceptionLogger’s code any more for any new logging functionality. We need to create a new logging class that implements the ILogger interface and must add another catch block to the DataExporter class’s ExportDataFromFile method.
1. public class EventLogger: ILogger
2. {
3. public void LogMessage(string aMessage)
4. {
5. //Code to write message in system’s event viewer.
6. }
7. }
And we need to add a condition in the DataExporter class as in the following:
1. public class DataExporter
2. {
3. public void ExportDataFromFile()
4. {
5. ExceptionLogger _exceptionLogger;
6. try {
7. //code to export data from files to database.
8. }
9. catch(IOException ex)
10. {
11. _exceptionLogger = new ExceptionLogger(new DbLogger());
12. _exceptionLogger.LogException(ex);
13. }
14. catch(SqlException ex)
15. {
16. _exceptionLogger = new ExceptionLogger(new EventLogger());
17. _exceptionLogger.LogException(ex);
18. }
19. catch(Exception ex)
20. {
21. _exceptionLogger = new ExceptionLogger(new FileLogger());
22. _exceptionLogger.LogException(ex);
23. }
24. }
25. }
Looks good. But we introduced the dependency here in the DataExporter class’s catch blocks. Yeah, someone must take the responsibility to provide the necessary objects to the ExceptionLogger to get the work done.

Let me explain it with a real world example. Suppose we want to have a wooden chair with specific measurements and the kind of wood to be used to make that chair. Then we can’t leave the decision making on measurements and the wood to the carpenter. Here his job is to make a chair based on our requirements with his tools and we provide the specifications to him to make a good chair.

So what is the benefit we get by the design? Yes, we definitely have a benefit with it. We need to modify both the DataExporter class and ExceptionLogger class whenever we need to introduce a new logging functionality. But in the updated design we need to add only another catch block for the new exception logging feature. Coupling is not inherently evil. If you don’t have some amount of coupling, your software will not do anything for you. The only thing we need to do is understand the system, requirements and environment properly and find areas where DIP should be followed.

Dependency Injection

Leave a reply

What is dependency Injection?

Dependency Injection(DI) means to decouple the objects which are dependent on each other. Say object A is dependent on Object B so the idea is to decouple these object from each other. We don’t need to hard code the object using new keyword rather sharing dependencies to objects at runtime in spite of compile time. If we talk about

How Dependency Injection works in Spring:

We don’t need to hard code the object using new keyword rather define the bean dependency in the configuration file. The spring container will be responsible for hooking up all.

Inversion of Control (IOC)

IOC is a general concept and it can be expressed in many different ways and Dependency Injection is one concrete example of IOC.

Two types of Dependency Injection:

Constructor Injection
Setter Injection

1. Constructor-based dependency injection:

Constructor-based DI is accomplished when the container invokes a class constructor with a number of arguments, each representing a dependency on other class.

public class Triangle {

private String type;

public String getType(){
    return type;
 }

public Triangle(String type){   //constructor injection
    this.type=type;
 }
}
<bean id=triangle" class ="com.test.dependencyInjection.Triangle">
        <constructor-arg value="20"/>
  </bean>

2. Setter-based dependency injection:

Setter-based DI is accomplished by the container calling setter methods on your beans after invoking a no-argument constructor or no-argument static factory method to instantiate your bean.

public class Triangle{

 private String type;

 public String getType(){
    return type;
  }
 public void setType(String type){          //setter injection
    this.type = type;
  }
 }

<!-- setter injection -->
 <bean id="triangle" class="com.test.dependencyInjection.Triangle">
        <property name="type" value="equivialteral"/>

NOTE: It is a good rule of thumb to use constructor arguments for mandatory dependencies and setters for optional dependencies. Note that the if we use annotation based than @Required annotation on a setter can be used to make setters as a required dependencies.

—————————————————————————————————

It means that objects should only have as many dependencies as is needed to do their job and the dependencies should be few. Furthermore, an object’s dependencies should be on interfaces and not on “concrete” objects, when possible. (A concrete object is any object created with the keyword new.) Loose coupling promotes greater reusability, easier maintainability, and allows you to easily provide “mock” objects in place of expensive services.

The “Dependency Injection” (DI) is also known as “Inversion of Control” (IoC), can be used as a technique for encouraging this loose coupling.

There are two primary approaches to implementing DI:

Constructor injection
Setter injection

Constructor injection

It’s the technique of passing objects dependencies to its constructor.

Note that the constructor accepts an interface and not concrete object. Also, note that an exception is thrown if the orderDao parameter is null. This emphasizes the importance of receiving a valid dependency. Constructor Injection is, in my opinion, the preferred mechanism for giving an object its dependencies. It is clear to the developer while invoking the object which dependencies need to be given to the “Person” object for proper execution.

Setter Injection

But consider the following example… Suppose you have a class with ten methods that have no dependencies, but you’re adding a new method that does have a dependency on IDAO. You could change the constructor to use Constructor Injection, but this may force you to changes to all constructor calls all over the place. Alternatively, you could just add a new constructor that takes the dependency, but then how does a developer easily know when to use one constructor over the other. Finally, if the dependency is very expensive to create, why should it be created and passed to the constructor when it may only be used rarely? “Setter Injection” is another DI technique that can be used in situations such as this.

Setter Injection does not force dependencies to be passed to the constructor. Instead, the dependencies are set onto public properties exposed by the object in need. As implied previously, the primary motivators for doing this include:

Supporting dependency injection without having to modify the constructor of a legacy class.
Allowing expensive resources or services to be created as late as possible and only when needed.

Here is the example of how the above code would look like:

public class Person {
    public Person() {}

    public IDAO Address {
        set { addressdao = value; }
        get {
            if (addressdao == null)
              throw new MemberAccessException("addressdao" +
                             " has not been initialized");
            return addressdao;
        }
    }

    public Address GetAddress() {
       // ... code that uses the addressdao object
       // to fetch address details from the datasource ...
    }

    // Should not be called directly;
    // use the public property instead
    private IDAO addressdao;

One of the major advantages of dependency injection is that it can make testing lots easier. Suppose you have an object which in its constructor does something like:Basically, instead of having your objects creating a dependency or asking a factory object to make one for them, you pass the needed dependencies in to the constructor or via property setters, and you make it somebody else’s problem (an object further up the dependency graph, or a dependency injector that builds the dependency graph). A dependency as I’m using it here is any other object the current object needs to hold a reference to.

public SomeClass() {
    myObject = Factory.getObject();
}

This can be troublesome when all you want to do is run some unit tests on SomeClass, especially if myObject is something that does complex disk or network access. So now you’re looking at mocking myObject but also somehow intercepting the factory call. Hard. Instead, pass the object in as an argument to the constructor. Now you’ve moved the problem elsewhere, but testing can become lots easier. Just make a dummy myObject and pass that in. The constructor would now look a bit like:

public SomeClass (MyClass myObject) {
    this.myObject = myObject;
}

Most people can probably work out the other problems that might arise when not using dependency injection while testing (like classes that do too much work in their constructors etc.) Most of this is stuff I picked up on the Google Testing Blog, to be perfectly honest…

Dependency Injection is a type of implementation of the “Inversion of Control” principle on which is based Frameworks building.

Frameworks as stated in “Design Pattern” of GoF are classes that implement the main control flow logic raising the developer to do that, in this way Frameworks realize the inversion of control principle.

A way to implement as a technique, and not as class hierarchy, this IoC principle it is just Dependency Injection.

DI consists mainly into delegate the mapping of classes instances and type reference to that instances, to an external “entity”: an object, static class, component, framework, etc…

Classes instances are the “dependencies“, the external binding of the calling component with the class instance through the reference it is the “injection“.

Obviously you can implement this technique in many way as you want from OOP point of view, see for example constructor injection, setter injection, interface injection.

Delegating a third party to carry out the task of match a ref to an object it is very useful when you want to completely separate a component that needs some services from the same services implementation.

In this way, when designing components, you can focus exclusively on their architecture and their specific logic, trusting on interfaces for collaborating with other objects without worry about any type of implementation changes of objects/services used, also if the same object you are using will be totally replaced (obviously respecting the interface).

I found this funny example in terms of loose coupling:

Any application is composed of many objects that collaborate with each other to perform some useful stuff. Traditionally each object is responsible for obtaining its own references to the dependent objects (dependencies) it collaborate with. This leads to highly coupled classes and hard-to-test code.

For example, consider a Car object.

A Car depends on wheels, engine, fuel, battery, etc. to run. Traditionally we define the brand of such dependent objects along with the definition of the Car object.

Without Dependency Injection (DI):

class Car{
  private Wheel wh= new NepaliRubberWheel();
  private Battery bt= new ExcideBattery();

  //The rest
}

Here, the Car object is responsible for creating the dependent objects.

What if we want to change the type of its dependent object – say Wheel – after the initial NepaliRubberWheel() punctures? We need to recreate the Car object with its new dependency say ChineseRubberWheel(), but only the Car manufacturer can do that.

Then what does the Dependency Injection do us for…?

When using dependency injection, objects are given their dependencies at run time rather than compile time (car manufacturing time). So that we can now change the Wheel whenever we want. Here, the dependency (wheel) can be injected into Car at run time.

After using dependency injection:

Here, we are injecting the dependencies (Wheel and Battery) at runtime. Hence the term : Dependency Injection.

class Car{
  private Wheel wh= [Inject an Instance of Wheel (dependency of car) at runtime]
  private Battery bt= [Inject an Instance of Battery (dependency of car) at runtime]
  Car(Wheel wh,Battery bt) {
      this.wh = wh;
      this.bt = bt;
  }
  //Or we can have setters
  void setWheel(Wheel wh) {
      this.wh = wh;
  }
}

Source: Understanding dependency injection

Credits:
http://stackoverflow.com/questions/130794/what-is-dependency-injection

test title

2 Replies

test post

Singleton Pattern

Leave a reply

Sample 1:

Singleton pattern falls under Creational Pattern of Gang of Four (GOF) Design Patterns in .Net. It is pattern is one of the simplest design patterns. This pattern ensures that a class has only one instance. In this article, I would like share what is Singleton pattern and how is it work?

What is Singleton Pattern?

Singleton pattern is one of the simplest design patterns. This pattern ensures that a class has only one instance and provides a global point of access to it.

Singleton Pattern – UML Diagram & Implementation

The UML class diagram for the implementation of the Singleton design pattern is given below:

The classes, and objects in the above UML class diagram are as follows:

Singleton

This is a class which is responsible for creating and maintaining its own unique instance.

C# – Implementation Code

//eager initialization of singleton
public class Singleton
{
private static Singleton instance = new Singleton();
private Singleton() { }
public static Singleton GetInstance
{
get
{
return instance;
}
}
}
////lazy initialization of singleton
public class Singleton
{
private static Singleton instance = null;
private Singleton() { }
public static Singleton GetInstance
{
get
{
if (instance == null)
instance = new Singleton();
return instance;
}
}
}
////Thread-safe (Double-checked Locking) initialization of singleton
public class Singleton
{
private static Singleton instance = null;
private Singleton() { }
private static object lockThis = new object();
public static Singleton GetInstance
{
get
{
lock (lockThis)
{
if (instance == null)
instance = new Singleton();
return instance;
}
}
}
}

Singleton Pattern – Example

Who is what?

The classes and objects in the above class diagram can be identified as follows:

Singleton – Singleton class

C# – Sample Code

/// <summary>
/// The ‘Singleton’ class
/// </summary>
public class Singleton
{
// .NET guarantees thread safety for static initialization
private static Singleton instance = null;
private string Name{get;set;}
private string IP{get;set;}
private Singleton()
{
//To DO: Remove below line
Console.WriteLine(“Singleton Intance”);
Name = “Server1”;
IP = “192.168.1.23”;
}
// Lock synchronization object
private static object syncLock = new object();
public static Singleton Instance
{
get
{
// Support multithreaded applications through
// ‘Double checked locking’ pattern which (once
// the instance exists) avoids locking each
// time the method is invoked
lock (syncLock)
{
if (Singleton.instance == null)
Singleton.instance = new Singleton();
return Singleton.instance;
}
}
}
public void Show()
{
Console.WriteLine(“Server Information is : Name={0} & IP={1}”, IP, Name);
}
}
/// <summary>
/// Singleton Pattern Demo
/// </summary>
///
class Program
{
static void Main(string[] args)
{
Singleton.Instance.Show();
Singleton.Instance.Show();
Console.ReadKey();
}
}

Singleton Pattern Demo – Output

When to use it?

Exactly one instance of a class is required.
Controlled access to a single object is necessary.

Sample 2:

Singleton

Definition

UML diagram

Participants

Structural code in C#

Real-world code in C#

.NET Optimized code in C#

Definition

Ensure a class has only one instance and provide a global point of access to it.

Frequency of use:

Medium high

UML class diagram

Participants

The classes and objects participating in this pattern are:

Singleton (LoadBalancer)
- defines an Instance operation that lets clients access its unique instance. Instance is a class operation.
- responsible for creating and maintaining its own unique instance.

Structural code in C#

This structural code demonstrates the Singleton pattern which assures only a single instance (the singleton) of the class can be created.

using System;
namespace DoFactory.GangOfFour.Singleton.Structural
{
/// <summary>
/// MainApp startup class for Structural
/// Singleton Design Pattern.
/// </summary>
class MainApp
{
/// <summary>
/// Entry point into console application.
/// </summary>
static void Main()
{
// Constructor is protected — cannot use new
Singleton s1 = Singleton.Instance();
Singleton s2 = Singleton.Instance();
// Test for same instance
if (s1 == s2)
{
Console.WriteLine(“Objects are the same instance”);
}
// Wait for user
Console.ReadKey();
}
}
/// <summary>
/// The ‘Singleton’ class
/// </summary>
class Singleton
{
private static Singleton _instance;
// Constructor is ‘protected’
protected Singleton()
{
}
public static Singleton Instance()
{
// Uses lazy initialization.
// Note: this is not thread safe.
if (_instance == null)
{
_instance = new Singleton();
}
return _instance;
}
}
}

Output

Objects are the same instance

Real-world code in C#

This real-world code demonstrates the Singleton pattern as a LoadBalancing object. Only a single instance (the singleton) of the class can be created because servers may dynamically come on- or off-line and every request must go throught the one object that has knowledge about the state of the (web) farm.

using System;
using System.Collections.Generic;
using System.Threading;
namespace DoFactory.GangOfFour.Singleton.RealWorld
{
/// <summary>
/// MainApp startup class for Real-World
/// Singleton Design Pattern.
/// </summary>
class MainApp
{
/// <summary>
/// Entry point into console application.
/// </summary>
static void Main()
{
LoadBalancer b1 = LoadBalancer.GetLoadBalancer();
LoadBalancer b2 = LoadBalancer.GetLoadBalancer();
LoadBalancer b3 = LoadBalancer.GetLoadBalancer();
LoadBalancer b4 = LoadBalancer.GetLoadBalancer();
// Same instance?
if (b1 == b2 && b2 == b3 && b3 == b4)
{
Console.WriteLine(“Same instance\n”);
}
// Load balance 15 server requests
LoadBalancer balancer = LoadBalancer.GetLoadBalancer();
for (int i = 0; i < 15; i++)
{
string server = balancer.Server;
Console.WriteLine(“Dispatch Request to: “ + server);
}
// Wait for user
Console.ReadKey();
}
}
/// <summary>
/// The ‘Singleton’ class
/// </summary>
class LoadBalancer
{
private static LoadBalancer _instance;
private List<string> _servers = new List<string>();
private Random _random = new Random();
// Lock synchronization object
private static object syncLock = new object();
// Constructor (protected)
protected LoadBalancer()
{
// List of available servers
_servers.Add(“ServerI”);
_servers.Add(“ServerII”);
_servers.Add(“ServerIII”);
_servers.Add(“ServerIV”);
_servers.Add(“ServerV”);
}
public static LoadBalancer GetLoadBalancer()
{
// Support multithreaded applications through
// ‘Double checked locking’ pattern which (once
// the instance exists) avoids locking each
// time the method is invoked
if (_instance == null)
{
lock (syncLock)
{
if (_instance == null)
{
_instance = new LoadBalancer();
}
}
}
return _instance;
}
// Simple, but effective random load balancer
public string Server
{
get
{
int r = _random.Next(_servers.Count);
return _servers[r].ToString();
}
}
}
}

Output

Same instance

ServerIII
ServerII
ServerI
ServerII
ServerI
ServerIII
ServerI
ServerIII
ServerIV
ServerII
ServerII
ServerIII
ServerIV
ServerII
ServerIV

.NET Optimized code in C#

The .NET optimized code demonstrates the same code as above but uses more modern, built-in .NET features.

Here an elegant .NET specific solution is offered. The Singleton pattern simply uses a private constructor and a static readonlyinstance variable that is lazily initialized. Thread safety is guaranteed by the compiler.

using System;
using System.Collections.Generic;
namespace DoFactory.GangOfFour.Singleton.NETOptimized
{
/// <summary>
/// MainApp startup class for .NET optimized
/// Singleton Design Pattern.
/// </summary>
class MainApp
{
/// <summary>
/// Entry point into console application.
/// </summary>
static void Main()
{
LoadBalancer b1 = LoadBalancer.GetLoadBalancer();
LoadBalancer b2 = LoadBalancer.GetLoadBalancer();
LoadBalancer b3 = LoadBalancer.GetLoadBalancer();
LoadBalancer b4 = LoadBalancer.GetLoadBalancer();
// Confirm these are the same instance
if (b1 == b2 && b2 == b3 && b3 == b4)
{
Console.WriteLine(“Same instance\n”);
}
// Next, load balance 15 requests for a server
LoadBalancer balancer = LoadBalancer.GetLoadBalancer();
for (int i = 0; i < 15; i++)
{
string serverName = balancer.NextServer.Name;
Console.WriteLine(“Dispatch request to: “ + serverName);
}
// Wait for user
Console.ReadKey();
}
}
/// <summary>
/// The ‘Singleton’ class
/// </summary>
sealed class LoadBalancer
{
// Static members are ‘eagerly initialized’, that is,
// immediately when class is loaded for the first time.
// .NET guarantees thread safety for static initialization
private static readonly LoadBalancer _instance =
new LoadBalancer();
// Type-safe generic list of servers
private List<Server> _servers;
private Random _random = new Random();
// Note: constructor is ‘private’
private LoadBalancer()
{
// Load list of available servers
_servers = new List<Server>
{
new Server{ Name = “ServerI”, IP = “120.14.220.18” },
new Server{ Name = “ServerII”, IP = “120.14.220.19” },
new Server{ Name = “ServerIII”, IP = “120.14.220.20” },
new Server{ Name = “ServerIV”, IP = “120.14.220.21” },
new Server{ Name = “ServerV”, IP = “120.14.220.22” },
};
}
public static LoadBalancer GetLoadBalancer()
{
return _instance;
}
// Simple, but effective load balancer
public Server NextServer
{
get
{
int r = _random.Next(_servers.Count);
return _servers[r];
}
}
}
/// <summary>
/// Represents a server machine
/// </summary>
class Server
{
// Gets or sets server name
public string Name { get; set; }
// Gets or sets server IP address
public string IP { get; set; }
}
}

Output

Same instance

ServerIV
ServerIV
ServerIII
ServerV
ServerII
ServerV
ServerII
ServerII
ServerI
ServerIV
ServerIV
ServerII
ServerI
ServerV
ServerIV

Credits:
http://www.dotnet-tricks.com/Tutorial/designpatterns/L2KL080613-Singleton-Design-Pattern—C#.html
http://www.dofactory.com/net/singleton-design-pattern

For More Design Patterns:
http://www.c-sharpcorner.com/UploadFile/sathvik/DesignPatterns11012005085547AM/DesignPatterns.aspx

Facade Design Pattern

Leave a reply

Sample 1:
Facade pattern falls under Structural Pattern of Gang of Four (GOF) Design Patterns in .Net. The Facade design pattern is particularly used when a system is very complex or difficult to understand because system has a large number of interdependent classes or its source code is unavailable. In this article, I would like share what is facade pattern and how is it work?

What is facade Pattern

Facade pattern hides the complexities of the system and provides an interface to the client using which the client can access the system.

This pattern involves a single wrapper class which contains a set of members which are required by client. These members access the system on behalf of the facade client and hide the implementation details.

The facade design pattern is particularly used when a system is very complex or difficult to understand because system has a large number of interdependent classes or its source code is unavailable.

Facade Pattern – UML Diagram & Implementation

The UML class diagram for the implementation of the facade design pattern is given below:

The classes, interfaces and objects in the above UML class diagram are as follows:

Complex System

A library of subsystems.
SubsystemA, SubsystemB, SubsystemC

These are classes within complex system and offer detailed operations.
Façade

This is a wrapper class which wrapper class which contains a set of members which are required by client.
Client

This is a class which calls the high-level operations in the Façade.

C# – Implementation Code

class SubsystemA
{
public string OperationA1()
{
return “Subsystem A, Method A1\n”;
}
public string OperationA2()
{
return “Subsystem A, Method A2\n”;
}
}
class SubsystemB
{
public string OperationB1()
{
return “Subsystem B, Method B1\n”;
}
public string OperationB2()
{
return “Subsystem B, Method B2\n”;
}
}
class SubsystemC
{
public string OperationC1()
{
return “Subsystem C, Method C1\n”;
}
public string OperationC2()
{
return “Subsystem C, Method C2\n”;
}
}
public class Facade
{
SubsystemA a = new SubsystemA();
SubsystemB b = new SubsystemB();
SubsystemC c = new SubsystemC();
public void Operation1()
{
Console.WriteLine(“Operation 1\n” +
a.OperationA1() +
a.OperationA2() +
b.OperationB1());
}
public void Operation2()
{
Console.WriteLine(“Operation 2\n” +
b.OperationB2() +
c.OperationC1() +
c.OperationC2());
}
}

Façade Pattern – Example

Who is what?

The classes, interfaces and objects in the above class diagram can be identified as follows:

CarModel, CarEngine, CarBody, CarAccessories – These are subsystems.
CarFacade– Facade class.

C# – Sample Code

/// <summary>
/// The ‘Subsystem ClassA’ class
/// </summary>
class CarModel
{
public void SetModel()
{
Console.WriteLine(” CarModel – SetModel”);
}
}
/// <summary>
/// The ‘Subsystem ClassB’ class
/// </summary>
class CarEngine
{
public void SetEngine()
{
Console.WriteLine(” CarEngine – SetEngine”);
}
}
/// <summary>
/// The ‘Subsystem ClassC’ class
/// </summary>
class CarBody
{
public void SetBody()
{
Console.WriteLine(” CarBody – SetBody”);
}
}
/// <summary>
/// The ‘Subsystem ClassD’ class
/// </summary>
class CarAccessories
{
public void SetAccessories()
{
Console.WriteLine(” CarAccessories – SetAccessories”);
}
}
/// <summary>
/// The ‘Facade’ class
/// </summary>
public class CarFacade
{
CarModel model;
CarEngine engine;
CarBody body;
CarAccessories accessories;
public CarFacade()
{
model = new CarModel();
engine = new CarEngine();
body = new CarBody();
accessories = new CarAccessories();
}
public void CreateCompleteCar()
{
Console.WriteLine(“******** Creating a Car **********\n”);
model.SetModel();
engine.SetEngine();
body.SetBody();
accessories.SetAccessories();
Console.WriteLine(“\n******** Car creation complete **********”);
}
}
/// <summary>
/// Facade Pattern Demo
/// </summary>
class Program
{
static void Main(string[] args)
{
CarFacade facade = new CarFacade();
facade.CreateCompleteCar();
Console.ReadKey();
}
}

facade Pattern Demo – Output

When to use it?

A simple interface is required to access to a complex system.
The abstractions and implementations of a subsystem are tightly coupled.
Need an entry point to each level of layered software.
The facade design pattern is particularly used when a system is very complex or difficult to understand because system has a large number of interdependent classes or its source code is unavailable
Sample 2:

Facade

Definition
UML diagram
Participants

Structural code in C#
Real-world code in C#
.NET Optimized code in C#

Definition

Provide a unified interface to a set of interfaces in a subsystem. Façade defines a higher-level interface that makes the subsystem easier to use.

Frequency of use:

High

UML class diagram

Participants

The classes and objects participating in this pattern are:
- Facade (MortgageApplication)
  - knows which subsystem classes are responsible for a request.
  - delegates client requests to appropriate subsystem objects.
- Subsystem classes (Bank, Credit, Loan)
  - implement subsystem functionality.
  - handle work assigned by the Facade object.
  - have no knowledge of the facade and keep no reference to it.
Structural code in C#

This structural code demonstrates the Facade pattern which provides a simplified and uniform interface to a large subsystem of classes.
3. using System;
5. namespace DoFactory.GangOfFour.Facade.Structural
6. {
7. /// <summary>
8. /// MainApp startup class for Structural
9. /// Facade Design Pattern.
10. /// </summary>
11. class MainApp
12. {
13. /// <summary>
14. /// Entry point into console application.
15. /// </summary>
16. public static void Main()
17. {
18. Facade facade = new Facade();
20. facade.MethodA();
21. facade.MethodB();
23. // Wait for user
24. Console.ReadKey();
25. }
26. }
28. /// <summary>
29. /// The ‘Subsystem ClassA’ class
30. /// </summary>
31. class SubSystemOne
32. {
33. public void MethodOne()
34. {
35. Console.WriteLine(” SubSystemOne Method”);
36. }
37. }
39. /// <summary>
40. /// The ‘Subsystem ClassB’ class
41. /// </summary>
42. class SubSystemTwo
43. {
44. public void MethodTwo()
45. {
46. Console.WriteLine(” SubSystemTwo Method”);
47. }
48. }
50. /// <summary>
51. /// The ‘Subsystem ClassC’ class
52. /// </summary>
53. class SubSystemThree
54. {
55. public void MethodThree()
56. {
57. Console.WriteLine(” SubSystemThree Method”);
58. }
59. }
61. /// <summary>
62. /// The ‘Subsystem ClassD’ class
63. /// </summary>
64. class SubSystemFour
65. {
66. public void MethodFour()
67. {
68. Console.WriteLine(” SubSystemFour Method”);
69. }
70. }
72. /// <summary>
73. /// The ‘Facade’ class
74. /// </summary>
75. class Facade
76. {
77. private SubSystemOne _one;
78. private SubSystemTwo _two;
79. private SubSystemThree _three;
80. private SubSystemFour _four;
82. public Facade()
83. {
84. _one = new SubSystemOne();
85. _two = new SubSystemTwo();
86. _three = new SubSystemThree();
87. _four = new SubSystemFour();
88. }
90. public void MethodA()
91. {
92. Console.WriteLine(“\nMethodA() —- “);
93. _one.MethodOne();
94. _two.MethodTwo();
95. _four.MethodFour();
96. }
98. public void MethodB()
99. {
100. Console.WriteLine(“\nMethodB() —- “);
101. _two.MethodTwo();
102. _three.MethodThree();
103. }
104. }
105. }
Output

MethodA() —-
SubSystemOne Method
SubSystemTwo Method
SubSystemFour Method

MethodB() —-
SubSystemTwo Method
SubSystemThree Method

Real-world code in C#

This real-world code demonstrates the Facade pattern as a MortgageApplication object which provides a simplified interface to a large subsystem of classes measuring the creditworthyness of an applicant.
3. using System;
5. namespace DoFactory.GangOfFour.Facade.RealWorld
6. {
7. /// <summary>
8. /// MainApp startup class for Real-World
9. /// Facade Design Pattern.
10. /// </summary>
11. class MainApp
12. {
13. /// <summary>
14. /// Entry point into console application.
15. /// </summary>
16. static void Main()
17. {
18. // Facade
19. Mortgage mortgage = new Mortgage();
21. // Evaluate mortgage eligibility for customer
22. Customer customer = new Customer(“Ann McKinsey”);
23. bool eligible = mortgage.IsEligible(customer, 125000);
25. Console.WriteLine(“\n” + customer.Name +
26. ” has been “ + (eligible ? “Approved” : “Rejected”));
28. // Wait for user
29. Console.ReadKey();
30. }
31. }
33. /// <summary>
34. /// The ‘Subsystem ClassA’ class
35. /// </summary>
36. class Bank
37. {
38. public bool HasSufficientSavings(Customer c, int amount)
39. {
40. Console.WriteLine(“Check bank for “ + c.Name);
41. return true;
42. }
43. }
45. /// <summary>
46. /// The ‘Subsystem ClassB’ class
47. /// </summary>
48. class Credit
49. {
50. public bool HasGoodCredit(Customer c)
51. {
52. Console.WriteLine(“Check credit for “ + c.Name);
53. return true;
54. }
55. }
57. /// <summary>
58. /// The ‘Subsystem ClassC’ class
59. /// </summary>
60. class Loan
61. {
62. public bool HasNoBadLoans(Customer c)
63. {
64. Console.WriteLine(“Check loans for “ + c.Name);
65. return true;
66. }
67. }
69. /// <summary>
70. /// Customer class
71. /// </summary>
72. class Customer
73. {
74. private string _name;
76. // Constructor
77. public Customer(string name)
78. {
79. this._name = name;
80. }
82. // Gets the name
83. public string Name
84. {
85. get { return _name; }
86. }
87. }
89. /// <summary>
90. /// The ‘Facade’ class
91. /// </summary>
92. class Mortgage
93. {
94. private Bank _bank = new Bank();
95. private Loan _loan = new Loan();
96. private Credit _credit = new Credit();
98. public bool IsEligible(Customer cust, int amount)
99. {
100. Console.WriteLine(“{0} applies for {1:C} loan\n”,
101. cust.Name, amount);
103. bool eligible = true;
105. // Check creditworthyness of applicant
106. if (!_bank.HasSufficientSavings(cust, amount))
107. {
108. eligible = false;
109. }
110. else if (!_loan.HasNoBadLoans(cust))
111. {
112. eligible = false;
113. }
114. else if (!_credit.HasGoodCredit(cust))
115. {
116. eligible = false;
117. }
119. return eligible;
120. }
121. }
122. }
Output

Ann McKinsey applies for $125,000.00 loan

Check bank for Ann McKinsey
Check loans for Ann McKinsey
Check credit for Ann McKinsey

Ann McKinsey has been Approved

Credits:
http://www.dotnet-tricks.com/Tutorial/designpatterns/1N4c140713-Facade-Design-Pattern—C#.html
http://www.dofactory.com/net/facade-design-pattern

About IIS Application Pool, recycle app pool and Session Timeout

Leave a reply

The smps.log can sometimes report sporadic errors indicating that it may have lost a connection to a server running a SiteMinder WebAgent:

[4280/5660][Wed Nov 05 2014 08:32:30][CServer.cpp:2283][ERROR][sm-Server-01090] Failed to receive request on session # 185 : <hostname>/<IP Address>:<Port>. Socket error 10053

If this error is occurring in the smps.log, you can check the webagent log of the server where the webagent is installed. This can be found by using the <hostname> reported in the smps.log error. The webagent log will have a correlating timestamp at or near the time of the Socket error reported in the smps.log.

NOTE: You should also keep in mind that the “Date Modified” timestamp of the webagent log can sometimes be different because once the webagent is stopped and restarted, a new log is only created once a request is made for a resource under the default website within IIS7. If this is an environment where the usage is low, there could be a different between when the error is reported in the smps.log on the policy server and when the webagent is restarted.

One way to confirm that the “Idle Time-Out” threshold is being reached in the DefaultAppPool in IIS7 is to check the Windows Event Viewer. You will also find that the System Log is reporting the following message:

event_viewer1

event_viewer2

Information about Event ID 5186 can be found at: http://technet.microsoft.com/en-us/library/cc735034(v=ws.10).aspx

Information about configuring Idle Time-out settings can be found at: http://technet.microsoft.com/en-us/library/cc771956(v=ws.10).aspx

By default, IIS7 sets application pools to “time-out” after 20 minutes of inactivity. If you do not have any activity to your site within 20 minutes the application pool will shut down – freeing up those system resources. By doing this, the webagent tied to the default application pool will also be shut down. Then the next time a request comes into the site IIS7 will automatically restart the application pool and serve up the requested pages and in turn, start the webagent. It will also mean that the first request – the one that causes the application pool to restart will be very slow. This is a result of the process starting, loading the required assemblies (like .NET) and finally loading the requested pages.

To extend the length of the time-out setting, simply change it from the default of 20 (minutes) to the value you choose. You can also adjust the setting to 0 (zero) which effectively disables the timeout so that the application pool will never shut down due to being idle.

To make this change, open Server Manager -> Expand the Roles -> Expand the Web Server (IIS) node. Then click on the Web Server (IIS) node -> Expand the node with your local server name and click on the Application Pools icon. You will then see a list of the application pools that are defined on your server. In the right-hand pane click the option for Advanced Settings.Source: http://bradkingsley.com/iis7-application-pool-idle-time-out-settings/

Restart IIS7 once the changes have been made. NOTE: When restarting IIS7, open Task Manager and make sure that the LLAWP.exe process fully terminates before starting IIS7.

DefaultAppPool1

After making the changes and IIS7 has been restarted, monitor the smps.log and the webagent logs to verify changes have taken effect.

———————————————————————————————————————————————————-

Why is the IIS default app pool recycle set to 1740 minutes?

Microsoft IIS Server has what appears to be an odd default for the application pool recycle time. It defaults to 1740 minutes, which is exactly 29 hours. I’ve always been a bit curious where that default came from. If you’re like me, you may have wondered too.

Wonder no longer! While at the MVP Summit this year in Bellevue WA I had the privilege again of talking with the IIS team. Wade Hilmo was there too. Somehow in the conversation a discussion about IIS default settings came up, which included the odd 1740 minutes for the app pool recycle interval. Wade told the story of how the setting came into being, and he granted me permission to share.

As you can imagine, many decisions for the large set of products produced by Microsoft come about after a lot of deliberation and research. Others have a geeky and fun origin. This is one of the latter.

The 1740 story

Back when IIS 6 was being developed—which is the version that introduced application pools—a default needed to be set for the Regular Time Interval when application pools are automatically recycled.

Wade suggested 29 hours for the simple reason that it’s the smallest prime number over 24. He wanted a staggered and non-repeating pattern that doesn’t occur more frequently than once per day. In Wade’s words: “you don’t get a resonate pattern”. The default has been 1740 minutes (29 hours) ever since!

That’s a fun little tidbit on the origin of the 1740. How about in your environment though? What is a good default?

Practical guidelines

First off, I think 29 hours is a good default. For a situation where you don’t know the environment, which is the case for a default setting, having a non-resonate pattern greater than one day is a good idea.

However, since you likely know your environment, it’s best to change this. I recommendsetting to a fixed time like 4:00am if you’re on the East coast of the US, 1:00am on the West coast, or whatever seems to make sense for your audience when you have the least amount of traffic. Setting it to a fixed time each day during low traffic times will minimize the impact and also allow you to troubleshoot easier if you run into any issues. If you have multiple application pools it may be wise to stagger them so that you don’t overload the server with a lot of simultaneous recycles.

Note that IIS overlaps the app pool when recycling so there usually isn’t any downtime during a recycle. However, in-memory information (session state, etc) is lost. See this video if you want to learn more about IIS overlapping app pools.

You may ask whether a fixed recycle is even needed. A daily recycle is just a band-aid to freshen IIS in case there is a slight memory leak or anything else that slowly creeps into the worker process. In theory you don’t need a daily recycle unless you have a known problem. I used to recommend that you turn it off completely if you don’t need it. However, I’m leaning more today towards setting it to recycle once per day at an off-peak time as a proactive measure.

My reason is that, first, your site should be able to survive a recycle without too much impact, so recycling daily shouldn’t be a concern. Secondly, I’ve found that even well behaving app pools can eventually have something sneak in over time that impacts the app pool. I’ve seen issues from traffic patterns that cause excessive caching or something odd in the application, and I’ve seen the very rare IIS bug (rare indeed!) that isn’t a problem if recycled daily. Is it a band-aid? Possibly, but if a daily recycle keeps a non-critical issue from bubbling to the top then I believe that it’s a good proactive measure to save a lot of troubleshooting effort on something that probably isn’t important to troubleshoot. However, if you think you have a real issue that is being suppressed by recycling then, by all means, turn off the auto-recycling so that you can track down and resolve your issue. There’s no black and white answer. Only you can make the best decision for your environment.

Idle Time-out

While on the topic of app pool defaults, there is one more that you should change with every new server deployment. The Idle Time-out should be set to 0 unless you are doing bulk hosting where you want to keep the memory footprint per site as low as possible.

If you have a just a few sites on your server and you want them to always load fast then set this to zero. Otherwise, when you have 20 minutes without any traffic then the app pool will terminate so that it can start up again on the next visit. The problem is that the first visit to an app pool needs to create a new w3wp.exe worker process which is slow because the app pool needs to be created, ASP.NET or another framework needs to be loaded, and then your application needs to be loaded. That can take a few seconds. Therefore I set that to 0 every chance I have, unless it’s for a server that hosts a lot of sites that don’t always need to be running.

There are other settings that can be reviewed for each environment but the two aforementioned settings are the two that should be changed almost every time.

Hopefully you enjoyed knowing about the 29 hour default as much as I did, even if just for fun. Happy IISing.

Credits:

Clients

http://weblogs.asp.net/owscott/why-is-the-iis-default-app-pool-recycle-set-to-1740-minutes

Contention, poor performance, and deadlocks when you make calls to Web services from an ASP.NET application

Symptoms

When you make calls to Web services from a Microsoft ASP.NET application, you may experience contention, poor performance, and deadlocks. Clients may report that requests stop responding (or “hang”) or take a very long time to execute. If a deadlock is suspected, the worker process may be recycled. You may receive the following messages in the application event log.

If you are using Internet Information Services (IIS) 5.0, you receive the following messages in the Application log:

   Event Type:     Error
   Event Source:   ASP.NET 1.0.3705.0
   Event Category: None
   Event ID:       1003
   Date:           5/4/2003
   Time:           6:18:23 PM
   User:           N/A
   Computer:       <ComputerName>
   Description:
      aspnet_wp.exe  (PID: <xxx>) was recycled because it was suspected to be in a deadlocked state.
      It did not send any responses for pending requests in the last 180 seconds.

If you are using IIS 6.0, you receive the following messages in the Application log:

   Event Type:     Warning
   Event Source:   W3SVC-WP
   Event Category: None
   Event ID:       2262
   Date:           5/4/2003
   Time:           1:02:33 PM
   User:           N/A
   Computer:       <ComputerName>
   Description:
      ISAPI 'C:\Windows\Microsoft.net\Framework\v.1.1.4322\aspnet_isapi.dll' reported itself as
      unhealthy for the following reason: 'Deadlock detected'.

If you are using IIS 6.0, you receive the following messages in the System log:

   Event Type:     Warning
   Event Source:   W3SVC
   Event Category: None
   Event ID:       1013
   Date:           5/4/2003
   Time:           1:03:47 PM
   User:           N/A
   Computer:       <ComputerName>
   Description:
      A process serving application pool 'DefaultAppPool' exceeded time limits during shut down.
      The process id was '<xxxx>'.

You may also receive the following exception error message when you make a call to the HttpWebRequest.GetResponse method:

“System.InvalidOperationException: There were not enough free threads in the ThreadPool object to complete the operation.”

You may also receive the following exception error message in the browser:

“HttpException (0x80004005): Request timed out.”

Note This article also applies to applications that make HttpWebRequest requests directly.

Cause

This problem might occur because ASP.NET limits the number of worker threads and completion port threads that a call can use to execute requests.

Typically, a call to a Web service uses one worker thread to execute the code that sends the request and one completion port thread to receive the callback from the Web service. However, if the request is redirected or requires authentication, the call may use as many as two worker threads and two completion port threads. Therefore, you can exhaust the managed ThreadPool when multiple Web service calls occur at the same time.

For example, suppose that the ThreadPool is limited to 10 worker threads and that all 10 worker threads are currently executing code that is waiting for a callback to execute. The callback can never execute, because any work items that are queued to the ThreadPool are blocked until a thread becomes available.

Another potential source of contention is the maxconnection parameter that the System.Net namespace uses to limit the number of connections. Generally, this limit works as expected. However, if many applications try to make many requests to a single IP address at the same time, threads may have to wait for an available connection.

Resolution

To resolve these problems, you can tune the following parameters in the Machine.config file to best fit your situation:

maxWorkerThreads
minWorkerThreads
maxIoThreads
minFreeThreads
minLocalRequestFreeThreads
maxconnection
executionTimeout

To successfully resolve these problems, take the following actions:

Limit the number of ASP.NET requests that can execute at the same time to approximately 12 per CPU.
Permit Web service callbacks to freely use threads in the ThreadPool.
Select an appropriate value for the maxconnections parameter. Base your selection on the number of IP addresses and AppDomains that are used.

Note The recommendation to limit the number of ASP.NET requests to 12 per CPU is a little arbitrary. However, this limit has proved to work well for most applications.

maxWorkerThreads and maxIoThreads

ASP.NET uses the following two configuration settings to limit the maximum number of worker threads and completion threads that are used:

<processModel maxWorkerThreads="20" maxIoThreads="20">

The maxWorkerThreads parameter and the maxIoThreads parameter are implicitly multiplied by the number of CPUs. For example, if you have two processors, the maximum number of worker threads is the following:

2*maxWorkerThreads

minFreeThreads and minLocalRequestFreeThreads

ASP.NET also contains the following configuration settings that determine how many worker threads and completion port threads must be available to start a remote request or a local request:

<httpRuntime minFreeThreads="8" minLocalRequestFreeThreads="8">

If there are not sufficient threads available, the request is queued until sufficient threads are free to make the request. Therefore, ASP.NET will not execute more than the following number of requests at the same time:

(maxWorkerThreads*number of CPUs)-minFreeThreads

Note The minFreeThreads parameter and the minLocalRequestFreeThreads parameter are not implicitly multiplied by the number of CPUs.

minWorkerThreads

As of ASP.NET 1.0 Service Pack 3 and ASP.NET 1.1, ASP.NET also contains the following configuration setting that determines how many worker threads may be made available immediately to service a remote request.

<processModel minWorkerThreads="1">

Threads that are controlled by this setting can be created at a much faster rate than worker threads that are created from the CLR’s default “thread-tuning” capabilities. This setting enables ASP.NET to service requests that may be suddenly filling the ASP.NET request queue due to a slow-down on a back end server, a sudden burst of requests from the client end, or something similar that would cause a sudden rise in the number of requests in the queue. The default value for the minWorkerThreads parameter is 1. We recommend that you set the value for the minWorkerThreads parameter to the following value.

minWorkerThreads = maxWorkerThreads / 2

By default, the minWorkerThreads parameter is not present in either the Web.config file or the Machine.config file. This setting is implicitly multiplied by the number of CPUs.

maxconnection

The maxconnection parameter determines how many connections can be made to a specific IP address. The parameter appears as follows:

<connectionManagement>
    <add address="*" maxconnection="2">
    <add address="http://65.53.32.230" maxconnection="12">
</connectionManagement>

If the application’s code references the application by hostname instead of IP address, the parameter should appear as follows:

<connectionManagement>
    <add address="*" maxconnection="2">
    <add address="http://hostname" maxconnection="12">
</connectionManagement>

Finally, if the application is hosted on a port other than 80, the parameter has to include the non-standard port in the URI, similar to the following:

<connectionManagement>
    <add address="*" maxconnection="2">
    <add address="http://hostname:8080" maxconnection="12">
</connectionManagement>

The settings for the parameters that are discussed earlier in this article are all at the process level. However, the maxconnection parameter setting applies to the AppDomain level. By default, because this setting applies to the AppDomain level, you can create a maximum of two connections to a specific IP address from each AppDomain in your process.

executionTimeout

ASP.NET uses the following configuration setting to limit the request execution time:

<httpRuntime executionTimeout="90"/>

You can also set this limit by using the Server.ScriptTimeout property.

Note If you increase the value of the executionTimeout parameter, you may also have to modify the processModel responseDeadlockInterval parameter setting.

Recommendations

The settings that are recommended in this section may not work for all applications. However, the following additional information may help you to make the appropriate adjustments.

If you are making one Web service call to a single IP address from each ASPX page, Microsoft recommends that you use the following configuration settings:

Set the values of the maxWorkerThreads parameter and the maxIoThreads parameter to 100.
Set the value of the maxconnection parameter to 12*N (where N is the number of CPUs that you have).
Set the values of the minFreeThreads parameter to 88*N and the minLocalRequestFreeThreads parameter to76*N.
Set the value of minWorkerThreads to 50. Remember, minWorkerThreads is not in the configuration file by default. You must add it.

Some of these recommendations involve a simple formula that involves the number of CPUs on a server. The variable that represents the number of CPUs in the formulas is N. For these settings, if you have hyperthreading enabled, you must use the number of logical CPUs instead of the number of physical CPUs. For example, if you have a four-processor server with hyperthreading enabled, then the value of N in the formulas will be 8 instead of 4.

Note When you use this configuration, you can execute a maximum of 12 ASP.NET requests per CPU at the same time because 100-88=12. Therefore, at least 88*N worker threads and 88*N completion port threads are available for other uses (such as for the Web service callbacks).

For example, you have a server with four processors and hyperthreading enabled. Based on these formulas, you would use the following values for the configuration settings that are mentioned in this article.

<system.web>
	<processModel maxWorkerThreads="100" maxIoThreads="100" minWorkerThreads="50"/>
	<httpRuntime minFreeThreads="704" minLocalRequestFreeThreads="608"/>
</system.web>

<system.net>
	<connectionManagement>
		<add address="[ProvideIPHere]" maxconnection="96"/>
	</connectionManagement>
</system.net>

Also, when you use this configuration, 12 connections are available per CPU per IP address for each AppDomain. Therefore, in the following scenario, very little contention occurs when requests are waiting for connections, and the ThreadPool is not exhausted:

The web hosts only one application (AppDomain).
Each request for an ASPX page makes one Web service request.
All requests are to the same IP address.

However, when you use this configuration, scenarios that involve one of the following will probably use too many connections:

Requests are to multiple IP addresses.
Requests are redirected (302 status code).
Requests require authentication.
Requests are made from multiple AppDomains.

In these scenarios, it is a good idea to use a lower value for the maxconnection parameter and higher values for the minFreeThreads parameter and theminLocalRequestFreeThreads parameter.

Credits:
https://support.microsoft.com/en-us/kb/821268

.NET and ADO.NET Data Service Performance Tips for Windows Azure Tables

We have collected the common issues that users have come across while using Windows Azure Table and posted some solutions. Some of these are .NET related or ADO.NET Data Services (aka Astoria) related. If you have alternate solutions, please let us know. If you feel we have missed something important, please let us know and we would like to cover them. We hope that the list helps 🙂

1> Default .NET HTTP connections is set to 2
This is a notorious one that has affected many developers. By default, the value for this is 2. This implies that only 2 concurrent connections can be maintained. This manifests itself as “underlying connection was closed…” when the number of concurrent requests is greater than 2. The default can be increased by setting the following in the application configuration file OR in code.

Config file:

<system.net>

</connectionManagement>

</system.net>

In code:

ServicePointManager.DefaultConnectionLimit = 48;

The exact number depends on your application. http://support.microsoft.com/kb/821268 has good information on how to set this for server side applications.

One can also set it for a particular uri by specifying the URI in place of “*”. If you are setting it in code, you could use the ServicePoint class rather than the ServicePointManager class i.e.:

ServicePoint myServicePoint = ServicePointManager.FindServicePoint(myServiceUri);
myServicePoint.ConnectionLimit = 48.

2> Turn off 100-continue (saves 1 roundtrip)
What is 100-continue? When a client sends a POST/PUT request, it can delay sending the payload by sending an “Expect: 100-continue” header.

The server will use the URI plus headers to ensure that the call can be made.
2. The server would then send back a response with status code 100 (Continue) to the client.
3. The client would send the rest of the payload.

This allows the client to be notified of most errors without incurring the cost of sending that entire payload. However, once the entire payload is received on the server end, other errors may still occur. When using .NET library, HttpWebRequest by default sends “Expect: 100-Continue” for all PUT/POST requests (even though MSDN suggests that it does so only for POSTS).

In Windows Azure Tables/Blobs/Queue, some of the failures that can be tested just by receiving the headers and URI are authentication, unsupported verbs, missing headers, etc. If Windows Azure clients have tested the client well enough to ensure that it is not sending any bad requests, clients could turn off 100-continue so that the entire request is sent in one roundtrip. This is especially true when clients send small payloads as in the table or queue service. This setting can be turned off in code or via a configuration setting.

Code:

ServicePointManager.Expect100Continue = false; // or on service point if only a particular service needs to be disabled.

Config file:

<system.net>

</settings>

</system.net>

Before turning 100-continue off, we recommend that you profile your application examining the effects with and without it.

3> To improve performance of ADO.NET Data Service deserialization
When you execute a query using ADO .Net data services, there are two important names – the name of the CLR class for the entity, and the name of the table in Windows Azure Table. We have noticed that when these names are different, there is a fixed overhead of approximately 8-15ms for deserializing each entity received in a query.

There are two workarounds until this is fixed in Astoria:

1> Rename your table to be the same as the class name.
So if you have a Customer entity class, use “Customer” as the table name instead of “Customers”.

from customer in context.CreateQuery<Customer>(“Customer”)

where a.PartitionKey == “Microsoft” select customer;

2> Use ResolveType on the DataServiceContext

public void Query(DataServiceContext context)

{

// set the ResolveType to a method that will return the appropriate type to create

context.ResolveType = this.ResolveEntityType;

…

}

public Type ResolveEntityType(string name)

{

// if the context handles just one type, you can return it without checking the

// value of “name”. Otherwise, check for the name and return the appropriate

// type (maybe a map of Dictionary<string, Type> will be useful)

Type type = typeof(Customer);

return type;

}

4> Turn entity tracking off for query results that are not going to be modified
DataServiceContext has a property MergeOption which can be set to AppendOnly, OverwriteChanges, PreserveChanges and NoTracking. The default is AppendOnly. All options except NoTracking lead to the context tracking the entities. Tracking is mandatory for updates/inserts/deletes. However, not all applications need to modify the entities that are returned from a query, so there really is no need to have change tracking on. The benefit is that Astoria need not do the extra work to track these entities. Turning off entity tracking allows the garbage collector to free up these objects even if the same DataContext is used for other queries. Entity tracking can be turned off by using:

context.MergeOption = MergeOption.NoTracking;

However, when using a context for updates/inserts/deletes, tracking has to be turned on and one would use PreseveChanges to ensure that etags are always updated for the entities.

5> All about unconditional updates/deletes
ETags can be viewed as a version for entities. These can be used for concurrency checks using the If-Match header during updates/deletes. Astoria maintains this etag which is sentETags can be viewed as a version for entities. These can be used for concurrency checks using the If-Match header during updates/deletes. Astoria maintains this etag which is sent with every entity entry in the payload. To get into more details, Astoria tracks entities in the context via context.Entities which is a collection of EntityDescriptors. EntityDescriptor has an “Etag” property that Astoria maintains. On every update/delete the ETag is sent to the server. Astoria by default sends the mandatory “If-Match” header with this etag value. On the server side, Windows Azure table ensures that the etag sent in the If-Match header matches our Timestamp property in the data store. If it matches, the server goes ahead and performs the update/delete; otherwise the server returns a status code of 412 i.e. Precondition failed, indicating that someone else may have modified the entity being updated/deleted. If a client sends “*” in the “If-Match” header, it tells the server that an unconditional update/delete needs to be performed i.e. go ahead and perform the requested operation irrespective of whether someone has changed the entity in the store. A client can send unconditional updates/deletes using the following code:

context.AttachTo(“TableName”, entity, “*”);

context.UpdateObject(entity);

However, if this entity is already being tracked, client will be required to detach the entity before attaching it:

context.Detach(entity);

Added on April 28th 2009
6> Turning off Nagle may help Inserts/Updates

We have seen that turning nagle off has provided significant boost to latencies for inserts and updates in table. However, turning nagle off is known to adversely affect throughput and hence it should be tested for your application to see if it makes a difference.

This can be turned off either in the configuration file or in code as below.

Code:

ServicePointManager.UseNagleAlgorithm = false;

Config file:

<system.net>

</settings>

</system.net>

Credits:
https://social.msdn.microsoft.com/Forums/azure/en-US/d84ba34b-b0e0-4961-a167-bbe7618beb83/net-and-adonet-data-service-performance-tips-for-windows-azure-tables?forum=windowsazuredata

HTML Doctypes

Leave a reply

A Document Type Declaration, or DOCTYPE, is an instruction to the Web browser about the version of markup language in which a page is written.

HTML5 Doctype

A DOCTYPE declaration appears at the top of a web page before all other elements. According to the HTML specification or standards, every HTML document requires a document type declaration to insure that your pages are displayed the way they are intended to be displayed. The doctype declaration is usually the very first thing defined in an HTML document; however the doctype declaration itself is not an HTML tag.

The DOCTYPE for HTML5 is very short, and case-insensitive.

<!DOCTYPE html>

Doctypes from earlier versions of HTML were longer because the HTML language was SGML-based and therefore required a reference to a DTD, but they are obsolete now. With HTML5 this is no longer the case and the doctype declaration is only needed to enable the standard mode for documents written using the HTML syntax.

You can use the following markup as a template to create a new HTML5 document that uses the latest HTML5 doctype declaration.

Example

Try this code »

<!DOCTYPE html>
<html lang="en">
<head>
<title></title>
</head>
<body>

</body>
</html>

Note:The doctype declaration refers to a Document Type Definition (DTD). It is an instruction to the web browser about what version of the markup language the page is written in. The W3C provides DTDs for all HTML versions.

HTML 4.01 Different Doctypes

The following section contains the different doctypes from the previous version of HTML. Although using the HTML 4.01 doctypes are still a valid way to create DOCTYPE declaration, but they are no longer considered a best practice.

HTML 4.01 Strict

The HTML 4.01 Strict DTD includes all elements and attributes that have not been deprecatedor do not appear in frameset documents. For documents that use this DTD, use the following DOCTYPE declaration:

<!DOCTYPE HTML PUBLIC “-//W3C//DTD HTML 4.01//EN”
“http://www.w3.org/TR/html4/strict.dtd”>

HTML 4.01 Transitional

The HTML 4.01 Transitional DTD includes everything in the strict DTD as well as deprecatedelements and attributes but excludes the frameset content. For documents that use this DTD, use the following DOCTYPE declaration:

<!DOCTYPE HTML PUBLIC “-//W3C//DTD HTML 4.01 Transitional//EN” “http://www.w3.org/TR/html4/loose.dtd”>

HTML 4.01 Frameset

The HTML 4.01 Frameset DTD includes everything in the transitional DTD, as well as also allows the use of frameset content. For documents that use this DTD, use the following DOCTYPE declaration:

<!DOCTYPE HTML PUBLIC “-//W3C//DTD HTML 4.01 Frameset//EN” “http://www.w3.org/TR/html4/frameset.dtd”>

Warning:The <frameset> and <frame> elements has been removed from HTML5 and should no longer be used. Therefore, frameset DTD is no longer valid.

XHTML 1.1 Doctype

XHTML 1.1 is the most current finalized revision of XHTML 1.0 Strict, introducing support forXHTML Modularization, which means that you can add modules (for example, to provide Ruby support for Chinese, Japanese, and Korean characters).

For documents that use this DTD, use the following DOCTYPE declaration:

<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML Basic 1.1//EN” “http://www.w3.org/TR/xhtml-basic/xhtml-basic11.dtd”>

Tip:Must add a doctype to your HTML/XHTML document and use the W3C’s Validator to check the markup or syntax error before publishing online.

Source credits: http://www.tutorialrepublic.com/html-tutorial/html-doctypes.php

::before and ::after selectors in css

Leave a reply

Summary

The CSS ::after pseudo-element matches a virtual last child of the selected element. Typically used to add cosmetic content to an element, by using the content CSS property. This element is inline by default.

Syntax

How to read CSS syntax.

element:after  { style properties }  /* CSS2 syntax */

element::after { style properties }  /* CSS3 syntax */

The ::after notation was introduced in CSS 3 in order to establish a discrimination between pseudo-classes and pseudo-elements. Browsers also accept the notation :after introduced in CSS 2.

Examples

Simple usage

Let’s create two classes, one for boring paragraphs and one for exciting ones. We can then mark each paragraph by adding a pseudo-element to the end of it.

<p class="boring-text">Here is some good old boring text.</p>
<p>Here is some moderate text that is neither boring nor exciting.</p>
<p class="exciting-text">Contributing to MDN is easy and fun.
Just hit the edit button to add new live samples, or improve existing samples.</p>

.exciting-text::after {

   content:    "<- now this *is* exciting!"; 
   color:      green;
}

.boring-text::after {
   content:    "<- BORING!";
   color:      red;
}

Output

https://mdn.mozillademos.org/en-US/docs/Web/CSS/::after$samples/Simple_usage?revision=691383

Decorative example

We can style text or images in the content property almost any way we want.

<span class="ribbon">Notice where the orange box is.</span>

.ribbon {
   background-color: #5BC8F7;
}

.ribbon::after {
   content:          "Look at this orange box.";
   background-color: #FFBA10;
   border-color:     black;
   border-style:     dotted;
}

Output

https://mdn.mozillademos.org/en-US/docs/Web/CSS/::after$samples/Decorative_example?revision=691383

Tooltips

The following example shows the use of the ::after pseudo-element in conjunction with the attr()CSS expression and a data-descr custom data attribute to create a pure-CSS, glossary-like tooltip. Checkout the live preview below, or you can see this example in a separate page.

<p>Here is the live example of the above code.<br />
  We have some <span data-descr="collection of words and punctuation">text</span> here with a few
  <span data-descr="small popups which also hide again">tooltips</span>.<br />
  Dont be shy, hover over to take a <span data-descr="not to be taken literally">look</span>.
</p>

    span[data-descr] {
        position: relative;
        text-decoration: underline;
        color: #00F;
        cursor: help;
    }

    span[data-descr]:hover::after {
        content: attr(data-descr);
        position: absolute;
        left: 0;
        top: 24px;
        min-width: 200px;
        border: 1px #aaaaaa solid;
        border-radius: 10px;
        background-color: #ffffcc;
        padding: 12px;
        color: #000000;
        font-size: 14px;
        z-index: 1;
    }

Output

https://mdn.mozillademos.org/en-US/docs/Web/CSS/::after$samples/Tooltips?revision=691383

::after is a pseudo element which allows you to insert content onto a page from CSS (without it needing to be in the HTML). While the end result is not actually in the DOM, it appears on the page as if it is, and would essentially be like this:

div::after {
  content: "hi";
}

<div>
  <!-- Rest of stuff inside the div -->
  hi
</div>

::before is exactly the same only it inserts the content before any other content in the HTML instead of after. The only reasons to use one over the other are:

You want the generated content to come before the element content, positionally.
The ::after content is also “after” in source-order, so it will position on top of ::before if stacked on top of each other naturally.

The value for content can be:

A string: content: "a string"; – special characters need to be specially encoded as a unicode entity. See the glyphs page.
An image: content: url(/path/to/image.jpg); – The image is inserted at it’s exact dimensions and cannot be resized. Since things like gradients are actually images, a pseudo element can be a gradient.
Nothing: content: “”; – Useful for clearfix and inserting images as background-images (set width and height, and can even resize with background-size).
A counter: content: counter(li); – Really useful for styling lists until :marker comes along.

Note that you cannot insert HTML (at least, that will be rendered as HTML). content: "<h1>nope</h1>";

: vs ::

Every browser that supports the double colon (::) CSS3 syntax also supports just the (:) syntax, but IE 8 only supports the single-colon, so for now, it’s recommended to just use the single-colon for best browser support.

:: is the newer format indented to distinguish pseudo content from pseudo selectors. If you don’t need IE 8 support, feel free to use the double-colon.

Source Credits:

::before / ::after

https://developer.mozilla.org/en-US/docs/Web/CSS/::after

CSS Selectors

Leave a reply

It explains How to use different signs (+,> and ~) in CSS selector and their differences. Before starting, let us take a sample code to understand the signs.

<div id="container">           
   <p>First</p>
    <div>
        <p>Child Paragraph</p>
    </div>
   <p>Second</p>
   <p>Third</p>      
</div>

div#container p{
font-weight:bold;
}

It is the descendant selector. It will target all p tags within container div.

> Sign:

It will target elements which are DIRECT children of a particular element.

div#container > p {
  border: 1px solid black;
}

Understand +, > and ~ symbols in CSS Selector

It will target all P element which are direct children of container div, not children of child div.

+ Sign:

It is Adjacent sibling combinator. It combines two sequences of simple selectors having the same parent and the second one must come IMMEDIATELY after the first.

div + p {  
   color: green;  
} 

css%20selector%203 Understand +, > and ~ symbols in CSS Selector

It will only select the first element that is immediately preceded by the former selector. In our example, it will target to Second ONLY because the owner P element comes just after Div tag.

~ Sign:

It is general sibling combinator and similar to Adjacent sibling combinator. the difference is that the second selector does NOT have to immediately follow the first one means It will select all elements that is preceded by the former selector.

div ~ p{
background-color:blue;
} 

css%20selector%204 Understand +, > and ~ symbols in CSS Selector

It will target both second and third.

@ Symbol in css:
These are all known in CSS as at-rules. They’re special instructions for the browser, not directly related to styling of (X)HTML/XML elements in Web documents using rules and properties, although they do play important roles in controlling how styles are applied.

/* Import another stylesheet from within a stylesheet */
@import url(style2.css);

/* Apply this style only for printing */
@media print {
    body {
        color: #000;
        background: #fff;
    }
}

/* Embed a custom web font */
@font-face {
    font-family: 'DejaVu Sans';
    src: local('DejaVu Sans Regular'), url(/fonts/DejaVuSans.ttf);
}

@font-face rules define custom fonts for use in your designs that aren’t always available on all computers, so a browser downloads a font from the server and sets text in that custom font as if the user’s computer had the font.
@media rules, in conjunction with media queries (formerly only media types), control which styles are applied and which aren’t based on what media the page is being displayed in. In my code example, only when printing a document should all text be set in black against a white (the paper) background. You can use media queries to filter out print media, mobile devices and so on, and style pages differently for those.

At-rules have no relation to selectors whatsoever. Because of their varying nature, different at-rules are defined in different ways across numerous different modules. More examples include:

An example of @media that might be useful to illustrate it further:

@media screen and (max-width: 1440px)
{
    span.sizedImage
    {
        height:135px;
        width: 174px;
    }
}    

@media screen and (min-width: 1441px)
{
    span.sizedImage
    {
        height:150px;
        width: 200px;
    }
}

This will vary the size of the image conditionally on the size of the screen, using a smaller image on a smaller screen. The first block would address screens up to width 1440px; the second would address screens larger than 1440px.

This comes in handy with things like tabs that float drop or scroll on smaller screens; you can often drop the font size of the tab labels down a point size on smaller screens and have them all fit.

So you learned the base id, class, and descendant selectors – and then called it a day? If so, you’re missing out on an enormous level of flexibility. While many of the selectors mentioned in this article are part of the CSS3 spec, and are, consequently, only available in modern browsers, you owe it to yourself to commit these to memory.

1. *

* {
 margin: 0;
 padding: 0;
}

Let’s knock the obvious ones out, for the beginners, before we move onto the more advanced selectors.

The star symbol will target every single element on the page. Many developers will use this trick to zero out the margins and padding. While this is certainly fine for quick tests, I’d advise you to never use this in production code. It adds too muchweight on the browser, and is unnecessary.

The * can also be used with child selectors.

#container * {
 border: 1px solid black;
}

This will target every single element that is a child of the #container div. Again, try not to use this technique very much, if ever.

GET	Retrieves a Resource
POST	Updates a Resource: if you are requesting the server to update one or more subordinates of the specified resource. Creates Resource = POST if you are sending a command to the server to create a subordinate of the specified resource, using some server-side algorithm.
PUT	Creates a Resource. Use PUT if you are sending the full content of the specified resource (URL). Update a Resource = PUT iff you are updating the full content of the specified resource.
DELETE	Deletes a Resource.

Intro to SOLID principles

S: Single Responsibility Principle (SRP)

O: Open/Closed Principle

L: Liskov Substitution Principle

I: Interface Segregation Principle (ISP)

D: Dependency Inversion Principle

Rate this:

Share this:

What is dependency Injection?

How Dependency Injection works in Spring:

Inversion of Control (IOC)

Two types of Dependency Injection:

1. Constructor-based dependency injection:

2. Setter-based dependency injection:

Constructor injection

Setter Injection

Rate this:

Share this:

Rate this:

Share this:

What is Singleton Pattern?

Singleton Pattern – UML Diagram & Implementation

Singleton

C# – Implementation Code

Singleton Pattern – Example

Who is what?

C# – Sample Code

Singleton Pattern Demo – Output

When to use it?

Singleton

Definition

UML class diagram

Participants

Structural code in C#

Output

Real-world code in C#

Output

.NET Optimized code in C#

Output

Rate this:

Share this:

What is facade Pattern

Facade Pattern – UML Diagram & Implementation

Complex System

SubsystemA, SubsystemB, SubsystemC

Façade

Client

C# – Implementation Code

Façade Pattern – Example

Who is what?

C# – Sample Code

facade Pattern Demo – Output

When to use it?

Facade

Definition

UML class diagram

Participants

Structural code in C#

Output

Real-world code in C#

Output

Rate this:

Share this:

Why is the IIS default app pool recycle set to 1740 minutes?

Contention, poor performance, and deadlocks when you make calls to Web services from an ASP.NET application

Symptoms

Cause

Resolution

maxWorkerThreads and maxIoThreads

minFreeThreads and minLocalRequestFreeThreads

minWorkerThreads

maxconnection

executionTimeout

Recommendations

Credits: https://support.microsoft.com/en-us/kb/821268

.NET and ADO.NET Data Service Performance Tips for Windows Azure Tables

Rate this:

Share this:

HTML5 Doctype

Example

Credits:
https://support.microsoft.com/en-us/kb/821268