1- Lend a helping hand. With millions of visitors every month, Google has become an essential part of everyday life - like a good friend - connecting people with the information they need to live great lives.
2- Life is beautiful. Being a part of something that matters and working on products in which you can believe is remarkably fulfilling.
3- Appreciation is the best motivation, so we’ve created a fun and inspiring workspace you’ll be glad to be a part of, including on-site doctor and dentist; massage and yoga; professional development opportunities; shoreline running trails; and plenty of snacks to get you through the day.
4- Work and play are not mutually exclusive. It is possible to code and pass the puck at the same time.
5- We love our employees, and we want them to know it. Google offers a variety of benefits, including a choice of medical programs, company-matched 401(k), stock options, maternity and paternity leave, and much more.
6- Innovation is our bloodline. Even the best technology can be improved. We see endless opportunity to create even more relevant, more useful, and faster products for our users. Google is the technology leader in organizing the world’s information.
7- Good company everywhere you look. Googlers range from former neurosurgeons, CEOs, and U.S. puzzle champions to alligator wrestlers and Marines. No matter what their backgrounds Googlers make for interesting cube mates.
8- Uniting the world, one user at a time. People in every country and every language use our products. As such we think, act, and work globally - just our little contribution to making the world a better place.
9- Boldly go where no one has gone before. There are hundreds of challenges yet to solve. Your creative ideas matter here and are worth exploring. You’ll have the opportunity to develop innovative new products that millions of people will find useful.
10- There is such a thing as a free lunch after all. In fact we have them every day: healthy, yummy, and made with love.
Wednesday, April 29, 2009
Wednesday, April 22, 2009
Populating WinForm Controls with ADO.NET
This tutorial will show you three example of populating a WinForm control with database-sourced data. In each example the same control will be used (a combo box), it will display customer name data pulled from a simple table in a fictitious Sales database stored in MS SQL2000.
The table is called ‘Customer’, and has the following fields:
Table: Customer
CustomerID an int which is an Identity field (an automatic sequential number)
FirstName a varchar(30)
LastName a varchar(30)
The simple aim is to display all customer names from this table in a combo box.
Possible Design Choices
There are basically two possible designs with ADO.NET. The simplest is to use a DataReader. DataReaders act much like a forward-only Recordset in ADO. We would sequentially read in the customer names, adding them to the combo box as the reading occurs. Another possibility is to use a DataSet. Think of a DataSet as an in-memory relational database. We create a DataSet that mirrors the portion of the database we are interested in, and use that to populate the combo-box. The advantage of this approach is that as soon as we have loaded the data we require we can close the database connection. The DataSet can then be used disconnected from the database, saving connection resources. The downside is of course that all the data and associated relational structure is held in memory. The appropriate resource trade-off will depend on your application. This tutorial will show examples of both approaches, first using a DataReader, and then using a DataSet. It will then show a third example that also uses a DataSet, but instead of populating the combo-box from the DataSet via code, it binds the combo-box directly to a DataTable object inside the DataSet.
ADO.NET Providers
For this example it would have been easy to use either OLEDB Provider, or the SQLServer provider. Since the target database was SQL2000, these examples will use the SQLServer provider. You will need to add this using clause to your code for these examples to work:
using System.Data.SqlClient;
Using a DataReader to Populate a Combo-box
Imagine we have a combo-box cboReaderBox, and a button called PopulateReaderBox that we want to use to populate that box. The code for the button Click handler would be as follows:
private void btnPopulateReaderBox_Click(object sender, System.EventArgs e)
{
//Connect to the Sales database
//Read in each of the Customers from the Customer table,
//Adding their name to the Combo box
//Do this using a DataReader - much like a forward only ADO cursor.
//declare these outside the try so we can close them off in the
//finally clause.
SqlDataReader oReader = null;
SqlConnection oConnection = null;
try
{
//ensure the box is cleared
cboReaderBox.Items.Clear();
//Use the SQLServer provider..
//set up the connection and the command...
oConnection = new
SqlConnection("server=localhost;uid=sa;pwd=;database=Sales");
string sSelectSQL = "SELECT FirstName +
' ' + LastName as Name FROM Customer";
SqlCommand oCommand = new SqlCommand(sSelectSQL,oConnection);
//open the connection, and use the reader to populate the combobox
oConnection.Open();
oReader = oCommand.ExecuteReader();
if (oReader != null)
{
while (oReader.Read())
{
cboReaderBox.Items.Add(oReader["Name"]);
}
}
//the finally clause will tidy up for us.
cboReaderBox.SelectedIndex = 0;
}
catch (Exception oE)
{
MessageBox.Show("Problem Populating Reader Box:
[" + oE.ToString() + "]");
}
finally
{
if (oReader!=null) oReader.Close();
if (oConnection!= null)
{
if (oConnection.State == ConnectionState.Open)
oConnection.Close();
}
}
}
This code does the following things:
1. Sets up a connection to the database
2. Sets up the command (a SELECT) ready to run
3. Opens a DataReader (like a forward-only record set) on that connection and command
4. Loops through the rows that get returned by the reader, adding the ‘Name’ column to the combo-box’s Item collection.
5. There is a try-catch-finally structure here just to add robustness, you don’t necessarily need this to get the code to work, but I like error handling.
Using a DataSet to Populate a Combo-box
Here is the code to populate another combo-box (cboDatasetBox) with the same data, but this time from an in-memory copy the database or DataSet.
private void btnPopulateDatasetBox_Click(object sender, System.EventArgs e)
{
//Connect to the Sales database
//Read in all of the Customers from the Customer table
// into a Dataset (an in-memory relational
//database.
//Run through this dataset, adding their names to the combobox.
//We can blow away the dataset at that point.
//declare these outside the try so we can close them off in the finally clause.
SqlConnection oConnection = null;
DataSet oCustomersDataSet = new DataSet();
try
{
//ensure the box is cleared
cboDatasetBox.Items.Clear();
//set up the connection
oConnection = new
SqlConnection("server=localhost;uid=sa;pwd=;database=Sales");
//set up the data adapter to get us our data...
//Adapters xfer data to/from Database and Dataset.
SqlDataAdapter oDataAdapter = new
SqlDataAdapter();
string sCommand = "SELECT FirstName + ' ' +
LastName as Name FROM Customer";
oDataAdapter.SelectCommand = new
SqlCommand(sCommand,oConnection);
//use the data adapter to fill the dataset with the result
// of that SQL statement
//Note we have 'changed' the table name so that in memory we run
// off the BoxCustomers
//'table'...just to make the point that we are working off a
// construct of our own devising.
oDataAdapter.Fill(oCustomersDataSet,"BoxCustomers");
//can now close the database connection, we'll work off the dataset
// which is in memory.
oConnection.Close();
//we are now disconnected.
//put the data from the dataset into the combobox
DataTable oDataTable = oCustomersDataSet.Tables["BoxCustomers"];
if (oDataTable == null)
throw new Exception("BoxCustomers table not
found in oCustomersDataSet.");
foreach (DataRow oRow in oDataTable.Rows)
{
cboDatasetBox.Items.Add(oRow["Name"]);
}
//the finally clause will tidy up for us.
cboDatasetBox.SelectedIndex = 0;
}
catch (Exception oE)
{
MessageBox.Show("Problem Populating Dataset Box:
[" + oE.ToString() + "]");
}
finally
{
//clear the inmemory data in the dataset, and close the database
// connection, if it's open.
if (oCustomersDataSet != null) oCustomersDataSet.Clear();
if (oConnection!= null)
{
if (oConnection.State == ConnectionState.Open)
oConnection.Close();
}
}
}
There are a few differences from the DataReader example:
1. It uses a DataAdapter. DataAdapters are the objects that handle communication between the database itself and your in-memory DataSet. We use this DataAdapter to ‘Fill()’ the DataSet with the results of our SELECT statement. The DataSet will then contain an in-memory version of the database Customer table.
2. Just to make the point that we don’t need the database anymore, the second parameter of the Fill() method specifies what to call the new in-memory table. I decided to call it ‘BoxCustomers’. In other respects it is identical to the actual Customers table in the database.
3. Notice we Close() the Connection to the database once the Fill() is done. With the data in memory, we no longer need the database.
4. DataSets can contain whole databases, so to populate the combo-box we explicitly specify the DataTable object pertaining to our new BoxCustomers in-memory table. We use this DataTable object to populate the combo-box.
Binding a Combo-box to a DataTable
With the table loaded into memory, we have a third option, which is to Bind the combo-box directly to that DataTable. The code for this is identical to the second example above, except:
1. Instead of foreach-ing through the DataRows in the DataTable, we simply:
cboBoundSetBox.DataSource = oDataTable;
cboBoundSetBox.DisplayMember = "Name";
2. Add the end (in the finally clause), we don’t Clear() the DataSet, as we would lose the data in the Table we have bound to the combo-box, thus emptying the combo-box again (except for any selected item)!
This tutorial will show you three example of populating a WinForm control with database-sourced data. In each example the same control will be used (a combo box), it will display customer name data pulled from a simple table in a fictitious Sales database stored in MS SQL2000.
The table is called ‘Customer’, and has the following fields:
Table: Customer
CustomerID an int which is an Identity field (an automatic sequential number)
FirstName a varchar(30)
LastName a varchar(30)
The simple aim is to display all customer names from this table in a combo box.
Possible Design Choices
There are basically two possible designs with ADO.NET. The simplest is to use a DataReader. DataReaders act much like a forward-only Recordset in ADO. We would sequentially read in the customer names, adding them to the combo box as the reading occurs. Another possibility is to use a DataSet. Think of a DataSet as an in-memory relational database. We create a DataSet that mirrors the portion of the database we are interested in, and use that to populate the combo-box. The advantage of this approach is that as soon as we have loaded the data we require we can close the database connection. The DataSet can then be used disconnected from the database, saving connection resources. The downside is of course that all the data and associated relational structure is held in memory. The appropriate resource trade-off will depend on your application. This tutorial will show examples of both approaches, first using a DataReader, and then using a DataSet. It will then show a third example that also uses a DataSet, but instead of populating the combo-box from the DataSet via code, it binds the combo-box directly to a DataTable object inside the DataSet.
ADO.NET Providers
For this example it would have been easy to use either OLEDB Provider, or the SQLServer provider. Since the target database was SQL2000, these examples will use the SQLServer provider. You will need to add this using clause to your code for these examples to work:
using System.Data.SqlClient;
Using a DataReader to Populate a Combo-box
Imagine we have a combo-box cboReaderBox, and a button called PopulateReaderBox that we want to use to populate that box. The code for the button Click handler would be as follows:
private void btnPopulateReaderBox_Click(object sender, System.EventArgs e)
{
//Connect to the Sales database
//Read in each of the Customers from the Customer table,
//Adding their name to the Combo box
//Do this using a DataReader - much like a forward only ADO cursor.
//declare these outside the try so we can close them off in the
//finally clause.
SqlDataReader oReader = null;
SqlConnection oConnection = null;
try
{
//ensure the box is cleared
cboReaderBox.Items.Clear();
//Use the SQLServer provider..
//set up the connection and the command...
oConnection = new
SqlConnection("server=localhost;uid=sa;pwd=;database=Sales");
string sSelectSQL = "SELECT FirstName +
' ' + LastName as Name FROM Customer";
SqlCommand oCommand = new SqlCommand(sSelectSQL,oConnection);
//open the connection, and use the reader to populate the combobox
oConnection.Open();
oReader = oCommand.ExecuteReader();
if (oReader != null)
{
while (oReader.Read())
{
cboReaderBox.Items.Add(oReader["Name"]);
}
}
//the finally clause will tidy up for us.
cboReaderBox.SelectedIndex = 0;
}
catch (Exception oE)
{
MessageBox.Show("Problem Populating Reader Box:
[" + oE.ToString() + "]");
}
finally
{
if (oReader!=null) oReader.Close();
if (oConnection!= null)
{
if (oConnection.State == ConnectionState.Open)
oConnection.Close();
}
}
}
This code does the following things:
1. Sets up a connection to the database
2. Sets up the command (a SELECT) ready to run
3. Opens a DataReader (like a forward-only record set) on that connection and command
4. Loops through the rows that get returned by the reader, adding the ‘Name’ column to the combo-box’s Item collection.
5. There is a try-catch-finally structure here just to add robustness, you don’t necessarily need this to get the code to work, but I like error handling.
Using a DataSet to Populate a Combo-box
Here is the code to populate another combo-box (cboDatasetBox) with the same data, but this time from an in-memory copy the database or DataSet.
private void btnPopulateDatasetBox_Click(object sender, System.EventArgs e)
{
//Connect to the Sales database
//Read in all of the Customers from the Customer table
// into a Dataset (an in-memory relational
//database.
//Run through this dataset, adding their names to the combobox.
//We can blow away the dataset at that point.
//declare these outside the try so we can close them off in the finally clause.
SqlConnection oConnection = null;
DataSet oCustomersDataSet = new DataSet();
try
{
//ensure the box is cleared
cboDatasetBox.Items.Clear();
//set up the connection
oConnection = new
SqlConnection("server=localhost;uid=sa;pwd=;database=Sales");
//set up the data adapter to get us our data...
//Adapters xfer data to/from Database and Dataset.
SqlDataAdapter oDataAdapter = new
SqlDataAdapter();
string sCommand = "SELECT FirstName + ' ' +
LastName as Name FROM Customer";
oDataAdapter.SelectCommand = new
SqlCommand(sCommand,oConnection);
//use the data adapter to fill the dataset with the result
// of that SQL statement
//Note we have 'changed' the table name so that in memory we run
// off the BoxCustomers
//'table'...just to make the point that we are working off a
// construct of our own devising.
oDataAdapter.Fill(oCustomersDataSet,"BoxCustomers");
//can now close the database connection, we'll work off the dataset
// which is in memory.
oConnection.Close();
//we are now disconnected.
//put the data from the dataset into the combobox
DataTable oDataTable = oCustomersDataSet.Tables["BoxCustomers"];
if (oDataTable == null)
throw new Exception("BoxCustomers table not
found in oCustomersDataSet.");
foreach (DataRow oRow in oDataTable.Rows)
{
cboDatasetBox.Items.Add(oRow["Name"]);
}
//the finally clause will tidy up for us.
cboDatasetBox.SelectedIndex = 0;
}
catch (Exception oE)
{
MessageBox.Show("Problem Populating Dataset Box:
[" + oE.ToString() + "]");
}
finally
{
//clear the inmemory data in the dataset, and close the database
// connection, if it's open.
if (oCustomersDataSet != null) oCustomersDataSet.Clear();
if (oConnection!= null)
{
if (oConnection.State == ConnectionState.Open)
oConnection.Close();
}
}
}
There are a few differences from the DataReader example:
1. It uses a DataAdapter. DataAdapters are the objects that handle communication between the database itself and your in-memory DataSet. We use this DataAdapter to ‘Fill()’ the DataSet with the results of our SELECT statement. The DataSet will then contain an in-memory version of the database Customer table.
2. Just to make the point that we don’t need the database anymore, the second parameter of the Fill() method specifies what to call the new in-memory table. I decided to call it ‘BoxCustomers’. In other respects it is identical to the actual Customers table in the database.
3. Notice we Close() the Connection to the database once the Fill() is done. With the data in memory, we no longer need the database.
4. DataSets can contain whole databases, so to populate the combo-box we explicitly specify the DataTable object pertaining to our new BoxCustomers in-memory table. We use this DataTable object to populate the combo-box.
Binding a Combo-box to a DataTable
With the table loaded into memory, we have a third option, which is to Bind the combo-box directly to that DataTable. The code for this is identical to the second example above, except:
1. Instead of foreach-ing through the DataRows in the DataTable, we simply:
cboBoundSetBox.DataSource = oDataTable;
cboBoundSetBox.DisplayMember = "Name";
2. Add the end (in the finally clause), we don’t Clear() the DataSet, as we would lose the data in the Table we have bound to the combo-box, thus emptying the combo-box again (except for any selected item)!
Wednesday, April 15, 2009
Ten Ways To Improve Your Website Conversion Rate
What is a Conversion Rate?
Your conversion rate is a measure of the number of potential customers that go on to buy. In the context of a website, it is usually the percentage of visitors that make a purchase. Many websites concentrate solely on increasing the number of visitors they have, when often they have fairly simple problems with their site that, if solved, would have a huge effect on their conversion rate and improve their site's bottom line at minimal expense.
Improving a website conversion rate can be relatively simple. Here are 10 techniques for doing just that:
10. Make The User's Life Easy
Let's start with something that sounds simple, but apparently is too complex for many companies to get right. The more difficult you make your web site to use, the less people will buy from you.
A well designed website should aim to prevent nobody from buying - to allow 100% of the people who want to buy to do so. So where do they go wrong?
Accessibility Making a site accessible is a legal obligation in many countries. Despite that, inaccessible websites are still being created. That can affect your sales, depending on how inaccessible you are, as visitors find the site impossible to use and go elsewhere (and end up recommending one of your competitors to their friends as well). A fairly typical inaccessible site could be losing 5% of potential sales because of this. (A really inaccessible website could even prevent search engines indexing it, giving a far higher amount of potential lost sales.)
Browsers Many designers only pay attention to Internet Explorer. The justification for this is usually that 99% of the site's users use IE. It never seems to occur to the designers that perhaps the reason they have so few visitors with other browsers is that their site is fundamentally broken - it doesn't work in anything else. Percentages of people not using IE varies from site to site - over 60% of visitors to this site use an alternative browser, for example. The number most often quoted though, is that 80-85% of web users are using IE on Windows, which means that an average site that doesn't work in anything else could easily be losing 15-20% of sales.
Be Bold! What happens when a user decides to buy a product? They add it to a shopping basket. How do they add it? They click a button or link (usually a button). What happens when they can't see the button? They go elsewhere. There are some users who are still uncomfortable scrolling. Having things above the fold is still important. And yet there are still plenty of sites out there with buttons that are too subtle, or don't say the right thing, or are hidden away at the bottom of the page. "Add" is rubbish button text. "Buy" is ok. "Add xxx To Your Basket" is great. "Add xxx to Your Basket" in big letters on a big, bright button, near the top of the page, is even better. Calls to action, like this, don't have to be gaudy or tasteless, but they do have to be obvious and clear. Sites I have worked on where just the call to action was changed have reported anything from a 1% to 30% increase in sales as a result.
Usability If your potential customers want to find out more before they buy, can they? Is it obvious to the user where to go to find the technical specs on your products? Are they online at all? Are they in PDF format? Can users even find your products in the first place? This is probably the most common mistake I see on any website - a complete failure to think of what the user wants and needs, and how they might use a site. Plenty of sites have product pages with a photo and some sales patter - and nothing else. Anything from 1% to 99% of potential sales can be lost through poor usability.
When you combine all of the problems above, it becomes fairly clear how easy it is to have a site perform poorly. Make your site accessible, make sure it is usable, make sure it works in common browsers, and make your calls to action clear and unambiguous, and you should be in a position to start converting the people who want to buy.
9. Be Clear, Open and Honest
If you have a product out of stock, say so. Few things annoy users as much as reading all about a product they are after, adding it to a cart, and starting the checkout process - only to find out the product isn't actually available.
The same applies to pricing - a user might spend $100 on a product, but when they find out the shipping is $100 on top of that, they are unlikely to continue the sale. Showing delivery pricing is tricky business, but not impossible. An Ip to Country database will allow you to work out where a user is from and show them a likely delivery cost, for example. If you can't do that, show delivery prices for the countries most appropriate to you - where your products are most often delivered, or for major world regions.
8. Don't Waste Time
One of the biggest mistakes sites make is asking for too much information. Your conversion process may be sale, or it may be a request for information. Either way, don't waste the user's time asking for things you don't need to know. This is, of course, doubly important when it comes to asking for information the user deems private, and that they don't want to give out without good reason.
You don't need to demand the user's email address before letting them download a PDF. You don't need their phone number when they fill out an email enquiry form. A user may not want to buy from you twice - so why make them create an account so they can buy again later before processing their first order? You can give the user the option to do all of these things by all means, but make sure it's not compulsory.
7. Help The User Trust You
Most people are still cautious when buying online, and rightly so. There are plenty of people you really shouldn't give your credit card information to! It's important to give the potential customer every reason to trust you.
An address - bricks and mortar, not a P.O. Box - is a good start. A phone number, with people answering the phone, also helps. Showing a privacy policy and explaining shipping procedures clearly can also help the user to trust you. If you have a SSL certificate, show the "VeriSign Secured" logo to the user.
Design and content also play a part in trust. A poor design gives off an unprofessional feeling. If a company can't afford a decent website, or won't spend the money on it, how can a user be sure their order will be treated with the importance it deserves? If content is inaccurate or badly written, the same applies - show that you take pride in what you do.
6. Have a Clear Returns Policy
Returns on the web are, and are likely to remain, a major issue for consumers. With a bricks and mortar shop, the customer knows where the shop is and that to return the product they simply have to go back there and explain the problem. With the web, this is more of an issue. This is especially true for clothing (where people cannot try things on before buying).
Users are impressed with sites with a good returns policy and are more likely to buy from them. Have people phone for returns - they can then explain the problem to a real person, which is always a good first step. Free return shipping is usually a good option, if commercially viable. People don't like to pay to return things, especially if it is a mistake by the retailer. Finally, give the user plenty of time to return things. 28 days is fairly common, but if it takes you that long to deliver a product, what use is the return policy? 28 days from the date of delivery is better.
5. Keep the User Informed
When somebody buys something online, they want to know when it's going to arrive at their door. People are impatient, after all. Giving them an estimated delivery date during the checkout process is a good start. Emailing them when their product is dispatched is great. Giving them a tracking number if using a delivery service that supports online tracking is even better. Keep the user informed at every step of the process, before and after sale, about as much as you can.
How will this improve your conversion rate? Leaving the customer happy once they have made a sale means they are more likely to speak favourably about you later. They may even recommend you to their friends and within online communities. They are also far more likely to buy from you again.
Think about it like this - if a salesman is doing their absolute best to help you, and to make your life easy, and answering your questions, you might buy what they were selling. If they completely ignored you after you'd bought from them, how would you feel about them? They might well have undone all the good work they put in, because once you'd completed your purchase they see no immediate value in you. A company that shows it cares about their customers, even after they've finished shopping, will make a user far happier and far more likely to return.
4. Offer Different Payment Options
It might sound obvious, but you should offer the user a reasonable selection of methods of payment. Not everybody has a credit card, and those that do don't always want to use them. You don't have to accept cheques, but when deciding on payment methods, consider alternatives to the usual methods. Make the user's life easy and give them what they want.
3. Improve the Value of Visitors
People that buy from you are doing so because they like what it is they see. If a user adds a product to a basket, show them other things they might like as well. If they are viewing a product, the same applies - show them similar items. While they might not buy the product they first saw, other similar ones may not have issues that put them off the first. Upselling and cross-selling are tried and tested sales techniques, and there is no reason not to use them on the web.
2. Be Memorable
A good site will include information. A poor one is just an online catalogue. Information (articles, advice, reviews and so on) all help the user early in their buying process. Users start with research online, just as they do offline. If you can make contact with the user at that stage of their process, and give a favourable impression, there is a good chance that they will come back and buy from you when they finally decide to make a purchase.
Being memorable, and making sure you stick in the user's mind, is dependant on a lot of factors. You must have a USP (see the next point), and branding is important (no good if your visitors remember why you are great but don't remember your name), as well as the quality of your site and information.
1. Know Your USP
Finally, the most important point of all - your Unique Selling Point (USP). Your USP is what sets you apart from your competition. If a visitor goes to several sites looking for a product, why would they decide to buy from you instead of somewhere else?
Many companies do not know their USP. Almost all companies have one, but not all of them are aware of it. If you are a family run business, that's a potential USP. Great customer service, low prices, products that can't be bought elsewhere, free delivery, great support - all of these are USPs. Tell your users what yours is. Shout it from the proverbial rooftops.
Your conversion rate is a measure of the number of potential customers that go on to buy. In the context of a website, it is usually the percentage of visitors that make a purchase. Many websites concentrate solely on increasing the number of visitors they have, when often they have fairly simple problems with their site that, if solved, would have a huge effect on their conversion rate and improve their site's bottom line at minimal expense.
Improving a website conversion rate can be relatively simple. Here are 10 techniques for doing just that:
10. Make The User's Life Easy
Let's start with something that sounds simple, but apparently is too complex for many companies to get right. The more difficult you make your web site to use, the less people will buy from you.
A well designed website should aim to prevent nobody from buying - to allow 100% of the people who want to buy to do so. So where do they go wrong?
Accessibility Making a site accessible is a legal obligation in many countries. Despite that, inaccessible websites are still being created. That can affect your sales, depending on how inaccessible you are, as visitors find the site impossible to use and go elsewhere (and end up recommending one of your competitors to their friends as well). A fairly typical inaccessible site could be losing 5% of potential sales because of this. (A really inaccessible website could even prevent search engines indexing it, giving a far higher amount of potential lost sales.)
Browsers Many designers only pay attention to Internet Explorer. The justification for this is usually that 99% of the site's users use IE. It never seems to occur to the designers that perhaps the reason they have so few visitors with other browsers is that their site is fundamentally broken - it doesn't work in anything else. Percentages of people not using IE varies from site to site - over 60% of visitors to this site use an alternative browser, for example. The number most often quoted though, is that 80-85% of web users are using IE on Windows, which means that an average site that doesn't work in anything else could easily be losing 15-20% of sales.
Be Bold! What happens when a user decides to buy a product? They add it to a shopping basket. How do they add it? They click a button or link (usually a button). What happens when they can't see the button? They go elsewhere. There are some users who are still uncomfortable scrolling. Having things above the fold is still important. And yet there are still plenty of sites out there with buttons that are too subtle, or don't say the right thing, or are hidden away at the bottom of the page. "Add" is rubbish button text. "Buy" is ok. "Add xxx To Your Basket" is great. "Add xxx to Your Basket" in big letters on a big, bright button, near the top of the page, is even better. Calls to action, like this, don't have to be gaudy or tasteless, but they do have to be obvious and clear. Sites I have worked on where just the call to action was changed have reported anything from a 1% to 30% increase in sales as a result.
Usability If your potential customers want to find out more before they buy, can they? Is it obvious to the user where to go to find the technical specs on your products? Are they online at all? Are they in PDF format? Can users even find your products in the first place? This is probably the most common mistake I see on any website - a complete failure to think of what the user wants and needs, and how they might use a site. Plenty of sites have product pages with a photo and some sales patter - and nothing else. Anything from 1% to 99% of potential sales can be lost through poor usability.
When you combine all of the problems above, it becomes fairly clear how easy it is to have a site perform poorly. Make your site accessible, make sure it is usable, make sure it works in common browsers, and make your calls to action clear and unambiguous, and you should be in a position to start converting the people who want to buy.
9. Be Clear, Open and Honest
If you have a product out of stock, say so. Few things annoy users as much as reading all about a product they are after, adding it to a cart, and starting the checkout process - only to find out the product isn't actually available.
The same applies to pricing - a user might spend $100 on a product, but when they find out the shipping is $100 on top of that, they are unlikely to continue the sale. Showing delivery pricing is tricky business, but not impossible. An Ip to Country database will allow you to work out where a user is from and show them a likely delivery cost, for example. If you can't do that, show delivery prices for the countries most appropriate to you - where your products are most often delivered, or for major world regions.
8. Don't Waste Time
One of the biggest mistakes sites make is asking for too much information. Your conversion process may be sale, or it may be a request for information. Either way, don't waste the user's time asking for things you don't need to know. This is, of course, doubly important when it comes to asking for information the user deems private, and that they don't want to give out without good reason.
You don't need to demand the user's email address before letting them download a PDF. You don't need their phone number when they fill out an email enquiry form. A user may not want to buy from you twice - so why make them create an account so they can buy again later before processing their first order? You can give the user the option to do all of these things by all means, but make sure it's not compulsory.
7. Help The User Trust You
Most people are still cautious when buying online, and rightly so. There are plenty of people you really shouldn't give your credit card information to! It's important to give the potential customer every reason to trust you.
An address - bricks and mortar, not a P.O. Box - is a good start. A phone number, with people answering the phone, also helps. Showing a privacy policy and explaining shipping procedures clearly can also help the user to trust you. If you have a SSL certificate, show the "VeriSign Secured" logo to the user.
Design and content also play a part in trust. A poor design gives off an unprofessional feeling. If a company can't afford a decent website, or won't spend the money on it, how can a user be sure their order will be treated with the importance it deserves? If content is inaccurate or badly written, the same applies - show that you take pride in what you do.
6. Have a Clear Returns Policy
Returns on the web are, and are likely to remain, a major issue for consumers. With a bricks and mortar shop, the customer knows where the shop is and that to return the product they simply have to go back there and explain the problem. With the web, this is more of an issue. This is especially true for clothing (where people cannot try things on before buying).
Users are impressed with sites with a good returns policy and are more likely to buy from them. Have people phone for returns - they can then explain the problem to a real person, which is always a good first step. Free return shipping is usually a good option, if commercially viable. People don't like to pay to return things, especially if it is a mistake by the retailer. Finally, give the user plenty of time to return things. 28 days is fairly common, but if it takes you that long to deliver a product, what use is the return policy? 28 days from the date of delivery is better.
5. Keep the User Informed
When somebody buys something online, they want to know when it's going to arrive at their door. People are impatient, after all. Giving them an estimated delivery date during the checkout process is a good start. Emailing them when their product is dispatched is great. Giving them a tracking number if using a delivery service that supports online tracking is even better. Keep the user informed at every step of the process, before and after sale, about as much as you can.
How will this improve your conversion rate? Leaving the customer happy once they have made a sale means they are more likely to speak favourably about you later. They may even recommend you to their friends and within online communities. They are also far more likely to buy from you again.
Think about it like this - if a salesman is doing their absolute best to help you, and to make your life easy, and answering your questions, you might buy what they were selling. If they completely ignored you after you'd bought from them, how would you feel about them? They might well have undone all the good work they put in, because once you'd completed your purchase they see no immediate value in you. A company that shows it cares about their customers, even after they've finished shopping, will make a user far happier and far more likely to return.
4. Offer Different Payment Options
It might sound obvious, but you should offer the user a reasonable selection of methods of payment. Not everybody has a credit card, and those that do don't always want to use them. You don't have to accept cheques, but when deciding on payment methods, consider alternatives to the usual methods. Make the user's life easy and give them what they want.
3. Improve the Value of Visitors
People that buy from you are doing so because they like what it is they see. If a user adds a product to a basket, show them other things they might like as well. If they are viewing a product, the same applies - show them similar items. While they might not buy the product they first saw, other similar ones may not have issues that put them off the first. Upselling and cross-selling are tried and tested sales techniques, and there is no reason not to use them on the web.
2. Be Memorable
A good site will include information. A poor one is just an online catalogue. Information (articles, advice, reviews and so on) all help the user early in their buying process. Users start with research online, just as they do offline. If you can make contact with the user at that stage of their process, and give a favourable impression, there is a good chance that they will come back and buy from you when they finally decide to make a purchase.
Being memorable, and making sure you stick in the user's mind, is dependant on a lot of factors. You must have a USP (see the next point), and branding is important (no good if your visitors remember why you are great but don't remember your name), as well as the quality of your site and information.
1. Know Your USP
Finally, the most important point of all - your Unique Selling Point (USP). Your USP is what sets you apart from your competition. If a visitor goes to several sites looking for a product, why would they decide to buy from you instead of somewhere else?
Many companies do not know their USP. Almost all companies have one, but not all of them are aware of it. If you are a family run business, that's a potential USP. Great customer service, low prices, products that can't be bought elsewhere, free delivery, great support - all of these are USPs. Tell your users what yours is. Shout it from the proverbial rooftops.
How to Enumerate SQL Server database Instances
How many times you created a .NET application in which you need to know about all of the database systems on your company’s network? May be you need to create an application for database administrator of your SQL Server database so that he can see a list of all the SQL Server databases installed in the company. In this small tutorial I will show you how you can obtain the list of all SQL Server database instances. 
SqlDataSourceEnumerator class in System.Data.Sql namespace provides a mechanism for enumerating all instances of SQL Servers in a given network. This class exposes a method called GetDataSources() that returns a DataTable object containing the list of SQL Servers with some basic information about the server.
Below is a code listing and screen shot of a simple Windows project I built that shows you how to use SqlDataSourceEnumerator class.
private void Form1_Load(object sender, EventArgs e){
//create a new instance of our SqlDataSourceEnumerator SqlDataSourceEnumerator sqlEnumerator = SqlDataSourceEnumerator.Instance;
//get the datatable containing our sql servers DataTable sqlServersTable = sqlEnumerator.GetDataSources();
dataGridView1.DataSource = sqlServersTable;}
List of SQL Server Instances
Please keep in mind following points when you enumerate SQL Servers by using above code:
1. SQL Server Browser service must be running on the client system to obtain the information correctly from SQL Server 2005. 2. Enumerating servers will only find SQL Server 2000 and later versions of the database.
I hope this tutorial will help many of you in the future.
SqlDataSourceEnumerator class in System.Data.Sql namespace provides a mechanism for enumerating all instances of SQL Servers in a given network. This class exposes a method called GetDataSources() that returns a DataTable object containing the list of SQL Servers with some basic information about the server.
Below is a code listing and screen shot of a simple Windows project I built that shows you how to use SqlDataSourceEnumerator class.
private void Form1_Load(object sender, EventArgs e){
//create a new instance of our SqlDataSourceEnumerator SqlDataSourceEnumerator sqlEnumerator = SqlDataSourceEnumerator.Instance;
//get the datatable containing our sql servers DataTable sqlServersTable = sqlEnumerator.GetDataSources();
dataGridView1.DataSource = sqlServersTable;}
List of SQL Server Instances
Please keep in mind following points when you enumerate SQL Servers by using above code:
1. SQL Server Browser service must be running on the client system to obtain the information correctly from SQL Server 2005. 2. Enumerating servers will only find SQL Server 2000 and later versions of the database.
I hope this tutorial will help many of you in the future.
Saturday, April 11, 2009
Programmers and IT failure
IT failures are often rooted in hidden, almost tectonic forces — organizational, political, and so on — that are difficult to measure or control. However, this focus can obscure those special folks who actually create the technology we implement and use. I’m referring to programmers.
At their best, programmers are the dreamers, visionaries, and skilled artisans of technology: the real creators. In the truest sense, these great ones have advanced knowledge and human well-being in science, medicine, and many other important domains.
However, we can also point to unskilled, inexperienced, or self-centered programming behavior as a direct source of project cost overruns and delays on some projects. How many programmer-led initiatives have gone late or over-budget because developers created cool software with scant business value?
Dead Programmer. Your code has survived and transcended your death. You are a part of the permanent historical record of computing. Other programmers study your work and writing. Examples: Dijkstra, Knuth, Kay
Successful Programmer. Programmers who are both well known and have created entire businesses - perhaps even whole industries - around their code. Getting to this level often depends more on business skills than programming. Examples: Gates, Carmack, DHH
Famous Programmer. This is also a good place to be, but not unless you also have a day job. But being famous doesn’t necessarily mean you can turn a profit and support yourself. Famous is good, but successful is better.
Working Programmer. You have a successful career as a software developer. But where do you go from there?
Average Programmer. At this level you are a good enough programmer to realize that you’re not a great programmer. If you are an average programmer but manage to make a living at it then you are talented, just not necessarily at coding.
Amateur Programmer. Being an amateur is a good thing; from this level one can rapidly rise to become a working programmer.
Unknown Programmer. The proverbial typical programmer. Joe Coder. Probably works for a large, anonymous MegaCorp. It’s just a job, not their entire life. Nothing wrong with that, either.
Bad Programmer. People who somehow fell into the programmer role without an iota of skill or ability. These people have no business writing code of any kind - but they do, anyway.
It’s easy to stereotype anyone, placing them on a pedestal or tearing down their contributions as meaningless, although neither extreme provides much value. Having said this, what do you think about the role of programmers in causing or preventing failed IT projects?
Source: http://blogs.techrepublic.com.com/
At their best, programmers are the dreamers, visionaries, and skilled artisans of technology: the real creators. In the truest sense, these great ones have advanced knowledge and human well-being in science, medicine, and many other important domains.
However, we can also point to unskilled, inexperienced, or self-centered programming behavior as a direct source of project cost overruns and delays on some projects. How many programmer-led initiatives have gone late or over-budget because developers created cool software with scant business value?
Dead Programmer. Your code has survived and transcended your death. You are a part of the permanent historical record of computing. Other programmers study your work and writing. Examples: Dijkstra, Knuth, Kay
Successful Programmer. Programmers who are both well known and have created entire businesses - perhaps even whole industries - around their code. Getting to this level often depends more on business skills than programming. Examples: Gates, Carmack, DHH
Famous Programmer. This is also a good place to be, but not unless you also have a day job. But being famous doesn’t necessarily mean you can turn a profit and support yourself. Famous is good, but successful is better.
Working Programmer. You have a successful career as a software developer. But where do you go from there?
Average Programmer. At this level you are a good enough programmer to realize that you’re not a great programmer. If you are an average programmer but manage to make a living at it then you are talented, just not necessarily at coding.
Amateur Programmer. Being an amateur is a good thing; from this level one can rapidly rise to become a working programmer.
Unknown Programmer. The proverbial typical programmer. Joe Coder. Probably works for a large, anonymous MegaCorp. It’s just a job, not their entire life. Nothing wrong with that, either.
Bad Programmer. People who somehow fell into the programmer role without an iota of skill or ability. These people have no business writing code of any kind - but they do, anyway.
It’s easy to stereotype anyone, placing them on a pedestal or tearing down their contributions as meaningless, although neither extreme provides much value. Having said this, what do you think about the role of programmers in causing or preventing failed IT projects?
Source: http://blogs.techrepublic.com.com/
Wednesday, April 8, 2009
10 Tips for Boosting Team Performance
As a Project Manager, your success depends on how well your team performs. So if you want to improve your team performance, then read these:
10 Tips for Boosting Team Performance
There are lots of different ways that you can boost your team performance. We've listed here our Top 10 Tips. We hope they help you...
Tip 1: Show them the vision
People only perform well in a role if they understand what it is that they need to deliver and why. For this reason, we suggest you get your team together to reinforce the project vision, objectives, timeframes and deadlines. Make your team feel wanted and needed by showing them that the project is critical to the success of the business. You will gain their buy-in and their commitment going forward.
Tip 2: Meet them individually
After your meeting, take each team member aside and tell them what it is that you need from them to help you deliver the project. Make sure they have a clear Job Description and they know how you are going to measure their performance. Ask them how they like to be managed, what motivates them and how you can support them in their role.
Tip 3: Give them room
At this point, you need to back off a little and give them room to perform. And if the pressure increases in your project, you need to give them more room than less. It's hard to do this, but you mustn't over-pressurize them or their performance will reduce, rather than improve.
Tip 4: Count the goals
As you back off, you need to put in place checks to measure their performance regularly. Meet with them individually every month to discuss their achievements, what's outstanding and how they can improve. Make sure you don't “bottle up” your concerns. Instead speak to them openly, keeping constructive at all times.
Tip 5: Be positive
If you're stressed and weary, ease off on your staff. Shouting or being negative will only rub off on them. It's incredibly difficult but you need to be positive, reassuring and supporting them at all times, even if the project is delayed.
Tip 6: Shake hands and pat backs
It's easy to forget to praise your team's successes. So every time you deliver a great quality product, finish a difficult task on time or get great feedback from a customer—congratulate those responsible in your team.
Tip 7: Meet at half time
Get your team together regularly to build a strong team spirit. Get them socializing together, so that new friendships are formed. The stronger the bond your team have with each other, the more likely they will work together as a single cohesive unit and achieve the objectives you have set.
Tips 8: Take time out
Don't be afraid to give team members time off for working hard. By taking time out, it will reduce sick leave, improve motivation and increase efficiency.
Tips 9: Give them what they need
Everyone is motivated by different things. You need to know what motivates every different member of your team. Get to know them well. If you can reward each person differently based on their motivations, then you'll improve their performance every time. This is the hardest trick in the book, but the one that pays the biggest dividends.
Tip 10: Celebrate your wins!
Staff all too often finish a project and move straight onto the next one without celebrating its success. When they do this, they carry their stress and pressure into the next project they work on. So help your team to "start afresh" by celebrating your success at the end of the project.
By taking these 10 tips seriously, you will improve the performance of your team and boost your chances of success.
Give your team the right tools to help them complete their work quickly and to a high level of quality. This builds personal pride in their work, improving motivation and performance.
10 Tips for Boosting Team Performance
There are lots of different ways that you can boost your team performance. We've listed here our Top 10 Tips. We hope they help you...
Tip 1: Show them the vision
People only perform well in a role if they understand what it is that they need to deliver and why. For this reason, we suggest you get your team together to reinforce the project vision, objectives, timeframes and deadlines. Make your team feel wanted and needed by showing them that the project is critical to the success of the business. You will gain their buy-in and their commitment going forward.
Tip 2: Meet them individually
After your meeting, take each team member aside and tell them what it is that you need from them to help you deliver the project. Make sure they have a clear Job Description and they know how you are going to measure their performance. Ask them how they like to be managed, what motivates them and how you can support them in their role.
Tip 3: Give them room
At this point, you need to back off a little and give them room to perform. And if the pressure increases in your project, you need to give them more room than less. It's hard to do this, but you mustn't over-pressurize them or their performance will reduce, rather than improve.
Tip 4: Count the goals
As you back off, you need to put in place checks to measure their performance regularly. Meet with them individually every month to discuss their achievements, what's outstanding and how they can improve. Make sure you don't “bottle up” your concerns. Instead speak to them openly, keeping constructive at all times.
Tip 5: Be positive
If you're stressed and weary, ease off on your staff. Shouting or being negative will only rub off on them. It's incredibly difficult but you need to be positive, reassuring and supporting them at all times, even if the project is delayed.
Tip 6: Shake hands and pat backs
It's easy to forget to praise your team's successes. So every time you deliver a great quality product, finish a difficult task on time or get great feedback from a customer—congratulate those responsible in your team.
Tip 7: Meet at half time
Get your team together regularly to build a strong team spirit. Get them socializing together, so that new friendships are formed. The stronger the bond your team have with each other, the more likely they will work together as a single cohesive unit and achieve the objectives you have set.
Tips 8: Take time out
Don't be afraid to give team members time off for working hard. By taking time out, it will reduce sick leave, improve motivation and increase efficiency.
Tips 9: Give them what they need
Everyone is motivated by different things. You need to know what motivates every different member of your team. Get to know them well. If you can reward each person differently based on their motivations, then you'll improve their performance every time. This is the hardest trick in the book, but the one that pays the biggest dividends.
Tip 10: Celebrate your wins!
Staff all too often finish a project and move straight onto the next one without celebrating its success. When they do this, they carry their stress and pressure into the next project they work on. So help your team to "start afresh" by celebrating your success at the end of the project.
By taking these 10 tips seriously, you will improve the performance of your team and boost your chances of success.
Give your team the right tools to help them complete their work quickly and to a high level of quality. This builds personal pride in their work, improving motivation and performance.
10 skills developers will need in the next five years
If you’re a developer looking to get ahead in your field (or in some cases, to simply stay employed), this is not a good time to be complacent. Justin James lists the skills you’ll want to work on now to maximize your future job prospects.
With the recent changes in the economy, a lot of developers are focused on their short-term job prospects. At the same time, it’s important to make sure that you get the most bang for your buck when it comes to taking the time and energy to learn new skills. Here is our list of 10 skills you should be learning right now to make sure that your resume is relevant for the next five years. The list is hardly exhaustive, and there are huge swaths of the industry it won’t cover (mainframe developers, for example). Nonetheless, for average mainstream development, you can’t go wrong learning at least seven of these skills — not only to the point where you can talk convincingly about them at a job interview, but actually use them on the job.
1: One of the “Big Three” (.NET, Java, PHP)
Unless there is a radical shift in the development world (akin to an asteroid hitting Redmond), most developers will need to know at least one of the Big Three development systems — .NET (VB.NET or C#), Java, or PHP — for the near future. It’s not enough to know the core languages, either. As projects encompass more and more disparate functionality, you’ll need to know the associated frameworks and libraries more deeply.
2: Rich Internet Applications (RIAs)
Love it or hate it, in the last few years, Flash is suddenly being used for more than just animations of politicians singing goofy songs. Flash has also sprouted additional functionality in the form or Flex and AIR. Flash’s competitors, such as JavaFx and Silverlight, are also upping the ante on features and performance. To make things even more complicated, HTML 5 is incorporating all sorts of RIA functionality, including database connectivity, and putting the formal W3C stamp on AJAX. In the near future, being an RIA pro will be a key resume differentiator.
3: Web development
Web development is not going away anytime soon. Many developers have been content to lay back and ignore the Web or to just stick to “the basics” their framework provides them with. But companies have been demanding more and more who really know how to work with the underlying technology at a “hand code” level. So bone up on JavaScript, CSS, and HTML to succeed over the next five years.
4: Web services
REST or SOAP? JSON or XML? While the choices and the answers depend on the project, it’s getting increasingly difficult to be a developer (even one not writing Web applications) without consuming or creating a Web service. Even areas that used to be ODBC, COM, or RPC domains are now being transitioned to Web services of some variety. Developers who can’t work with Web services will find themselves relegated to legacy and maintenance roles.
5: Soft skills
One trend that has been going for quite some time is the increasing visibility of IT within and outside the enterprise. Developers are being brought into more and more non-development meetings and processes to provide feedback. For example, the CFO can’t change the accounting rules without working with IT to update the systems. And an operations manager can’t change a call center process without IT updating the CRM workflow. Likewise, customers often need to work directly with the development teams to make sure that their needs are met. Will every developer need to go to Toastmasters or study How to Win Friends and Influence People? No. But the developers who do will be much more valuable to their employers — and highly sought after in the job market.
6: One dynamic and/or functional programming language
Languages like Ruby, Python, F#, and Groovy still aren’t quite mainstream – but the ideas in them are. For example, the LINQ system in Microsoft’s .NET is a direct descendent of functional programming techniques. Both Ruby and Python are becoming hot in some sectors, thanks to the Rails framework and Silverlight, respectively. Learning one of these languages won’t just improve your resume, though; it will expand your horizons. Every top-flight developer I’ve met recommends learning at least one dynamic or functional programming language to learn new ways of thinking, and from personal experience, I can tell you that it works.
7: Agile methodologies
When Agile first hit mainstream awareness, I was a skeptic, along with many other folks I know. It seemed to be some sort of knee-jerk reaction to tradition, throwing away the controls and standards in favor of anarchy. But as time went on, the ideas behind Agile became both better defined and better expressed. Many shops are either adopting Agile or running proof-of-concept experiments with Agile. While Agile is not the ultimate panacea for project failure, it does indeed have a place on many projects. Developers with a proven track record of understanding and succeeding in Agile environments will be in increasingly high demand over the next few years.
8: Domain knowledge
Hand-in-hand with Agile methodologies, development teams are increasingly being viewed as partners in the definition of projects. This means that developers who understand the problem domain are able to contribute to the project in a highly visible, valuable way. With Agile, a developer who can say, “From here, we can also add this functionality fairly easily, and it will get us a lot of value,” or “Gee, that requirement really doesn’t match the usage patterns our logs show” will excel. As much as many developers resist the idea of having to know anything about the problem domain at all, it is undeniable that increasing numbers of organizations prefer (if not require) developers to at least understand the basics.
9: Development “hygiene”
A few years ago, many (if not most) shops did not have access to bug tracking systems, version control, and other such tools; it was just the developers and their IDE of choice. But thanks to the development of new, integrated stacks, like the Microsoft Visual Studio Team System, and the explosion in availability of high quality, open source environments, organizations without these tools are becoming much less common. Developers must know more than just how to check code in and out of source control or how to use the VM system to build test environments. They need to have a rigorous habit of hygiene in place to make sure that they are properly coordinating with their teams. “Code cowboys” who store everything on a personal USB drive, don’t document which changes correspond to which task item, and so on, are unwelcome in more traditional shops and even more unwelcome in Agile environments, which rely on a tight coordination between team members to operate.
10: Mobile development
The late 1990s saw Web development rise to mainstream acceptance and then begin to marginalize traditional desktop applications in many areas. In 2008, mobile development left the launch pad, and over the next five years, it will become increasingly important. There are, of course, different approaches to mobile development: Web applications designed to work on mobile devices, RIAs aimed at that market, and applications that run directly on the devices. Regardless of which of these paths you choose, adding mobile development to your skill set will ensure that you are in demand for the future.
Source: http://blogs.techrepublic.com.com/10things/?p=643
With the recent changes in the economy, a lot of developers are focused on their short-term job prospects. At the same time, it’s important to make sure that you get the most bang for your buck when it comes to taking the time and energy to learn new skills. Here is our list of 10 skills you should be learning right now to make sure that your resume is relevant for the next five years. The list is hardly exhaustive, and there are huge swaths of the industry it won’t cover (mainframe developers, for example). Nonetheless, for average mainstream development, you can’t go wrong learning at least seven of these skills — not only to the point where you can talk convincingly about them at a job interview, but actually use them on the job.
1: One of the “Big Three” (.NET, Java, PHP)
Unless there is a radical shift in the development world (akin to an asteroid hitting Redmond), most developers will need to know at least one of the Big Three development systems — .NET (VB.NET or C#), Java, or PHP — for the near future. It’s not enough to know the core languages, either. As projects encompass more and more disparate functionality, you’ll need to know the associated frameworks and libraries more deeply.
2: Rich Internet Applications (RIAs)
Love it or hate it, in the last few years, Flash is suddenly being used for more than just animations of politicians singing goofy songs. Flash has also sprouted additional functionality in the form or Flex and AIR. Flash’s competitors, such as JavaFx and Silverlight, are also upping the ante on features and performance. To make things even more complicated, HTML 5 is incorporating all sorts of RIA functionality, including database connectivity, and putting the formal W3C stamp on AJAX. In the near future, being an RIA pro will be a key resume differentiator.
3: Web development
Web development is not going away anytime soon. Many developers have been content to lay back and ignore the Web or to just stick to “the basics” their framework provides them with. But companies have been demanding more and more who really know how to work with the underlying technology at a “hand code” level. So bone up on JavaScript, CSS, and HTML to succeed over the next five years.
4: Web services
REST or SOAP? JSON or XML? While the choices and the answers depend on the project, it’s getting increasingly difficult to be a developer (even one not writing Web applications) without consuming or creating a Web service. Even areas that used to be ODBC, COM, or RPC domains are now being transitioned to Web services of some variety. Developers who can’t work with Web services will find themselves relegated to legacy and maintenance roles.
5: Soft skills
One trend that has been going for quite some time is the increasing visibility of IT within and outside the enterprise. Developers are being brought into more and more non-development meetings and processes to provide feedback. For example, the CFO can’t change the accounting rules without working with IT to update the systems. And an operations manager can’t change a call center process without IT updating the CRM workflow. Likewise, customers often need to work directly with the development teams to make sure that their needs are met. Will every developer need to go to Toastmasters or study How to Win Friends and Influence People? No. But the developers who do will be much more valuable to their employers — and highly sought after in the job market.
6: One dynamic and/or functional programming language
Languages like Ruby, Python, F#, and Groovy still aren’t quite mainstream – but the ideas in them are. For example, the LINQ system in Microsoft’s .NET is a direct descendent of functional programming techniques. Both Ruby and Python are becoming hot in some sectors, thanks to the Rails framework and Silverlight, respectively. Learning one of these languages won’t just improve your resume, though; it will expand your horizons. Every top-flight developer I’ve met recommends learning at least one dynamic or functional programming language to learn new ways of thinking, and from personal experience, I can tell you that it works.
7: Agile methodologies
When Agile first hit mainstream awareness, I was a skeptic, along with many other folks I know. It seemed to be some sort of knee-jerk reaction to tradition, throwing away the controls and standards in favor of anarchy. But as time went on, the ideas behind Agile became both better defined and better expressed. Many shops are either adopting Agile or running proof-of-concept experiments with Agile. While Agile is not the ultimate panacea for project failure, it does indeed have a place on many projects. Developers with a proven track record of understanding and succeeding in Agile environments will be in increasingly high demand over the next few years.
8: Domain knowledge
Hand-in-hand with Agile methodologies, development teams are increasingly being viewed as partners in the definition of projects. This means that developers who understand the problem domain are able to contribute to the project in a highly visible, valuable way. With Agile, a developer who can say, “From here, we can also add this functionality fairly easily, and it will get us a lot of value,” or “Gee, that requirement really doesn’t match the usage patterns our logs show” will excel. As much as many developers resist the idea of having to know anything about the problem domain at all, it is undeniable that increasing numbers of organizations prefer (if not require) developers to at least understand the basics.
9: Development “hygiene”
A few years ago, many (if not most) shops did not have access to bug tracking systems, version control, and other such tools; it was just the developers and their IDE of choice. But thanks to the development of new, integrated stacks, like the Microsoft Visual Studio Team System, and the explosion in availability of high quality, open source environments, organizations without these tools are becoming much less common. Developers must know more than just how to check code in and out of source control or how to use the VM system to build test environments. They need to have a rigorous habit of hygiene in place to make sure that they are properly coordinating with their teams. “Code cowboys” who store everything on a personal USB drive, don’t document which changes correspond to which task item, and so on, are unwelcome in more traditional shops and even more unwelcome in Agile environments, which rely on a tight coordination between team members to operate.
10: Mobile development
The late 1990s saw Web development rise to mainstream acceptance and then begin to marginalize traditional desktop applications in many areas. In 2008, mobile development left the launch pad, and over the next five years, it will become increasingly important. There are, of course, different approaches to mobile development: Web applications designed to work on mobile devices, RIAs aimed at that market, and applications that run directly on the devices. Regardless of which of these paths you choose, adding mobile development to your skill set will ensure that you are in demand for the future.
Source: http://blogs.techrepublic.com.com/10things/?p=643
F (Function) - Key Tricks
What the F-key?
See that line of keys ranging from F1 to F12 at the top of your keyboard? Wonder what all of 'em do? Yeah, so do I, and that's why today we're going to take a trip down funky f-key lane to discover the fun of Function Keys!
Function keys have many, many uses, some of which are specific to the program that's running at the time. They're mainly used as shortcuts or in conjunction with the CTRL, ALT, and Shift keys, which I'll get more into in another article.
For now, here are the basics of function keys F1 – F4.
F1- Typically pressing this brings up the help file for the program you're currently in. To test this, go ahead and left click on a blank area of your desktop, then press F1. The help file should spring to life, offering it's bounty of knowledge!
F2 – This F-key is used to rename stuff. Click on a file or folder and strike the F2 key; you'll be able to rename it with ease! This is a good one to know if you're zipping through a bunch of files you're archiving and you have a specific naming convention in mind. Click the file, press F2 and rename it! - wash, rinse, repeat!
F3 – Used to bring up the search function in Windows, but varies for other programs. Great for Internet Explorer and Firefox users who want to find a specific word or phrase on a web page with ease!
F4 – In Internet Explorer the F4 key opens the address bar. Even though I said I wouldn't be mentioning any extra key commands until later, I must mention that pressing ALT + F4 will close any active program. Careful with this one!
Function keys have many, many uses, some of which are specific to the program that's running at the time. They're mainly used as shortcuts or in conjunction with the CTRL, ALT, and Shift keys, which I'll cover in a later article.
Continuing on, here are the basics of function keys F5 – F8.
F5 – Refresh key. Use this key to reload a web page or refresh your desktop. This is a good one for both the Internet (good for Ebay bid battles) and apparent computer freezes which you can read about here.
F6 – Cycles the cursor from field to field in the active program. In MS Word you can use this F-key to go to the next pane or frame.
F7 – This F-key is program-specific. Experiment in different programs to see what it can do, but remember to save your work first!
F8 – This key is used to boot Windows in Safe Mode
Function keys are pretty versatile, but some only have purpose specific to the program that's running at the time. They're mainly used as shortcuts or in conjunction with the CTRL, ALT, and Shift keys. We'll talk about that soon.
For now, here are the basics of function keys F9 – F12.
F9 – Another program-specific function key, I just call it “lazy”, though... Well, if you're using MS Word the F9 key will update the selected field, so that's one thing it can do!
F10 – This key is used to access the Menu Bar in programs (File, Edit, View, Etc.). Good for zapping up there if you need to access some of the menu functions.
F11 – Is used in Internet Explorer to toggle the full screen view, also known as “KIOSK” mode.
F12 – Another “lazy” key, although some individual programs may have functions assigned to it. In MS Word this can be used as the “Save As” command.
See that line of keys ranging from F1 to F12 at the top of your keyboard? Wonder what all of 'em do? Yeah, so do I, and that's why today we're going to take a trip down funky f-key lane to discover the fun of Function Keys!
Function keys have many, many uses, some of which are specific to the program that's running at the time. They're mainly used as shortcuts or in conjunction with the CTRL, ALT, and Shift keys, which I'll get more into in another article.
For now, here are the basics of function keys F1 – F4.
F1- Typically pressing this brings up the help file for the program you're currently in. To test this, go ahead and left click on a blank area of your desktop, then press F1. The help file should spring to life, offering it's bounty of knowledge!
F2 – This F-key is used to rename stuff. Click on a file or folder and strike the F2 key; you'll be able to rename it with ease! This is a good one to know if you're zipping through a bunch of files you're archiving and you have a specific naming convention in mind. Click the file, press F2 and rename it! - wash, rinse, repeat!
F3 – Used to bring up the search function in Windows, but varies for other programs. Great for Internet Explorer and Firefox users who want to find a specific word or phrase on a web page with ease!
F4 – In Internet Explorer the F4 key opens the address bar. Even though I said I wouldn't be mentioning any extra key commands until later, I must mention that pressing ALT + F4 will close any active program. Careful with this one!
Function keys have many, many uses, some of which are specific to the program that's running at the time. They're mainly used as shortcuts or in conjunction with the CTRL, ALT, and Shift keys, which I'll cover in a later article.
Continuing on, here are the basics of function keys F5 – F8.
F5 – Refresh key. Use this key to reload a web page or refresh your desktop. This is a good one for both the Internet (good for Ebay bid battles) and apparent computer freezes which you can read about here.
F6 – Cycles the cursor from field to field in the active program. In MS Word you can use this F-key to go to the next pane or frame.
F7 – This F-key is program-specific. Experiment in different programs to see what it can do, but remember to save your work first!
F8 – This key is used to boot Windows in Safe Mode
Function keys are pretty versatile, but some only have purpose specific to the program that's running at the time. They're mainly used as shortcuts or in conjunction with the CTRL, ALT, and Shift keys. We'll talk about that soon.
For now, here are the basics of function keys F9 – F12.
F9 – Another program-specific function key, I just call it “lazy”, though... Well, if you're using MS Word the F9 key will update the selected field, so that's one thing it can do!
F10 – This key is used to access the Menu Bar in programs (File, Edit, View, Etc.). Good for zapping up there if you need to access some of the menu functions.
F11 – Is used in Internet Explorer to toggle the full screen view, also known as “KIOSK” mode.
F12 – Another “lazy” key, although some individual programs may have functions assigned to it. In MS Word this can be used as the “Save As” command.
Saturday, April 4, 2009
Introduction to Object Oriented Programming Concepts (OOP)
1. Introduction I have noticed an increase in the number of articles published in the Architect category in code-project during the last few months. The number of readers for most of these articles is also high, though the ratings for the articles are not. This indicates that readers are interested in reading articles on Architecture, but the quality does not match their expectations. This article is a constructive attempt to group/ define/ explain all introductory concepts of software architecture for well seasoned developers who are looking to take their next step as system architects.
One day I read an article that said that the richest 2 percent own half the world's wealth. It also said that the richest 1 percent of adults owned 40 percent of global assets in the year 2000. And further, that the richest 10 percent of adults accounted for 85 percent of the world's total wealth. So there is an unbalanced distribution of wealth in the physical world. Have you ever thought of an unbalanced distribution of knowledge in the software world? According to my view point, the massive expansion of the software industry is forcing developers to use already implemented libraries, services and frameworks to develop software within ever shorter periods of time. The new developers are trained to use (I would say more often) already developed software components, to complete the development quicker. They just plug in an existing library and some how manage to achieve the requirements. But the sad part of the story is, that they never get a training to define, design the architecture for, and implement such components. As the number of years pass by, these developers become leads and also software architects. Their titles change, but the old legacy of not understanding, of not having any architectural experience continues, creating a vacuum of good architects. The bottom line is that only a small percentage of developers know how to design a truly object oriented system. The solution to this problem is getting harder every day as the aggressive nature of the software industry does not support an easy adjustment to existing processes, and also the related online teaching materials are either complex or less practical or sometimes even wrong. The most of them use impractical, irrelevant examples of shapes, animals and many other physical world entities to teach concepts of software architecture. There are only very few good business-oriented design references. Unfortunately, I myself am no exception and am a result of this very same system. I got the same education that all of you did, and also referred to the same resource set you all read.
Coming back to the initial point, I noticed that there is a knowledge gap, increasing every day, between the architects who know how to architect a system properly and the others who do not know. The ones, who know, know it right. But the ones, who do not know, know nothing. Just like the world’s wealth distribution, it is an unbalanced distribution of knowledge.
2. Background This article began after reading and hearing the questions new developers have, on basics of software architecture. There are some good articles out there, but still developers struggle to understand the basic concepts, and more importantly, the way to apply them correctly.
As I see it, newcomers will always struggle to understand a precise definition of a new concept, because it is always a new and hence unfamiliar idea. The one, who has experience, understands the meaning, but the one who doesn’t, struggles to understand the very same definition. It is like that. Employers want experienced employees. So they say, you need to have experience to get a job. But how the hell is one supposed to have that experience if no one is willing to give him a job? As in the general case, the start with software architecture is no exception. It will be difficult. When you start to design your very first system, you will try to apply everything you know or learned from everywhere. You will feel that an interface needs to be defined for every class, like I did once. You will find it harder to understand when and when not to do something. Just prepare to go through a painful process. Others will criticize you, may laugh at you and say that the way you have designed it is wrong. Listen to them, and learn continuously. In this process you will also have to read and think a lot. I hope that this article will give you the right start for that long journey.
“The knowledge of the actions of great men, acquired by long experience in contemporary affairs, and a continual study of antiquity” – I read this phrase when I was reading the book named “The Art of War”, seems applicable here, isn’t it?
3. Prerequisites This article is an effort to provide an accurate information pool for new developers on the basics of software architecture, focusing on Object Oriented Programming (OOP). If you are a developer, who has a minimum of three or more years of continuous development experience and has that hunger to learn more, to step-in to the next level to become a software architect, this article is for you.
4. The Main Content
4.1. What is Software Architecture? Software Architecture is defined to be the rules, heuristics and patterns governing:
Partitioning the problem and the system to be built into discrete pieces
Techniques used to create interfaces between these pieces
Techniques used to manage overall structure and flow
Techniques used to interface the system to its environment
Appropriate use of development and delivery approaches, techniques and tools.
4.2. Why Architecture is important?
The primary goal of software architecture is to define the non-functional requirements of a system and define the environment. The detailed design is followed by a definition of how to deliver the functional behavior within the architectural rules. Architecture is important because it:
Controls complexity
Enforces best practices
Gives consistency and uniformity
Increases predictability
Enables re-use.
4.3. What is OOP? OOP is a design philosophy. It stands for Object Oriented Programming. Object-Oriented Programming (OOP) uses a different set of programming languages than old procedural programming languages (C, Pascal, etc.). Everything in OOP is grouped as self sustainable "objects". Hence, you gain re-usability by means of four main object-oriented programming concepts.
In order to clearly understand the object orientation, let’s take your “hand” as an example. The “hand” is a class. Your body has two objects of type hand, named left hand and right hand. Their main functions are controlled/ managed by a set of electrical signals sent through your shoulders (through an interface). So the shoulder is an interface which your body uses to interact with your hands. The hand is a well architected class. The hand is being re-used to create the left hand and the right hand by slightly changing the properties of it.
4.4. What is an Object? An object can be considered a "thing" that can perform a set of related activities. The set of activities that the object performs defines the object's behavior. For example, the hand can grip something or a Student (object) can give the name or address.
In pure OOP terms an object is an instance of a class.
4.5. What is a Class?
A class is simply a representation of a type of object. It is the blueprint/ plan/ template that
describe the details of an object. A class is the blueprint from which the individual objects are created. Class is composed of three things: a name, attributes, and operations.
Collapse Copy Codepublic class Student
{
}
According to the sample given below we can say that the student object, named objectStudent, has created out of the Student class.
Collapse Copy CodeStudent objectStudent = new Student();
In real world, you'll often find many individual objects all of the same kind. As an example, there may be thousands of other bicycles in existence, all of the same make and model. Each bicycle has built from the same blueprint. In object-oriented terms, we say that the bicycle is an instance of the class of objects known as bicycles.
In the software world, though you may not have realized it, you have already used classes. For example, the TextBox control, you always used, is made out of the TextBox class, which defines its appearance and capabilities. Each time you drag a TextBox control, you are actually creating a new instance of the TextBox class.
4.6. How to identify and design a Class?
This is an art; each designer uses different techniques to identify classes. However according to Object Oriented Design Principles, there are five principles that you must follow when design a class,
SRP - The Single Responsibility Principle - A class should have one, and only one, reason to change.
OCP - The Open Closed Principle - You should be able to extend a classes behavior, without modifying it.
LSP - The Liskov Substitution Principle- Derived classes must be substitutable for their base classes.
DIP - The Dependency Inversion Principle- Depend on abstractions, not on concretions.
ISP - The Interface Segregation Principle- Make fine grained interfaces that are client specific.
For more information on design principles, please refer to Object Mentor.
Additionally to identify a class correctly, you need to identify the full list of leaf level functions/ operations of the system (granular level use cases of the system). Then you can proceed to group each function to form classes (classes will group same types of functions/ operations). However a well defined class must be a meaningful grouping of a set of functions and should support the re-usability while increasing expandability/ maintainability of the overall system.
In software world the concept of dividing and conquering is always recommended, if you start analyzing a full system at the start, you will find it harder to manage. So the better approach is to identify the module of the system first and then dig deep in to each module separately to seek out classes.
A software system may consist of many classes. But in any case, when you have many, it needs to be managed. Think of a big organization, with its work force exceeding several thousand employees (let’s take one employee as a one class). In order to manage such a work force, you need to have proper management policies in place. Same technique can be applies to manage classes of your software system as well. In order to manage the classes of a software system, and to reduce the complexity, the system designers use several techniques, which can be grouped under four main concepts named Encapsulation, Abstraction, Inheritance, and Polymorphism. These concepts are the four main gods of OOP world and in software term, they are called four main Object Oriented Programming (OOP) Concepts.
4.7. What is Encapsulation (or information hiding)? The encapsulation is the inclusion within a program object of all the resources need for the object to function - basically, the methods and the data. In OOP the encapsulation is mainly achieved by creating classes, the classes expose public methods and properties. The class is kind of a container or capsule or a cell, which encapsulate the set of methods, attribute and properties to provide its indented functionalities to other classes. In that sense, encapsulation also allows a class to change its internal implementation without hurting the overall functioning of the system. That idea of encapsulation is to hide how a class does it but to allow requesting what to do.
In order to modularize/ define the functionality of a one class, that class can uses functions/ properties exposed by another class in many different ways. According to Object Oriented Programming there are several techniques, classes can use to link with each other and they are named association, aggregation, and composition.
There are several other ways that an encapsulation can be used, as an example we can take the usage of an interface. The interface can be used to hide the information of an implemented class.
Collapse Copy CodeIStudent myStudent = new LocalStudent();
IStudent myStudent = new ForeignStudent();
According to the sample above (let’s assume that LocalStudent and ForeignStudent are implemented by the IStudent interface) we can see how LocalStudent and ForeignStudent are hiding their, localize implementing information through the IStudent interface.
4.8. What is Association? Association is a (*a*) relationship between two classes. It allows one object instance to cause another to perform an action on its behalf. Association is the more general term that define the relationship between two classes, where as the aggregation and composition are relatively special.
Collapse Copy Codepublic class StudentRegistrar
{
public StudentRegistrar ();
{
new RecordManager().Initialize();
}
}
In this case we can say that there is an association between StudentRegistrar and RecordManager or there is a directional association from StudentRegistrar to RecordManager or StudentRegistrar use a (*Use*) RecordManager. Since a direction is explicitly specified, in this case the controller class is the StudentRegistrar.
To some beginners, association is a confusing concept. The troubles created not only by the association alone, but with two other OOP concepts, that is association, aggregation and composition. Every one understands association, before aggregation and composition are described. The aggregation or composition cannot be separately understood. If you understand the aggregation alone it will crack the definition given for association, and if you try to understand the composition alone it will always threaten the definition given for aggregation, all three concepts are closely related, hence must study together, by comparing one definition to another. Let’s explore all three and see whether we can understand the differences between these useful concepts.
4.9. What is the difference between Association, Aggregation and Composition? Association is a (*a*) relationship between two classes, where one class use another. But aggregation describes a special type of an association. Aggregation is the (*the*) relationship between two classes. When object of one class has an (*has*) object of another, if second is a part of first (containment relationship) then we called that there is an aggregation between two classes. Unlike association, aggregation always insists a direction.
Collapse Copy Codepublic class University
{
private Chancellor universityChancellor = new Chancellor();
}
In this case I can say that University aggregate Chancellor or University has an (*has-a*) Chancellor. But even without a Chancellor a University can exists. But a University cannot exist without Faculties, the life time of a University attached with the life time of its Faculty (or Faculties). If Faculties are disposed the University will not exist or wise versa. In that case we called that University is composed of Faculties. So that composition can be recognized as a special type of an aggregation.
Same way, as another example, you can say that, there is a composite relationship in-between a KeyValuePairCollection and a KeyValuePair. The two mutually depend on each other.
.Net and Java uses the Composite relation to define their Collections. I have seen Composition is being used in many other ways too. However the more important factor, that most people forget is the life time factor. The life time of the two classes that has bond with a composite relation mutually depend on each other. If you take the .net Collection to understand this, there you have the Collection Element define inside (it is an inner part, hence called it is composed of) the Collection, farcing the Element to get disposed with the Collection. If not, as an example, if you define the Collection and it’s Element to be independent, then the relationship would be more of a type Aggregation, than a Composition. So the point is, if you want to bind two classes with Composite relation, more accurate way is to have a one define inside the other class (making it a protected or private class). This way you are allowing the outer class to fulfill its purpose, while tying the lifetime of the inner class with the outer class.
So in summary, we can say that aggregation is a special kind of an association and composition is a special kind of an aggregation. (Association->Aggregation->Composition)
4.10. What is Abstraction and Generalization? Abstraction is an emphasis on the idea, qualities and properties rather than the particulars (a suppression of detail). The importance of abstraction is derived from its ability to hide irrelevant details and from the use of names to reference objects. Abstraction is essential in the construction of programs. It places the emphasis on what an object is or does rather than how it is represented or how it works. Thus, it is the primary means of managing complexity in large programs.
While abstraction reduces complexity by hiding irrelevant detail, generalization reduces complexity by replacing multiple entities which perform similar functions with a single construct. Generalization is the broadening of application to encompass a larger domain of objects of the same or different type. Programming languages provide generalization through variables, parameterization, generics and polymorphism. It places the emphasis on the similarities between objects. Thus, it helps to manage complexity by collecting individuals into groups and providing a representative which can be used to specify any individual of the group.
Abstraction and generalization are often used together. Abstracts are generalized through parameterization to provide greater utility. In parameterization, one or more parts of an entity are replaced with a name which is new to the entity. The name is used as a parameter. When the parameterized abstract is invoked, it is invoked with a binding of the parameter to an argument.
4.11. What is an Abstract class? Abstract classes, which declared with the abstract keyword, cannot be instantiated. It can only be used as a super-class for other classes that extend the abstract class. Abstract class is the concept and implementation gets completed when it is being realized by a subclass. In addition to this a class can inherit only from one abstract class (but a class may implement many interfaces) and must override all its abstract methods/ properties and may override virtual methods/ properties.
Abstract classes are ideal when implementing frameworks. As an example, let’s study the abstract class named LoggerBase below. Please carefully read the comments as it will help you to understand the reasoning behind this code.
Collapse Copy Codepublic abstract class LoggerBase
{
///
/// field is private, so it intend to use inside the class only
///
private log4net.ILog logger = null;
///
/// protected, so it only visible for inherited class
///
protected LoggerBase()
{
// The private object is created inside the constructor
logger = log4net.LogManager.GetLogger(this.LogPrefix);
// The additional initialization is done immediately after
log4net.Config.DOMConfigurator.Configure();
}
///
/// When you define the property as abstract,
/// it forces the inherited class to override the LogPrefix
/// So, with the help of this technique the log can be made,
/// inside the abstract class itself, irrespective of it origin.
/// If you study carefully you will find a reason for not to have “set” method here.
///
protected abstract System.Type LogPrefix
{
get;
}
///
/// Simple log method,
/// which is only visible for inherited classes
///
///
protected void LogError(string message)
{
if (this.logger.IsErrorEnabled)
{
this.logger.Error(message);
}
}
///
/// Public properties which exposes to inherited class
/// and all other classes that have access to inherited class
///
public bool IsThisLogError
{
get
{
return this.logger.IsErrorEnabled;
}
}
}The idea of having this class as an abstract is to define a framework for exception logging. This class will allow all subclass to gain access to a common exception logging module and will facilitate to easily replace the logging library. By the time you define the LoggerBase, you wouldn’t have an idea about other modules of the system. But you do have a concept in mind and that is, if a class is going to log an exception, they have to inherit the LoggerBase. In other word the LoggerBase provide a framework for exception logging.
Let’s try to understand each line of the above code.
Like any other class, an abstract class can contain fields, hence I used a private field named logger declare the ILog interface of the famous log4net library. This will allow the Loggerbase class to control, what to use, for logging, hence, will allow changing the source logger library easily.
The access modifier of the constructor of the LoggerBase is protected. The public constructor has no use when the class is of type abstract. The abstract classes are not allowed to instantiate the class. So I went for the protected constructor.
The abstract property named LogPrefix is an important one. It enforces and guarantees to have a value for LogPrefix (LogPrefix uses to obtain the detail of the source class, which the exception has occurred) for every subclass, before they invoke a method to log an error.
The method named LogError is protected, hence exposed to all subclasses. You are not allowed or rather you cannot make it public, as any class, without inheriting the LoggerBase cannot use it meaningfully.
Let’s find out why the property named IsThisLogError is public. It may be important/ useful for other associated classes of an inherited class to know whether the associated member logs its errors or not.
Apart from these you can also have virtual methods defined in an abstract class. The virtual method may have its default implementation, where a subclass can override it when required.
All and all, the important factor here is that all OOP concepts should be used carefully with reasons, you should be able to logically explain, why you make a property a public or a field a private or a class an abstract. Additionally, when architecting frameworks, the OOP concepts can be used to forcefully guide the system to be developed in the way framework architect’s wanted it to be architected initially.
4.12. What is an Interface? In summary the Interface separates the implementation and defines the structure, and this concept is very useful in cases where you need the implementation to be interchangeable. Apart from that an interface is very useful when the implementation changes frequently. Some say you should define all classes in terms of interfaces, but I think recommendation seems a bit extreme.
Interface can be used to define a generic template and then one or more abstract classes to define partial implementations of the interface. Interfaces just specify the method declaration (implicitly public and abstract) and can contain fields and properties (which are also implicitly public and abstract). Interface definition begins with the keyword interface. An interface like that of an abstract class cannot be instantiated.
If a class that implements an interface does not define all the methods of the interface, then it must be declared abstract and the method definitions must be provided by the subclass that extends the abstract class. In addition to this an interfaces can inherit other interfaces.
The sample below will provide an interface for our LoggerBase abstract class.
Collapse Copy Codepublic interface ILogger
{
bool IsThisLogError { get; }
}
4.13. What is the difference between a Class and an Interface? In .Net/ C# a class can be defined to implement an interface and also it supports multiple implementations. When a class implements an interface, an object of such class can be encapsulated inside an interface.
If MyLogger is a class, which implements ILogger, there we can write
Collapse Copy CodeILogger log = new MyLogger();
A class and an interface are two different types (conceptually). Theoretically a class emphasis the idea of encapsulation, while an interface emphasis the idea of abstraction (by suppressing the details of the implementation). The two poses a clear separation from one to another. Therefore it is very difficult or rather impossible to have an effective meaningful comparison between the two, but it is very useful and also meaningful to have a comparison between an interface and an abstract class.
4.14. What is the difference between an Interface and an Abstract class?
There are quite a big difference between an interface and an abstract class, even though both look similar.
Interface definition begins with a keyword interface so it is of type interface
Abstract classes are declared with the abstract keyword so it is of type class
Interface has no implementation, but they have to be implemented.
Abstract class’s methods can have implementations and they have to be extended.
Interfaces can only have method declaration (implicitly public and abstract) and fields (implicitly public static)
Abstract class’s methods can’t have implementation only when declared abstract.
Interface can inherit more than one interfaces
Abstract class can implement more than one interfaces, but can inherit only one class
Abstract class must override all abstract method and may override virtual methods
Interface can be used when the implementation is changing
Abstract class can be used to provide some default behavior for a base class.
Interface makes implementation interchangeable
Interface increase security by hiding the implementation
Abstract class can be used when implementing framework
Abstract classes are an excellent way to create planned inheritance hierarchies and also to use as non-leaf classes in class hierarchies.
Abstract classes let you define some behaviors; they force your subclasses to provide others. For example, if you have an application framework, an abstract class can be used to provide the default implementation of the services and all mandatory modules such as event logging and message handling etc. This approach allows the developers to develop the application within the guided help provided by the framework.
However, in practice when you come across with some application-specific functionality that only your application can perform, such as startup and shutdown tasks etc. The abstract base class can declare virtual shutdown and startup methods. The base class knows that it needs those methods, but an abstract class lets your class admit that it doesn't know how to perform those actions; it only knows that it must initiate the actions. When it is time to start up, the abstract class can call the startup method. When the base class calls this method, it can execute the method defined by the child class.
4.15. What is Implicit and Explicit Interface Implementations?
As mentioned before .Net support multiple implementations, the concept of implicit and explicit implementation provide safe way to implement methods of multiple interfaces by hiding, exposing or preserving identities of each of interface methods, even when the method signatures are the same.
Let's consider the interfaces defined below.
Collapse Copy Codeinterface IDisposable
{
void Dispose();
}
Here you can see that the class Student has implicitly and explicitly implemented the method named Dispose() via Dispose and IDisposable.Dispose.
Collapse Copy Codeclass Student : IDisposable
{
public void Dispose()
{
Console.WriteLine("Student.Dispose");
}
void IDisposable.Dispose()
{
Console.WriteLine("IDisposable.Dispose");
}
}
4.16. What is Inheritance?
Ability of a new class to be created, from an existing class by extending it, is called inheritance.
Collapse Copy Codepublic class Exception
{
}
public class IOException : Exception
{
}
According to the above example the new class (IOException), which is called the derived class or subclass, inherits the members of an existing class (Exception), which is called the base class or super-class. The class IOException can extend the functionality of the class Exception by adding new types and methods and by overriding existing ones.
Just like abstraction is closely related with generalization, the inheritance is closely related with specialization. It is important to discuss those two concepts together with generalization to better understand and to reduce the complexity.
One of the most important relationships among objects in the real world is specialization, which can be described as the “is-a” relationship. When we say that a dog is a mammal, we mean that the dog is a specialized kind of mammal. It has all the characteristics of any mammal (it bears live young, nurses with milk, has hair), but it specializes these characteristics to the familiar characteristics of canis domesticus. A cat is also a mammal. As such, we expect it to share certain characteristics with the dog that are generalized in Mammal, but to differ in those characteristics that are specialized in cats.
The specialization and generalization relationships are both reciprocal and hierarchical. Specialization is just the other side of the generalization coin: Mammal generalizes what is common between dogs and cats, and dogs and cats specialize mammals to their own specific subtypes.
Similarly, as an example you can say that both IOException and SecurityException are of type Exception. They have all characteristics and behaviors of an Exception, That mean the IOException is a specialized kind of Exception. A SecurityException is also an Exception. As such, we expect it to share certain characteristic with IOException that are generalized in Exception, but to differ in those characteristics that are specialized in SecurityExceptions. In other words, Exception generalizes the shared characteristics of both IOException and SecurityException, while IOException and SecurityException specialize with their characteristics and behaviors.
In OOP, the specialization relationship is implemented using the principle called inheritance. This is the most common and most natural and widely accepted way of implement this relationship.
4.17. What is Polymorphisms? Polymorphisms is a generic term that means 'many shapes'. More precisely Polymorphisms means the ability to request that the same operations be performed by a wide range of different types of things.
At times, I used to think that understanding Object Oriented Programming concepts have made it difficult since they have grouped under four main concepts, while each concept is closely related with one another. Hence one has to be extremely careful to correctly understand each concept separately, while understanding the way each related with other concepts.
In OOP the polymorphisms is achieved by using many different techniques named method overloading, operator overloading and method overriding,
4.18. What is Method Overloading? The method overloading is the ability to define several methods all with the same name.
Collapse Copy Codepublic class MyLogger
{
public void LogError(Exception e)
{
// Implementation goes here
}
public bool LogError(Exception e, string message)
{
// Implementation goes here
}
}
4.19. What is Operator Overloading? The operator overloading (less commonly known as ad-hoc polymorphisms) is a specific case of polymorphisms in which some or all of operators like +, - or == are treated as polymorphic functions and as such have different behaviors depending on the types of its arguments.
Collapse Copy Codepublic class Complex
{
private int real;
public int Real
{ get { return real; } }
private int imaginary;
public int Imaginary
{ get { return imaginary; } }
public Complex(int real, int imaginary)
{
this.real = real;
this.imaginary = imaginary;
}
public static Complex operator +(Complex c1, Complex c2)
{
return new Complex(c1.Real + c2.Real, c1.Imaginary + c2.Imaginary);
}
}
I above example I have overloaded the plus operator for adding two complex numbers. There the two properties named Real and Imaginary has been declared exposing only the required “get” method, while the object’s constructor is demanding for mandatory real and imaginary values with the user defined constructor of the class.
4.20. What is Method Overriding? Method overriding is a language feature that allows a subclass to override a specific implementation of a method that is already provided by one of its super-classes.
A subclass can give its own definition of methods but need to have the same signature as the method in its super-class. This means that when overriding a method the subclass's method has to have the same name and parameter list as the super-class's overridden method.
Collapse Copy Codeusing System;
public class Complex
{
private int real;
public int Real
{ get { return real; } }
private int imaginary;
public int Imaginary
{ get { return imaginary; } }
public Complex(int real, int imaginary)
{
this.real = real;
this.imaginary = imaginary;
}
public static Complex operator +(Complex c1, Complex c2)
{
return new Complex(c1.Real + c2.Real, c1.Imaginary + c2.Imaginary);
}
public override string ToString()
{
return (String.Format("{0} + {1}i", real, imaginary));
}
}
In above example I have extended the implementation of the sample Complex class given under operator overloading section. This class has one overridden method named “ToString”, which override the default implementation of the standard “ToString” method to support the correct string conversion of a complex number.
Collapse Copy CodeComplex num1 = new Complex(5, 7);
Complex num2 = new Complex(3, 8);
// Add two Complex numbers using the
// overloaded plus operator
Complex sum = num1 + num2;
// Print the numbers and the sum
// using the overriden ToString method
Console.WriteLine("({0}) + ({1}) = {2}", num1, num2, sum);
Console.ReadLine();
4.21. What is a Use case?
A use case is a thing an actor perceives from the system. A use case maps actors with functions. Importantly, the actors need not be people. As an example a system can perform the role of an actor, when it communicate with another system.
In another angle a use case encodes a typical user interaction with the system. In particular, it:
Captures some user-visible function.
Achieves some concrete goal for the user. A complete set of use cases largely defines the requirements for your system: everything the user can see, and would like to do. The below diagram contains a set of use cases that describes a simple login module of a gaming website.
4.22. What is a Class Diagram?
A class diagrams are widely used to describe the types of objects in a system and their relationships. Class diagrams model class structure and contents using design elements such as classes, packages and objects. Class diagrams describe three different perspectives when designing a system, conceptual, specification, and implementation. These perspectives become evident as the diagram is created and help solidify the design.
The Class diagrams, physical data models, along with the system overview diagram are in my opinion the most important diagrams that suite the current day rapid application development requirements. UML Notations:
4.23. What is a Package Diagram? Package diagrams are used to reflect the organization of packages and their elements. When used to represent class elements, package diagrams provide a visualization of the name-spaces. In my designs, I use the package diagrams to organize classes in to different modules of the system.
4.24. What is a Sequence Diagram? A sequence diagrams model the flow of logic within a system in a visual manner, it enable both to document and validate your logic, and are used for both analysis and design purposes. Sequence diagrams are the most popular UML artifact for dynamic modeling, which focuses on identifying the behavior within your system.
4.25. What is two-tier architecture? The two-tier architecture is refers to client/ server architectures as well, the term client/ server was first used in the 1980s in reference to personal computers (PCs) on a network. The actual client/ server model started gaining acceptance in the late 1980s, and later it was adapted to World Wide Web programming.
According to the modern days use of two-tier architecture the user interfaces (or with ASP.NET, all web pages) runs on the client and the database is stored on the server. The actual application logic can run on either the client or the server. So in this case the user interfaces are directly access the database. Those can also be non-interface processing engines, which provide solutions to other remote/ local systems. In either case, today the two-tier model is not as reputed as the three-tier model. The advantage of the two-tier design is its simplicity, but the simplicity comes with the cost of scalability. The newer three-tier architecture, which is more famous, introduces a middle tier for the application logic.
4.26. What is three-tier architecture? The three tier software architecture (also known as three layer architectures) emerged in the 1990s to overcome the limitations of the two tier architecture. This architecture has aggressively customized and adopted by modern day system designer to web systems.
Three-tier is a client-server architecture in which the user interface, functional process logic, data storage and data access are developed and maintained as independent modules, some time on separate platforms. The term "three-tier" or "three-layer", as well as the concept of multi-tier architectures (often refers to as three-tier architecture), seems to have originated within Rational Software.
The 3-Tier architecture has the following three tiers.
Presentation Tier or Web Server: User Interface, displaying/ accepting data/ input to/ from the user
Application Logic/ Business Logic/ Transaction Tier or Application Server: Data validation, acceptability check before being added to the database and all other business/ application specific operations
Data Tier or Database server: Simple reading and writing method to database or any other storage, connection, command, stored procedures etc
4.27. What is MVC architecture? The Model-View-Controller (MVC) architecture separates the modeling of the domain, the presentation, and the actions based on user input into three separate classes.
Unfortunately, the popularity of this pattern has resulted in a number of faulty usages; each technology (Java, ASP.NET etc) has defined it in their own way making it difficult to understand. In particular, the term "controller" has been used to mean different things in different contexts. The definitions given bellow are the closes possible ones I found for ASP.NET version of MVC.
Model: DataSet and typed DataSet (some times business object, object collection, XML etc) are the most common use of the model.
View: The ASPX and ASCX files generally handle the responsibilities of the view.
Controllers: The handling of events or the controlling is usually done in the code-behind class. In a complex n-tier distributed system the MVC architecture place the vital role of organizing the presentation tier of the system.
4.28. What is SOA? A service-oriented architecture is essentially a collection of services. These services communicate with each other. The communication can involve either simple data passing or it could involve two or more services coordinating some activity. Some means of connecting services to each other is needed.
The .Net technology introduces the SOA by mean of web services.
The SOA can be used as the concept to connect multiple systems to provide services. It has it's great share in the future of the IT world.
According to the imaginary diagram above, we can see how the Service Oriented Architecture is being used to provide a set of centralized services to the citizens of a country. The citizens are given a unique identifying card, where that card carries all personal information of each citizen. Each service centers such as shopping complex, hospital, station, and factory are equipped with a computer system where that system is connected to a central server, which is responsible of providing service to a city. As an example when a customer enter the shopping complex the regional computer system report it to the central server and obtain information about the customer before providing access to the premises. The system welcomes the customer. The customer finished the shopping and then by the time he leaves the shopping complex, he will be asked to go through a billing process, where the regional computer system will manage the process. The payment will be automatically handled with the input details obtain from the customer identifying card.
The regional system will report to the city (computer system of the city) while the city will report to the country (computer system of the country).
4.29. What is the Data Access Layer? The data access layer (DAL), which is a key part of every n-tier system, is mainly consist of a simple set of code that does basic interactions with the database or any other storage device. These functionalities are often referred to as CRUD (Create, Retrieve, Update, and Delete).
The data access layer need to be generic, simple, quick and efficient as much as possible. It should not include complex application/ business logics.
I have seen systems with lengthy, complex store procedures (SP), which run through several cases before doing a simple retrieval. They contain not only most part of the business logic, but application logic and user interface logic as well. If SP is getting longer and complicated, then it is a good indication that you are burring your business logic inside the data access layer.
4.30. What is the Business Logic Layer? I know for a fact that this is a question for most, but from the other hand by reading many articles I have become aware that not everyone agrees to what business logic actually is, and in many cases it's just the bridge in between the presentation layer and the data access layer with having nothing much, except taking from one and passing to the other. In some other cases, it is not even been well thought out, they just take the leftovers from the presentation layer and the data access layer then put them in another layer which automatically is called the business logic layer. However there are no god said things that cannot be changed in software world. You can change as and when you feel comfortable that the method you apply is flexible enough to support the growth of your system. There are many great ways, but be careful when selecting them, they can over complicating the simple system. It is a balance one needs to find with their experience.
As a general advice when you define business entities, you must decide how to map the data in your tables to correctly defined business entities. The business entities should meaningfully define considering various types of requirements and functioning of your system. It is recommended to identify the business entities to encapsulate the functional/ UI (User Interface) requirements of your application, rather than define a separate business entity for each table of your database. For example, if you want to combine data from couple of table to build a UI (User Interface) control (Web Control), implement that function in the Business Logic Layer with a business object that uses couple of data object to support with your complex business requirement.
4.31. What is Gang of Four (GoF) Design Patterns? The Gang of Four (GoF) patterns are generally considered the foundation for all other patterns. They are categorized in three groups: Creational, Structural, and Behavioral. Here you will find information on these important patterns.
Creational Patterns
Abstract Factory Creates an instance of several families of classes
Builder Separates object construction from its representation
Factory Method Creates an instance of several derived classes
Prototype A fully initialized instance to be copied or cloned
Singleton A class of which only a single instance can exist
Structural Patterns
Adapter Match interfaces of different classes
Bridge Separates an object’s interface from its implementation
Composite A tree structure of simple and composite objects
Decorator Add responsibilities to objects dynamically
Facade A single class that represents an entire subsystem
Flyweight A fine-grained instance used for efficient sharing
Proxy An object representing another object
Behavioral Patterns
Chain of Resp. A way of passing a request between a chain of objects
Command Encapsulate a command request as an object
Interpreter A way to include language elements in a program
Iterator Sequentially access the elements of a collection
Mediator Defines simplified communication between classes
Memento Capture and restore an object's internal state
Observer A way of notifying change to a number of classes
State Alter an object's behavior when its state changes
Strategy Encapsulates an algorithm inside a class
Template Method Defer the exact steps of an algorithm to a subclass
Visitor Defines a new operation to a class without change
4.32. What is the difference between Abstract Factory and Builder design patterns?
The two design patterns are fundamentally different. However, when you learn them for the first time, you will see a confusing similarity. So that it will make harder for you to understand them. But if you continue to study eventually, you will get afraid of design patterns too. It is like infant phobia, once you get afraid at your early age, it stays with you forever. So the result would be that you never look back at design patterns again. Let me see whether I can solve this brain teaser for you.
In the image below, you have both design pattern listed in. I am trying to compare the two one on one to identify the similarities. If you observe the figure carefully, you will see an easily understandable color pattern (same color is used to mark the classes that are of similar kind).
Please follow up with the numbers in the image when reading the listing below.
Mark #1: Both patterns have used a generic class as the entry-class. The only difference is the name of the class. One pattern has named it as “Client”, while the other named it as “Director”. Mark #2: Here again the difference is the class name. It is “AbstractFactory” for one and “Builder” for the other. Additionally both classes are of type abstract. Mark #3: Once again both patterns have defined two generic (WindowsFactory & ConcreteBuilder) classes. They both have created by inheriting their respective abstract class. Mark #4: Finally, both seem to produce some kind of a generic output.
Now, where are we? Aren’t they looking almost identical? So then why are we having two different patterns here?
Let’s compare the two again side by side for one last time, but this time, focusing on the differences.
Abstract Factory: Emphasizes a family of product objects (either simple or complex)
Builder: Focuses on constructing a complex object step by step
Abstract Factory: Focus on *what* is made
Builder: Focus on *how* it is made
Abstract Factory: Focus on defining many different types of *factories* to build many *products*, and it is not a one builder for just one product
Builder: Focus on building a one complex but one single *product*
Abstract Factory: Defers the choice of what concrete type of object to make until run time
Builder: Hide the logic/ operation of how to compile that complex object
Abstract Factory: *Every* method call creates and returns different objects
Builder: Only the *last* method call returns the object, while other calls partially build the object
Sometimes creational patterns are complementary: So you can join one or many patterns when you design your system. As an example builder can use one of the other patterns to implement which components get built or in another case Abstract Factory, Builder, and Prototype can use Singleton in their implementations. So the conclusion would be that the two design patterns exist to resolve two type of business problems, so even though they look similar, they are not.
I hope that this shed some light to resolve the puzzle. If you still don’t understand it, then this time it is not you, it has to be me and it is since that I don’t know how to explain it.
5. What is the Conclusion? I don't think, that it is realistic trying to make a programming language be everything to everybody. The language becomes bloated, hard to learn, and hard to read if everything plus the kitchen sink is thrown in. In another word every language has their limitations. As system architect and designer we should be able to fully and more importantly correctly (this also mean that you shouldn’t use a ballistic missile to kill a fly or hire FBI to catch the fly) utilize the available tools and features to build usable, sustainable, maintainable and also very importantly expandable software systems, that fully utilize the feature of the language to bring a competitively advance system to their customers. In order to do it, the foundation of a system places a vital role. The design or the architecture of a software system is the foundation. It hold the system together, hence designing a system properly (this never mean an *over* desinging) is the key to the success. When you talk about designing a software system, the correct handling of OOP concept is very important. I have made the above article richer with idea but still kept it short so that one can learn/ remind all of important concept at a glance. Hope you all will enjoy reading it.
Source: http://www.codeproject.com/KB/architecture/OOP_Concepts_and_manymore.aspx
One day I read an article that said that the richest 2 percent own half the world's wealth. It also said that the richest 1 percent of adults owned 40 percent of global assets in the year 2000. And further, that the richest 10 percent of adults accounted for 85 percent of the world's total wealth. So there is an unbalanced distribution of wealth in the physical world. Have you ever thought of an unbalanced distribution of knowledge in the software world? According to my view point, the massive expansion of the software industry is forcing developers to use already implemented libraries, services and frameworks to develop software within ever shorter periods of time. The new developers are trained to use (I would say more often) already developed software components, to complete the development quicker. They just plug in an existing library and some how manage to achieve the requirements. But the sad part of the story is, that they never get a training to define, design the architecture for, and implement such components. As the number of years pass by, these developers become leads and also software architects. Their titles change, but the old legacy of not understanding, of not having any architectural experience continues, creating a vacuum of good architects. The bottom line is that only a small percentage of developers know how to design a truly object oriented system. The solution to this problem is getting harder every day as the aggressive nature of the software industry does not support an easy adjustment to existing processes, and also the related online teaching materials are either complex or less practical or sometimes even wrong. The most of them use impractical, irrelevant examples of shapes, animals and many other physical world entities to teach concepts of software architecture. There are only very few good business-oriented design references. Unfortunately, I myself am no exception and am a result of this very same system. I got the same education that all of you did, and also referred to the same resource set you all read.
Coming back to the initial point, I noticed that there is a knowledge gap, increasing every day, between the architects who know how to architect a system properly and the others who do not know. The ones, who know, know it right. But the ones, who do not know, know nothing. Just like the world’s wealth distribution, it is an unbalanced distribution of knowledge.
2. Background This article began after reading and hearing the questions new developers have, on basics of software architecture. There are some good articles out there, but still developers struggle to understand the basic concepts, and more importantly, the way to apply them correctly.
As I see it, newcomers will always struggle to understand a precise definition of a new concept, because it is always a new and hence unfamiliar idea. The one, who has experience, understands the meaning, but the one who doesn’t, struggles to understand the very same definition. It is like that. Employers want experienced employees. So they say, you need to have experience to get a job. But how the hell is one supposed to have that experience if no one is willing to give him a job? As in the general case, the start with software architecture is no exception. It will be difficult. When you start to design your very first system, you will try to apply everything you know or learned from everywhere. You will feel that an interface needs to be defined for every class, like I did once. You will find it harder to understand when and when not to do something. Just prepare to go through a painful process. Others will criticize you, may laugh at you and say that the way you have designed it is wrong. Listen to them, and learn continuously. In this process you will also have to read and think a lot. I hope that this article will give you the right start for that long journey.
“The knowledge of the actions of great men, acquired by long experience in contemporary affairs, and a continual study of antiquity” – I read this phrase when I was reading the book named “The Art of War”, seems applicable here, isn’t it?
3. Prerequisites This article is an effort to provide an accurate information pool for new developers on the basics of software architecture, focusing on Object Oriented Programming (OOP). If you are a developer, who has a minimum of three or more years of continuous development experience and has that hunger to learn more, to step-in to the next level to become a software architect, this article is for you.
4. The Main Content
4.1. What is Software Architecture? Software Architecture is defined to be the rules, heuristics and patterns governing:
Partitioning the problem and the system to be built into discrete pieces
Techniques used to create interfaces between these pieces
Techniques used to manage overall structure and flow
Techniques used to interface the system to its environment
Appropriate use of development and delivery approaches, techniques and tools.
4.2. Why Architecture is important?
The primary goal of software architecture is to define the non-functional requirements of a system and define the environment. The detailed design is followed by a definition of how to deliver the functional behavior within the architectural rules. Architecture is important because it:
Controls complexity
Enforces best practices
Gives consistency and uniformity
Increases predictability
Enables re-use.
4.3. What is OOP? OOP is a design philosophy. It stands for Object Oriented Programming. Object-Oriented Programming (OOP) uses a different set of programming languages than old procedural programming languages (C, Pascal, etc.). Everything in OOP is grouped as self sustainable "objects". Hence, you gain re-usability by means of four main object-oriented programming concepts.
In order to clearly understand the object orientation, let’s take your “hand” as an example. The “hand” is a class. Your body has two objects of type hand, named left hand and right hand. Their main functions are controlled/ managed by a set of electrical signals sent through your shoulders (through an interface). So the shoulder is an interface which your body uses to interact with your hands. The hand is a well architected class. The hand is being re-used to create the left hand and the right hand by slightly changing the properties of it.
4.4. What is an Object? An object can be considered a "thing" that can perform a set of related activities. The set of activities that the object performs defines the object's behavior. For example, the hand can grip something or a Student (object) can give the name or address.
In pure OOP terms an object is an instance of a class.
4.5. What is a Class?
A class is simply a representation of a type of object. It is the blueprint/ plan/ template that
describe the details of an object. A class is the blueprint from which the individual objects are created. Class is composed of three things: a name, attributes, and operations.Collapse Copy Codepublic class Student
{
}
According to the sample given below we can say that the student object, named objectStudent, has created out of the Student class.
Collapse Copy CodeStudent objectStudent = new Student();
In real world, you'll often find many individual objects all of the same kind. As an example, there may be thousands of other bicycles in existence, all of the same make and model. Each bicycle has built from the same blueprint. In object-oriented terms, we say that the bicycle is an instance of the class of objects known as bicycles.
In the software world, though you may not have realized it, you have already used classes. For example, the TextBox control, you always used, is made out of the TextBox class, which defines its appearance and capabilities. Each time you drag a TextBox control, you are actually creating a new instance of the TextBox class.
4.6. How to identify and design a Class?
This is an art; each designer uses different techniques to identify classes. However according to Object Oriented Design Principles, there are five principles that you must follow when design a class,
SRP - The Single Responsibility Principle - A class should have one, and only one, reason to change.
OCP - The Open Closed Principle - You should be able to extend a classes behavior, without modifying it.
LSP - The Liskov Substitution Principle- Derived classes must be substitutable for their base classes.
DIP - The Dependency Inversion Principle- Depend on abstractions, not on concretions.
ISP - The Interface Segregation Principle- Make fine grained interfaces that are client specific.
For more information on design principles, please refer to Object Mentor.
Additionally to identify a class correctly, you need to identify the full list of leaf level functions/ operations of the system (granular level use cases of the system). Then you can proceed to group each function to form classes (classes will group same types of functions/ operations). However a well defined class must be a meaningful grouping of a set of functions and should support the re-usability while increasing expandability/ maintainability of the overall system.
In software world the concept of dividing and conquering is always recommended, if you start analyzing a full system at the start, you will find it harder to manage. So the better approach is to identify the module of the system first and then dig deep in to each module separately to seek out classes.
A software system may consist of many classes. But in any case, when you have many, it needs to be managed. Think of a big organization, with its work force exceeding several thousand employees (let’s take one employee as a one class). In order to manage such a work force, you need to have proper management policies in place. Same technique can be applies to manage classes of your software system as well. In order to manage the classes of a software system, and to reduce the complexity, the system designers use several techniques, which can be grouped under four main concepts named Encapsulation, Abstraction, Inheritance, and Polymorphism. These concepts are the four main gods of OOP world and in software term, they are called four main Object Oriented Programming (OOP) Concepts.
4.7. What is Encapsulation (or information hiding)? The encapsulation is the inclusion within a program object of all the resources need for the object to function - basically, the methods and the data. In OOP the encapsulation is mainly achieved by creating classes, the classes expose public methods and properties. The class is kind of a container or capsule or a cell, which encapsulate the set of methods, attribute and properties to provide its indented functionalities to other classes. In that sense, encapsulation also allows a class to change its internal implementation without hurting the overall functioning of the system. That idea of encapsulation is to hide how a class does it but to allow requesting what to do.
In order to modularize/ define the functionality of a one class, that class can uses functions/ properties exposed by another class in many different ways. According to Object Oriented Programming there are several techniques, classes can use to link with each other and they are named association, aggregation, and composition.
There are several other ways that an encapsulation can be used, as an example we can take the usage of an interface. The interface can be used to hide the information of an implemented class.
Collapse Copy CodeIStudent myStudent = new LocalStudent();
IStudent myStudent = new ForeignStudent();
According to the sample above (let’s assume that LocalStudent and ForeignStudent are implemented by the IStudent interface) we can see how LocalStudent and ForeignStudent are hiding their, localize implementing information through the IStudent interface.
4.8. What is Association? Association is a (*a*) relationship between two classes. It allows one object instance to cause another to perform an action on its behalf. Association is the more general term that define the relationship between two classes, where as the aggregation and composition are relatively special.
Collapse Copy Codepublic class StudentRegistrar
{
public StudentRegistrar ();
{
new RecordManager().Initialize();
}
}
In this case we can say that there is an association between StudentRegistrar and RecordManager or there is a directional association from StudentRegistrar to RecordManager or StudentRegistrar use a (*Use*) RecordManager. Since a direction is explicitly specified, in this case the controller class is the StudentRegistrar.
To some beginners, association is a confusing concept. The troubles created not only by the association alone, but with two other OOP concepts, that is association, aggregation and composition. Every one understands association, before aggregation and composition are described. The aggregation or composition cannot be separately understood. If you understand the aggregation alone it will crack the definition given for association, and if you try to understand the composition alone it will always threaten the definition given for aggregation, all three concepts are closely related, hence must study together, by comparing one definition to another. Let’s explore all three and see whether we can understand the differences between these useful concepts.
4.9. What is the difference between Association, Aggregation and Composition? Association is a (*a*) relationship between two classes, where one class use another. But aggregation describes a special type of an association. Aggregation is the (*the*) relationship between two classes. When object of one class has an (*has*) object of another, if second is a part of first (containment relationship) then we called that there is an aggregation between two classes. Unlike association, aggregation always insists a direction.
Collapse Copy Codepublic class University
{
private Chancellor universityChancellor = new Chancellor();
}
In this case I can say that University aggregate Chancellor or University has an (*has-a*) Chancellor. But even without a Chancellor a University can exists. But a University cannot exist without Faculties, the life time of a University attached with the life time of its Faculty (or Faculties). If Faculties are disposed the University will not exist or wise versa. In that case we called that University is composed of Faculties. So that composition can be recognized as a special type of an aggregation.
Same way, as another example, you can say that, there is a composite relationship in-between a KeyValuePairCollection and a KeyValuePair. The two mutually depend on each other.
.Net and Java uses the Composite relation to define their Collections. I have seen Composition is being used in many other ways too. However the more important factor, that most people forget is the life time factor. The life time of the two classes that has bond with a composite relation mutually depend on each other. If you take the .net Collection to understand this, there you have the Collection Element define inside (it is an inner part, hence called it is composed of) the Collection, farcing the Element to get disposed with the Collection. If not, as an example, if you define the Collection and it’s Element to be independent, then the relationship would be more of a type Aggregation, than a Composition. So the point is, if you want to bind two classes with Composite relation, more accurate way is to have a one define inside the other class (making it a protected or private class). This way you are allowing the outer class to fulfill its purpose, while tying the lifetime of the inner class with the outer class.
So in summary, we can say that aggregation is a special kind of an association and composition is a special kind of an aggregation. (Association->Aggregation->Composition)
4.10. What is Abstraction and Generalization? Abstraction is an emphasis on the idea, qualities and properties rather than the particulars (a suppression of detail). The importance of abstraction is derived from its ability to hide irrelevant details and from the use of names to reference objects. Abstraction is essential in the construction of programs. It places the emphasis on what an object is or does rather than how it is represented or how it works. Thus, it is the primary means of managing complexity in large programs.
While abstraction reduces complexity by hiding irrelevant detail, generalization reduces complexity by replacing multiple entities which perform similar functions with a single construct. Generalization is the broadening of application to encompass a larger domain of objects of the same or different type. Programming languages provide generalization through variables, parameterization, generics and polymorphism. It places the emphasis on the similarities between objects. Thus, it helps to manage complexity by collecting individuals into groups and providing a representative which can be used to specify any individual of the group.
Abstraction and generalization are often used together. Abstracts are generalized through parameterization to provide greater utility. In parameterization, one or more parts of an entity are replaced with a name which is new to the entity. The name is used as a parameter. When the parameterized abstract is invoked, it is invoked with a binding of the parameter to an argument.
4.11. What is an Abstract class? Abstract classes, which declared with the abstract keyword, cannot be instantiated. It can only be used as a super-class for other classes that extend the abstract class. Abstract class is the concept and implementation gets completed when it is being realized by a subclass. In addition to this a class can inherit only from one abstract class (but a class may implement many interfaces) and must override all its abstract methods/ properties and may override virtual methods/ properties.
Abstract classes are ideal when implementing frameworks. As an example, let’s study the abstract class named LoggerBase below. Please carefully read the comments as it will help you to understand the reasoning behind this code.
Collapse Copy Codepublic abstract class LoggerBase
{
///
/// field is private, so it intend to use inside the class only
///
private log4net.ILog logger = null;
///
/// protected, so it only visible for inherited class
///
protected LoggerBase()
{
// The private object is created inside the constructor
logger = log4net.LogManager.GetLogger(this.LogPrefix);
// The additional initialization is done immediately after
log4net.Config.DOMConfigurator.Configure();
}
///
/// When you define the property as abstract,
/// it forces the inherited class to override the LogPrefix
/// So, with the help of this technique the log can be made,
/// inside the abstract class itself, irrespective of it origin.
/// If you study carefully you will find a reason for not to have “set” method here.
///
protected abstract System.Type LogPrefix
{
get;
}
///
/// Simple log method,
/// which is only visible for inherited classes
///
///
protected void LogError(string message)
{
if (this.logger.IsErrorEnabled)
{
this.logger.Error(message);
}
}
///
/// Public properties which exposes to inherited class
/// and all other classes that have access to inherited class
///
public bool IsThisLogError
{
get
{
return this.logger.IsErrorEnabled;
}
}
}The idea of having this class as an abstract is to define a framework for exception logging. This class will allow all subclass to gain access to a common exception logging module and will facilitate to easily replace the logging library. By the time you define the LoggerBase, you wouldn’t have an idea about other modules of the system. But you do have a concept in mind and that is, if a class is going to log an exception, they have to inherit the LoggerBase. In other word the LoggerBase provide a framework for exception logging.
Let’s try to understand each line of the above code.
Like any other class, an abstract class can contain fields, hence I used a private field named logger declare the ILog interface of the famous log4net library. This will allow the Loggerbase class to control, what to use, for logging, hence, will allow changing the source logger library easily.
The access modifier of the constructor of the LoggerBase is protected. The public constructor has no use when the class is of type abstract. The abstract classes are not allowed to instantiate the class. So I went for the protected constructor.
The abstract property named LogPrefix is an important one. It enforces and guarantees to have a value for LogPrefix (LogPrefix uses to obtain the detail of the source class, which the exception has occurred) for every subclass, before they invoke a method to log an error.
The method named LogError is protected, hence exposed to all subclasses. You are not allowed or rather you cannot make it public, as any class, without inheriting the LoggerBase cannot use it meaningfully.
Let’s find out why the property named IsThisLogError is public. It may be important/ useful for other associated classes of an inherited class to know whether the associated member logs its errors or not.
Apart from these you can also have virtual methods defined in an abstract class. The virtual method may have its default implementation, where a subclass can override it when required.
All and all, the important factor here is that all OOP concepts should be used carefully with reasons, you should be able to logically explain, why you make a property a public or a field a private or a class an abstract. Additionally, when architecting frameworks, the OOP concepts can be used to forcefully guide the system to be developed in the way framework architect’s wanted it to be architected initially.
4.12. What is an Interface? In summary the Interface separates the implementation and defines the structure, and this concept is very useful in cases where you need the implementation to be interchangeable. Apart from that an interface is very useful when the implementation changes frequently. Some say you should define all classes in terms of interfaces, but I think recommendation seems a bit extreme.
Interface can be used to define a generic template and then one or more abstract classes to define partial implementations of the interface. Interfaces just specify the method declaration (implicitly public and abstract) and can contain fields and properties (which are also implicitly public and abstract). Interface definition begins with the keyword interface. An interface like that of an abstract class cannot be instantiated.
If a class that implements an interface does not define all the methods of the interface, then it must be declared abstract and the method definitions must be provided by the subclass that extends the abstract class. In addition to this an interfaces can inherit other interfaces.
The sample below will provide an interface for our LoggerBase abstract class.
Collapse Copy Codepublic interface ILogger
{
bool IsThisLogError { get; }
}
4.13. What is the difference between a Class and an Interface? In .Net/ C# a class can be defined to implement an interface and also it supports multiple implementations. When a class implements an interface, an object of such class can be encapsulated inside an interface.
If MyLogger is a class, which implements ILogger, there we can write
Collapse Copy CodeILogger log = new MyLogger();
A class and an interface are two different types (conceptually). Theoretically a class emphasis the idea of encapsulation, while an interface emphasis the idea of abstraction (by suppressing the details of the implementation). The two poses a clear separation from one to another. Therefore it is very difficult or rather impossible to have an effective meaningful comparison between the two, but it is very useful and also meaningful to have a comparison between an interface and an abstract class.
4.14. What is the difference between an Interface and an Abstract class?
There are quite a big difference between an interface and an abstract class, even though both look similar.
Interface definition begins with a keyword interface so it is of type interface
Abstract classes are declared with the abstract keyword so it is of type class
Interface has no implementation, but they have to be implemented.
Abstract class’s methods can have implementations and they have to be extended.
Interfaces can only have method declaration (implicitly public and abstract) and fields (implicitly public static)
Abstract class’s methods can’t have implementation only when declared abstract.
Interface can inherit more than one interfaces
Abstract class can implement more than one interfaces, but can inherit only one class
Abstract class must override all abstract method and may override virtual methods
Interface can be used when the implementation is changing
Abstract class can be used to provide some default behavior for a base class.
Interface makes implementation interchangeable
Interface increase security by hiding the implementation
Abstract class can be used when implementing framework
Abstract classes are an excellent way to create planned inheritance hierarchies and also to use as non-leaf classes in class hierarchies.
Abstract classes let you define some behaviors; they force your subclasses to provide others. For example, if you have an application framework, an abstract class can be used to provide the default implementation of the services and all mandatory modules such as event logging and message handling etc. This approach allows the developers to develop the application within the guided help provided by the framework.
However, in practice when you come across with some application-specific functionality that only your application can perform, such as startup and shutdown tasks etc. The abstract base class can declare virtual shutdown and startup methods. The base class knows that it needs those methods, but an abstract class lets your class admit that it doesn't know how to perform those actions; it only knows that it must initiate the actions. When it is time to start up, the abstract class can call the startup method. When the base class calls this method, it can execute the method defined by the child class.
4.15. What is Implicit and Explicit Interface Implementations?
As mentioned before .Net support multiple implementations, the concept of implicit and explicit implementation provide safe way to implement methods of multiple interfaces by hiding, exposing or preserving identities of each of interface methods, even when the method signatures are the same.
Let's consider the interfaces defined below.
Collapse Copy Codeinterface IDisposable
{
void Dispose();
}
Here you can see that the class Student has implicitly and explicitly implemented the method named Dispose() via Dispose and IDisposable.Dispose.
Collapse Copy Codeclass Student : IDisposable
{
public void Dispose()
{
Console.WriteLine("Student.Dispose");
}
void IDisposable.Dispose()
{
Console.WriteLine("IDisposable.Dispose");
}
}
4.16. What is Inheritance?
Ability of a new class to be created, from an existing class by extending it, is called inheritance.
Collapse Copy Codepublic class Exception
{
}
public class IOException : Exception
{
}
According to the above example the new class (IOException), which is called the derived class or subclass, inherits the members of an existing class (Exception), which is called the base class or super-class. The class IOException can extend the functionality of the class Exception by adding new types and methods and by overriding existing ones.
Just like abstraction is closely related with generalization, the inheritance is closely related with specialization. It is important to discuss those two concepts together with generalization to better understand and to reduce the complexity.
One of the most important relationships among objects in the real world is specialization, which can be described as the “is-a” relationship. When we say that a dog is a mammal, we mean that the dog is a specialized kind of mammal. It has all the characteristics of any mammal (it bears live young, nurses with milk, has hair), but it specializes these characteristics to the familiar characteristics of canis domesticus. A cat is also a mammal. As such, we expect it to share certain characteristics with the dog that are generalized in Mammal, but to differ in those characteristics that are specialized in cats.
The specialization and generalization relationships are both reciprocal and hierarchical. Specialization is just the other side of the generalization coin: Mammal generalizes what is common between dogs and cats, and dogs and cats specialize mammals to their own specific subtypes.
Similarly, as an example you can say that both IOException and SecurityException are of type Exception. They have all characteristics and behaviors of an Exception, That mean the IOException is a specialized kind of Exception. A SecurityException is also an Exception. As such, we expect it to share certain characteristic with IOException that are generalized in Exception, but to differ in those characteristics that are specialized in SecurityExceptions. In other words, Exception generalizes the shared characteristics of both IOException and SecurityException, while IOException and SecurityException specialize with their characteristics and behaviors.
In OOP, the specialization relationship is implemented using the principle called inheritance. This is the most common and most natural and widely accepted way of implement this relationship.
4.17. What is Polymorphisms? Polymorphisms is a generic term that means 'many shapes'. More precisely Polymorphisms means the ability to request that the same operations be performed by a wide range of different types of things.
At times, I used to think that understanding Object Oriented Programming concepts have made it difficult since they have grouped under four main concepts, while each concept is closely related with one another. Hence one has to be extremely careful to correctly understand each concept separately, while understanding the way each related with other concepts.
In OOP the polymorphisms is achieved by using many different techniques named method overloading, operator overloading and method overriding,
4.18. What is Method Overloading? The method overloading is the ability to define several methods all with the same name.
Collapse Copy Codepublic class MyLogger
{
public void LogError(Exception e)
{
// Implementation goes here
}
public bool LogError(Exception e, string message)
{
// Implementation goes here
}
}
4.19. What is Operator Overloading? The operator overloading (less commonly known as ad-hoc polymorphisms) is a specific case of polymorphisms in which some or all of operators like +, - or == are treated as polymorphic functions and as such have different behaviors depending on the types of its arguments.
Collapse Copy Codepublic class Complex
{
private int real;
public int Real
{ get { return real; } }
private int imaginary;
public int Imaginary
{ get { return imaginary; } }
public Complex(int real, int imaginary)
{
this.real = real;
this.imaginary = imaginary;
}
public static Complex operator +(Complex c1, Complex c2)
{
return new Complex(c1.Real + c2.Real, c1.Imaginary + c2.Imaginary);
}
}
I above example I have overloaded the plus operator for adding two complex numbers. There the two properties named Real and Imaginary has been declared exposing only the required “get” method, while the object’s constructor is demanding for mandatory real and imaginary values with the user defined constructor of the class.
4.20. What is Method Overriding? Method overriding is a language feature that allows a subclass to override a specific implementation of a method that is already provided by one of its super-classes.
A subclass can give its own definition of methods but need to have the same signature as the method in its super-class. This means that when overriding a method the subclass's method has to have the same name and parameter list as the super-class's overridden method.
Collapse Copy Codeusing System;
public class Complex
{
private int real;
public int Real
{ get { return real; } }
private int imaginary;
public int Imaginary
{ get { return imaginary; } }
public Complex(int real, int imaginary)
{
this.real = real;
this.imaginary = imaginary;
}
public static Complex operator +(Complex c1, Complex c2)
{
return new Complex(c1.Real + c2.Real, c1.Imaginary + c2.Imaginary);
}
public override string ToString()
{
return (String.Format("{0} + {1}i", real, imaginary));
}
}
In above example I have extended the implementation of the sample Complex class given under operator overloading section. This class has one overridden method named “ToString”, which override the default implementation of the standard “ToString” method to support the correct string conversion of a complex number.
Collapse Copy CodeComplex num1 = new Complex(5, 7);
Complex num2 = new Complex(3, 8);
// Add two Complex numbers using the
// overloaded plus operator
Complex sum = num1 + num2;
// Print the numbers and the sum
// using the overriden ToString method
Console.WriteLine("({0}) + ({1}) = {2}", num1, num2, sum);
Console.ReadLine();
4.21. What is a Use case?
A use case is a thing an actor perceives from the system. A use case maps actors with functions. Importantly, the actors need not be people. As an example a system can perform the role of an actor, when it communicate with another system.
In another angle a use case encodes a typical user interaction with the system. In particular, it:
Captures some user-visible function.
Achieves some concrete goal for the user. A complete set of use cases largely defines the requirements for your system: everything the user can see, and would like to do. The below diagram contains a set of use cases that describes a simple login module of a gaming website.
4.22. What is a Class Diagram?
A class diagrams are widely used to describe the types of objects in a system and their relationships. Class diagrams model class structure and contents using design elements such as classes, packages and objects. Class diagrams describe three different perspectives when designing a system, conceptual, specification, and implementation. These perspectives become evident as the diagram is created and help solidify the design.
The Class diagrams, physical data models, along with the system overview diagram are in my opinion the most important diagrams that suite the current day rapid application development requirements. UML Notations:
4.23. What is a Package Diagram? Package diagrams are used to reflect the organization of packages and their elements. When used to represent class elements, package diagrams provide a visualization of the name-spaces. In my designs, I use the package diagrams to organize classes in to different modules of the system.
4.24. What is a Sequence Diagram? A sequence diagrams model the flow of logic within a system in a visual manner, it enable both to document and validate your logic, and are used for both analysis and design purposes. Sequence diagrams are the most popular UML artifact for dynamic modeling, which focuses on identifying the behavior within your system.
4.25. What is two-tier architecture? The two-tier architecture is refers to client/ server architectures as well, the term client/ server was first used in the 1980s in reference to personal computers (PCs) on a network. The actual client/ server model started gaining acceptance in the late 1980s, and later it was adapted to World Wide Web programming.
According to the modern days use of two-tier architecture the user interfaces (or with ASP.NET, all web pages) runs on the client and the database is stored on the server. The actual application logic can run on either the client or the server. So in this case the user interfaces are directly access the database. Those can also be non-interface processing engines, which provide solutions to other remote/ local systems. In either case, today the two-tier model is not as reputed as the three-tier model. The advantage of the two-tier design is its simplicity, but the simplicity comes with the cost of scalability. The newer three-tier architecture, which is more famous, introduces a middle tier for the application logic.
4.26. What is three-tier architecture? The three tier software architecture (also known as three layer architectures) emerged in the 1990s to overcome the limitations of the two tier architecture. This architecture has aggressively customized and adopted by modern day system designer to web systems.
Three-tier is a client-server architecture in which the user interface, functional process logic, data storage and data access are developed and maintained as independent modules, some time on separate platforms. The term "three-tier" or "three-layer", as well as the concept of multi-tier architectures (often refers to as three-tier architecture), seems to have originated within Rational Software.
The 3-Tier architecture has the following three tiers.
Presentation Tier or Web Server: User Interface, displaying/ accepting data/ input to/ from the user
Application Logic/ Business Logic/ Transaction Tier or Application Server: Data validation, acceptability check before being added to the database and all other business/ application specific operations
Data Tier or Database server: Simple reading and writing method to database or any other storage, connection, command, stored procedures etc
4.27. What is MVC architecture? The Model-View-Controller (MVC) architecture separates the modeling of the domain, the presentation, and the actions based on user input into three separate classes.
Unfortunately, the popularity of this pattern has resulted in a number of faulty usages; each technology (Java, ASP.NET etc) has defined it in their own way making it difficult to understand. In particular, the term "controller" has been used to mean different things in different contexts. The definitions given bellow are the closes possible ones I found for ASP.NET version of MVC.
Model: DataSet and typed DataSet (some times business object, object collection, XML etc) are the most common use of the model.
View: The ASPX and ASCX files generally handle the responsibilities of the view.
Controllers: The handling of events or the controlling is usually done in the code-behind class. In a complex n-tier distributed system the MVC architecture place the vital role of organizing the presentation tier of the system.
4.28. What is SOA? A service-oriented architecture is essentially a collection of services. These services communicate with each other. The communication can involve either simple data passing or it could involve two or more services coordinating some activity. Some means of connecting services to each other is needed.
The .Net technology introduces the SOA by mean of web services.
The SOA can be used as the concept to connect multiple systems to provide services. It has it's great share in the future of the IT world.
According to the imaginary diagram above, we can see how the Service Oriented Architecture is being used to provide a set of centralized services to the citizens of a country. The citizens are given a unique identifying card, where that card carries all personal information of each citizen. Each service centers such as shopping complex, hospital, station, and factory are equipped with a computer system where that system is connected to a central server, which is responsible of providing service to a city. As an example when a customer enter the shopping complex the regional computer system report it to the central server and obtain information about the customer before providing access to the premises. The system welcomes the customer. The customer finished the shopping and then by the time he leaves the shopping complex, he will be asked to go through a billing process, where the regional computer system will manage the process. The payment will be automatically handled with the input details obtain from the customer identifying card.
The regional system will report to the city (computer system of the city) while the city will report to the country (computer system of the country).
4.29. What is the Data Access Layer? The data access layer (DAL), which is a key part of every n-tier system, is mainly consist of a simple set of code that does basic interactions with the database or any other storage device. These functionalities are often referred to as CRUD (Create, Retrieve, Update, and Delete).
The data access layer need to be generic, simple, quick and efficient as much as possible. It should not include complex application/ business logics.
I have seen systems with lengthy, complex store procedures (SP), which run through several cases before doing a simple retrieval. They contain not only most part of the business logic, but application logic and user interface logic as well. If SP is getting longer and complicated, then it is a good indication that you are burring your business logic inside the data access layer.
4.30. What is the Business Logic Layer? I know for a fact that this is a question for most, but from the other hand by reading many articles I have become aware that not everyone agrees to what business logic actually is, and in many cases it's just the bridge in between the presentation layer and the data access layer with having nothing much, except taking from one and passing to the other. In some other cases, it is not even been well thought out, they just take the leftovers from the presentation layer and the data access layer then put them in another layer which automatically is called the business logic layer. However there are no god said things that cannot be changed in software world. You can change as and when you feel comfortable that the method you apply is flexible enough to support the growth of your system. There are many great ways, but be careful when selecting them, they can over complicating the simple system. It is a balance one needs to find with their experience.
As a general advice when you define business entities, you must decide how to map the data in your tables to correctly defined business entities. The business entities should meaningfully define considering various types of requirements and functioning of your system. It is recommended to identify the business entities to encapsulate the functional/ UI (User Interface) requirements of your application, rather than define a separate business entity for each table of your database. For example, if you want to combine data from couple of table to build a UI (User Interface) control (Web Control), implement that function in the Business Logic Layer with a business object that uses couple of data object to support with your complex business requirement.
4.31. What is Gang of Four (GoF) Design Patterns? The Gang of Four (GoF) patterns are generally considered the foundation for all other patterns. They are categorized in three groups: Creational, Structural, and Behavioral. Here you will find information on these important patterns.
Creational Patterns
Abstract Factory Creates an instance of several families of classes
Builder Separates object construction from its representation
Factory Method Creates an instance of several derived classes
Prototype A fully initialized instance to be copied or cloned
Singleton A class of which only a single instance can exist
Structural Patterns
Adapter Match interfaces of different classes
Bridge Separates an object’s interface from its implementation
Composite A tree structure of simple and composite objects
Decorator Add responsibilities to objects dynamically
Facade A single class that represents an entire subsystem
Flyweight A fine-grained instance used for efficient sharing
Proxy An object representing another object
Behavioral Patterns
Chain of Resp. A way of passing a request between a chain of objects
Command Encapsulate a command request as an object
Interpreter A way to include language elements in a program
Iterator Sequentially access the elements of a collection
Mediator Defines simplified communication between classes
Memento Capture and restore an object's internal state
Observer A way of notifying change to a number of classes
State Alter an object's behavior when its state changes
Strategy Encapsulates an algorithm inside a class
Template Method Defer the exact steps of an algorithm to a subclass
Visitor Defines a new operation to a class without change
4.32. What is the difference between Abstract Factory and Builder design patterns?
The two design patterns are fundamentally different. However, when you learn them for the first time, you will see a confusing similarity. So that it will make harder for you to understand them. But if you continue to study eventually, you will get afraid of design patterns too. It is like infant phobia, once you get afraid at your early age, it stays with you forever. So the result would be that you never look back at design patterns again. Let me see whether I can solve this brain teaser for you.
In the image below, you have both design pattern listed in. I am trying to compare the two one on one to identify the similarities. If you observe the figure carefully, you will see an easily understandable color pattern (same color is used to mark the classes that are of similar kind).
Please follow up with the numbers in the image when reading the listing below.
Mark #1: Both patterns have used a generic class as the entry-class. The only difference is the name of the class. One pattern has named it as “Client”, while the other named it as “Director”. Mark #2: Here again the difference is the class name. It is “AbstractFactory” for one and “Builder” for the other. Additionally both classes are of type abstract. Mark #3: Once again both patterns have defined two generic (WindowsFactory & ConcreteBuilder) classes. They both have created by inheriting their respective abstract class. Mark #4: Finally, both seem to produce some kind of a generic output.
Now, where are we? Aren’t they looking almost identical? So then why are we having two different patterns here?
Let’s compare the two again side by side for one last time, but this time, focusing on the differences.
Abstract Factory: Emphasizes a family of product objects (either simple or complex)
Builder: Focuses on constructing a complex object step by step
Abstract Factory: Focus on *what* is made
Builder: Focus on *how* it is made
Abstract Factory: Focus on defining many different types of *factories* to build many *products*, and it is not a one builder for just one product
Builder: Focus on building a one complex but one single *product*
Abstract Factory: Defers the choice of what concrete type of object to make until run time
Builder: Hide the logic/ operation of how to compile that complex object
Abstract Factory: *Every* method call creates and returns different objects
Builder: Only the *last* method call returns the object, while other calls partially build the object
Sometimes creational patterns are complementary: So you can join one or many patterns when you design your system. As an example builder can use one of the other patterns to implement which components get built or in another case Abstract Factory, Builder, and Prototype can use Singleton in their implementations. So the conclusion would be that the two design patterns exist to resolve two type of business problems, so even though they look similar, they are not.
I hope that this shed some light to resolve the puzzle. If you still don’t understand it, then this time it is not you, it has to be me and it is since that I don’t know how to explain it.
5. What is the Conclusion? I don't think, that it is realistic trying to make a programming language be everything to everybody. The language becomes bloated, hard to learn, and hard to read if everything plus the kitchen sink is thrown in. In another word every language has their limitations. As system architect and designer we should be able to fully and more importantly correctly (this also mean that you shouldn’t use a ballistic missile to kill a fly or hire FBI to catch the fly) utilize the available tools and features to build usable, sustainable, maintainable and also very importantly expandable software systems, that fully utilize the feature of the language to bring a competitively advance system to their customers. In order to do it, the foundation of a system places a vital role. The design or the architecture of a software system is the foundation. It hold the system together, hence designing a system properly (this never mean an *over* desinging) is the key to the success. When you talk about designing a software system, the correct handling of OOP concept is very important. I have made the above article richer with idea but still kept it short so that one can learn/ remind all of important concept at a glance. Hope you all will enjoy reading it.
Source: http://www.codeproject.com/KB/architecture/OOP_Concepts_and_manymore.aspx
Subscribe to:
Posts (Atom)
About Me
- Masood H.Virk
- Jeddah, Makkah, Saudi Arabia
- for more details www.inhousetoday.com