Delagtes and Events concept in OOPs

You will get many example on how to use delegates and events.In this post,I`ll try to explain about delegates  and event concept in C#                                                                                                     

    In the above example The client code(any application) consumes service code(it can be any code/application which provide some kind of processing/service to the client) by object construction or any other means.
   The client code can call methods from the service code based on the domain context but how does service code can call methods from the client code .Essentially,They are Callback requirements.In C#, We have "Delegate" and "event"  concept to implement this kinds of callbacks
  With Delegate, The client code will get full flexibility of invoking itself and Event provide  a limited flexibility to the client code.

Key Points:

1. This client code is called subscriber to this service code
2. There can be many subscribers
3. The methods(in client code)  which are to be called from service code are called Callbacks/Event Handler
4. It is common practice to use private delegate or instead use Events
5. There can  be many callbacks withing same client code or different client code
6. In C# , delegates are all type safe , It means that, All subscriber should provide callbacks which has same signatures with that of delegate defined on the service side

Workaround for the syntax error in C#:ref and out are not valid in this context

Recently I was  trying  to implement the interface Microsoft.Office.Interop.Word.Styles.
public Style this[ref object Index]
        {
          
        }

Visual Studio through  this error ":ref and out are not valid in this context"

Workaround :

//public Style this[ref object Index] // error CS0631: ref and out are not valid in this context
public Style get_Item(ref object Index)
{
    . . .
}

Great thoughts from Great Programmers

Kent Beck`s Two Hats : there are two hats namely refactoring hat and adding new function hat when you wear the adding new function hat, don`t change existing code and think of refactoring. you are just adding new capabilities. You can measure your progress by adding tests and getting the tests to work
    When you wear refactor hat, you make a point of not adding function; you only restructure the code. You don't add any tests (unless you find a case you missed earlier), you only change tests when you absolutely need to in order to cope with a change in an interface.
   As you develop software, you probably find yourself swapping hats frequently. You start by trying to add a new function, and you realize this would be much easier if the code were structured differently. So you swap hats and refactor for a while. Once the code is better structured, you swap hats and add the new function. Once you get the new function working, you realize you coded it in a way that's awkward to understand, so you swap hats again and refactor. All this might take only ten minutes, but during this time you should always be aware of which hat you're wearing.
Bottom line is that don`t wear the these two hats at the same time

Martin Fowler :Any fool can write code that a computer can understand. Good programmers write
code that humans can understand. :Programming is in many ways a conversation with a computer. You write code that tells the computer what to do, and it responds by doing exactly what you tell it. In time you close the gap between what you want it to do and what you tell it to do. Programming in this mode is all about saying exactly what you want. But there is another user of your source code. Someone will try to read your code in a few months'time to make some changes. We easily forget that extra user of the code, yet that user is actually the most important. Who cares if the computer takes a few more cycles to compile something? It does matter if it takes a programmer a week to make a change that would have taken only an hour if she had understood your code.

Refactoring a software application

Refactoring : a change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior.

The rhythm of refactoring: test, small change, test,small change, test, small change ...

Why you need to refactor :

1. Improves the Design of Software :Any software decays over a period of time as requirements changes ,Refactoring helps in  preventing the software decay  
2. Makes Software Easier to Understand:
3. Helps You Find Bugs
4. Helps You Program Faster

When you need to Refactor?:

1. Before adding new function/capability/feature
2. Before fixing a bug
3. While reviewing code
4. To understand legacy application

When you need not refactor ?:

1. The application is not working
2. The application is full of bugs
3. The code base is not stabilized 

Technology Stack for modern web development

                When we start for developing a web application, We tend to follow the latest/current trend in technology world without understanding the requirements or context. I suggest not to follow the trend but to follow the project specific requirements( There is no silver bullet for all projects )

                In this blog, I`m going to lay out a technology stack for Single Page Application.

Technology	Description
ASP.NET MVC 5	A server MVC platform which provides us modules, handler ,state management ,authentication/authorization  and boot strapping of initial requirements
Web API(as REST services)	Services for processing data from /to client application and can work with any client type application
Angular JS	Client side (web ) MVC processing
Entity Framework	ORM for data access
Bootstrap	CSS framework
JSON	Data exchange  format
ASP.NET Identity	Authentication /Authorization
SQL Server	Database
Open Web Interface for .NET (OWIN)	Hosting the application that runs outside IIS environments
Unit of work/Repository  Patterns	Data Access Patterns
JQuery	DOM Manipulation

The above technology stack provides solid foundation for building the web application

Learning Plan for Single Page application Development

                 Generally When we start to learn a technology, we start searching through google to get some good resources for learning and google through up large and misleading information even for small query as well.To address this issue and make learning in a consistent way, Microsoft came with MSDN and Microsoft Virtual Academy. But the books can not be replaced with online material for sheer enjoyment of learning.
                 In this blog, I`ll lay out a learning plan for Single Page Application which help you understanding of this technology.Indeed , This plan is for programmer who has already worked on the Asp.net and C#/JavaScript and want to get hands on the SPA.

1. Pro Asp.net MVC 5 by Adam Freeman :
             This is a fantastic book to really start your journey of MVC and provides good foundation of MVC way
2.Pro AngularJS by Adam Freeman  :
            This is a tough book and is kind of reference book to get understanding of Client side MVC way and
3.Pro Single Page Application :
            This is also tough book and provides you overall understanding of SPA architecture right from beginning till end of your SPA Development
4.Expert ASP.NET Web API 2 for MVC Developers :
             Once we got understanding of how SPA works,You can start to understand asp.net as a server side platform for SPA and this is easy reference book for web api for deeper understanding of asp.net server side platform.
5.Pro Asp.NET MVC 5 Platform :
            This is a reference book to harness you knowledge of asp.net as sever side platforms and this book provide you information on the modules,handler, state management and authentication for SPA development

             By following these books above, you get great confidence to work on SPA Development and i strongly suggest you to follow validated learning technique for learning any technology or depending on your requirements
 
 

Ways to understand an software application

Generally , When we are given a legacy application for our own understand and later to fix the bugs. We tend to follow the ways as below

1. Open your application and start go through application UI
2. Open the source code and go through each files to get an understand of application structure  
3. Create the classes diagram using Visual Studio/IDE
4. Open any documents(requirements ,help .. etc) related to the application and try to understand them
5. Debug the application using IDE.

Issues /Pitfalls with the above approach.

1. if you follow way 1 merely, It tends to be more of manual testing and helps a little
2. if you follow way 2 and 3, it is not much of any help
3. if you follow way 4 , In my view , Writing documents are kind of violation of the principle"Don't repeat yourself " and Generally gives what application is supposed to do and not what application is doing right now(we are interested in knowing this)
4. if you follow way 5 , It is more of waste of efforts and time

My recommended ways to understand any application.

1. Open your application,start go through application UI to get sense of how application looks like
2. make a list of unknown words/terminologies to make sure we get little bit of domain knowledge
3. Get to know about those words/terminologies by going through the documents/asking someone else/ Google them
4.  try to understand your technical design documents if you have.
5. Make a list of most critical functionality based on your present understanding(e.g. CRUD)
6. Make a list of classes and discover their responsibility corresponding to the listed  in step 5

Follow the below steps for each of classes listed in the step 6

1. Make a list of the keywords(language specific) which you don`t understand in the class
2. Understand all keywords
3. Break dependencies in the class/public methods involved
4. Write characterizing unit tests (are tests that characterizes the actual behavior of a piece of code) based on your understandings of class/method responsibilities   
5. Make sure that you have clear intention to get sense of what this does actually not to find any bugs 
6. debug this unit test by seeing through every line of code and DB activity if any
7. Stop when you feel that you got a sense of responsibilities the class has 

By following the steps above, We can get more confidence while working with a legacy application