TRUNGTQ

Think Big, Act Small, Fail Fast and Learn Rapidly

NAVIGATION - SEARCH

NativeScript là gì?

http://docs.nativescript.org/

Công cụ phát triển NativeScript sử dụng JavaScript và Typescript để xây dựng các ứng dụng gốc cho iOS, Android, và Windows Phone.

NativeScript, một công nghệ của công ty Telerik dành cho việc xây dựng các ứng di động gốc đa nền tảng từ một code duy nhất, và đã sẵn sàng để phát hành phiên bản 1.0 vào cuối tháng Tư. Telerik đang giới thiệu chương trình dùng thử vào tuần này dành cho mã nguồn mở NativeScript.

Trang web của NativeScripttrang GitHub mô tả thời gian chạy cho phép các lập trình viên sử dụng JavaScript và TypeScript để xây dựng các ứng dụng gốc cho iOS, Android, và Windows Phone (qua chiến lược Windows Universal) và chia sẻ code khắp các nền tảng. "Các lập trình viên có các kỹ năng về Web muốn xây dựng các ứng dụng gốc đích thực nên cảm thấy hứng thú bởi vì bây giờ có một cách giúp họ thực hiện được việc này" mà không cần có sự am hiểu về các ngôn ngữ quen thuộc hay các framework, ông Todd Anglin - phó chủ tịch của Telerik cho biết.

NativeScript sản xuất các ứng dụng mà có UI gốc, ông Anglin nói. "Đó là ứng dụng không render HTML trong một Web view - như với các ứng dụng lai (hybrid app) hay các ứng dụng trình duyệt truyền thống.... NativeScript cho phép ưu tiên các công cụ JavaScript trên iOS, Android, và Windows để điều khiển UI layer gốc."

Các lập trình viên sử dụng các library của NativeScript, mà tách ra các sự khác biệt giữa các nền tảng gốc; các lập trình viên cũng sử dụng CSS và ECMAScript 5. Node.js cho phép các nhà phát triển ứng dụng chỉ cần sử dụng Javascript để lập trình cho server-side "sắp xếp vai trò (helps) mà JavaScript cung cấp cho ứng dụng di động," ông Anglin cho biết.

NativeScript cung cấp sự truy cập đầy đủ vào nền tảng gốc API, và nó đặc trưng máy ảo JavaScript đã đóng gói trước; JavaScript được viết cho ứng dụng NativeScript vẫn chạy như JavaScript trên một thiết bị. "NativeScript sẽ thi hành JavaScript này trên các máy ảo JavaScript gốc được cung cấp bởi iOS (JavaScriptCore), Android (V8), và Windows (Chakra)," ông Anglin cho biết. NativeScript cung cấp "một proxy của JavaScript hiện ra tất cả các API của iOS/Android/Windows vào các máy JavaScript này, bằng cách đưa quyền điều khiển đầy đủ cho JavaScript để điều khiển các khả năng của thiết bị gốc."

NativeScript cũng xử lý UI gốc đa nền tảng, cung cấp ngôn ngữ đánh dấu siêu văn bản bằng thẻ (Markup language) được phân tách vào các công cụ UI đặc trưng nền tảng khi một ứng dụng được xây dựng. "Ví dụ như: khi một lập trình viên thêm một nút vào một ứng dụng, thì NativeScript sẽ tự động sử dụng nút điều khiển UI gốc thích hợp từ iOS, Android và Windows."

Anglin thấy rằng NativeScript khác với các công nghệ phát triển di động khác, chẳng hạn như Appcelerator Titanium, công nghệ này cũng có ý nghĩa là cho phép xây dựng các ứng dụng di động gốc qua JavaScript. Anglin dám chắc rằng Titanium có quá nhiều sự tùy biến, làm nó mang tính cá nhân nhiều hơn.

"Sự khác biệt lớn giữa một ứng dụng NativeScript và một ứng dụng lai (chẳng hạn như PhoneGap hay Sencha) là NativeScript không phụ thuộc vào trình duyệt/Web UI layer để render ứng dụng. Nó render một UI gốc, không phụ thuộc trình duyệt....Trình duyệt hay Web UI layer đó thường có sự bế tắc trong các ứng dụng di động mà muốn có các hình ảnh động đẹp và scrolling."

Telerik đã thông báo về NativeScript vào cuối tháng Sáu, công ty hy vọng tiền tệ hóa (monetize) NativeScript bằng việc đưa ra các công cụ nền tảng và UI cao cấp.

LINK: http://www.itjobs.com.vn/vi/article/javascript-trong-cac-ung-dung-cua-ios-android-va-windows-phone-467

 

Top 10 Things Every Developer Must Do

Oh wow! I am revisiting this article after six years. Things have changed quite a bit since then.

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

Over the 18 years of my software development career, I have seen many mistakes that developers repeat again and again. 

Here is my top 10 list and more.



1. Missing Documentation

I have seen developers who do not like to write documentation. Obviously, there are tight deadlines and deliverables but it does not take too much time to write about the functionality you are implementing. If you spend one hour for every seven hours of code you write, it will go a long way, and eventually it will save you a lot more time.

OK, let's try to understand this with an example.

In the code sample below, you can see a method called MessySample. I created two ArrayList objects and added some integer and string values to it. Once added, the code simply displays the output.

private void MessySample()  

{  

    ArrayList obj = new ArrayList();  

    obj.Add(32);  

    obj.Add(21);  

    obj.Add(45);  

    obj.Add(11);  

    obj.Add(89);  

    ArrayList obj2 = new ArrayList();  

    obj2.Add("Mahesh Chand");  

    obj2.Add("Praveen Kumar");  

    obj2.Add("Raj Kumar");  

    obj2.Add("Dinesh Beniwal");  

    int bs = obj2.BinarySearch("Raj Kumar");  

    Console.WriteLine(bs);  

    foreach (object o in obj2)  

    {  

        Console.WriteLine(o);  

    }  

} 


Technically, there is nothing wrong with this code.

 

The only problem is, there is no proper documentation. Unless I go through the code, I don't know what this method is doing. Also proper naming conventions and readable variables can help. If another programmer writes code and uses the same name variables, obj1 and obj2, and at some point, you try to find all variable references with the same name, you may end up going through some unwanted code. Here is the same code but documented:

/// <summary>  

/// This is a MessySample method that shows how we can write messy code  

/// </summary>  

private void MessySample()  

{  

    // Create an ArrayList object to store integer items  

    ArrayList obj = new ArrayList();  

    obj.Add(32);  

    obj.Add(21);  

    obj.Add(45);  

    obj.Add(11);  

    obj.Add(89);  

    // Create an ArrayList object to store string items  

    ArrayList obj2 = new ArrayList();  

    obj2.Add("Mahesh Chand");  

    obj2.Add("Praveen Kumar");  

    obj2.Add("Raj Kumar");  

    obj2.Add("Dinesh Beniwal");  

    // Apply binary search  

    int bs = obj2.BinarySearch("Raj Kumar");  

    // Display index on the console  

    Console.WriteLine(bs);  

    // Send ArrayList items to the console  

    foreach (object o in obj2)  

    {  

        Console.WriteLine(o);  

    }  

}  



 

2. Messy Code

Keep it clean. Don't be messy. Writing code is an art. Make it cleaner. Make it pretty. Format it. This part is more about focusing on naming conventions and proper representation of your methods, properties, and variables.

Here is my original code sample. As you can see from the code below, I have two ArrayList objects and the code adds some integer and string values to them. 

private void MessySample()  

{  

    ArrayList obj = new ArrayList();  

    obj.Add(32);  

    obj.Add(21);  

    obj.Add(45);  

    obj.Add(11);  

    obj.Add(89);  

    ArrayList obj2 = new ArrayList();  

    obj2.Add("Mahesh Chand");  

    obj2.Add("Praveen Kumar");  

    obj2.Add("Raj Kumar");  

    obj2.Add("Dinesh Beniwal");  

   

    int bs = obj2.BinarySearch("Raj Kumar");  

    Console.WriteLine(bs);  

   

    foreach (object o in obj2)  

    {  

        Console.WriteLine(o);  

    }  

}  

 

The following code is a clean code with proper comments and naming conventions. As one of the comments suggests, if you use the proper method, variable, and other object names, you will need very little or no documentation. From the code below, I can clearly see that numberList is an array of numbers and authorsArray is a an array of author names.

/// <summary>  

/// This method is a clean sample that shows how to write  

/// clean code.  

/// </summary>  

private void CleanSample()  

{  

    // Dynamic ArrayList with no size limit  

    ArrayList numberList = new ArrayList();  

    // Add 5 Integer Items to ArrayList  

    numberList.Add(32);  

    numberList.Add(21);  

    numberList.Add(45);  

    numberList.Add(11);  

    numberList.Add(89);  

   

    // Create Authors Array List to store authors  

    ArrayList authorsArray = new ArrayList();  

    // Add Author names  

    authorsArray.Add("Mahesh Chand");  

    authorsArray.Add("Praveen Kumar");  

    authorsArray.Add("Raj Kumar");  

    authorsArray.Add("Dinesh Beniwal");  

   

    // Display and apply binary search  

    Console.WriteLine("====== Binary Search ArrayList ============");  

    int bs = authorsArray.BinarySearch("Raj Kumar");  

    Console.WriteLine(bs);  

   

    // Display authors to the console  

    foreach (object author in authorsArray)  

    {  

        Console.WriteLine(author);  

    }  

}  



 

  1. Copy, But With Love

    Code sharing, code reusability, and open source are very common practices today. Thank Google, C# Corner, MSDN, CodeProject, StackOverflow and other online websites for providing tons of free code. It would be foolish for us not to use the same code that is already written and available.

 

So copy, but copy with love. The first thing you need to do is understand the code and verify it. There is so much code out there. Some code is written by experts. Some code is written by amateurs. You must test your code. Once tested, you may also want to check with the terms and conditions and licensing of the code. Sometimes, you may not realize it, but a person who has shared code may want you to use his copyright terms. 

  1. Think Outside of the Box

    If you are involved in a project that was already developed by some other developers, do not just follow what other developers have written. Before you follow the same steps, think if the way the prior code was implemented is the right way to do it. I may have shared some code on C# Corner but that does not mean I have written the most efficient code. You may come up with better ideas.

 

For example, on many websites, you may find code that is written using C# 2.0. The same code is applicable today as well, but in C# 5.0, you may write the same code in an optimal way.

5. Testing! Testing! Testing!

This is one of the areas where I find most developers who are rushing to deliver their code are not testing it thoroughly. Not only must you functional test your code, but also stress test it. This I have seen over and over: When a new functionality is added to a project, there may be chances that the code may have affected other areas. You as a developer need to test that all areas are tested well before it is given to your Integration Manager or deployed on the Test Server.   

Read here: Why Every Developer Should be a Good Tester

 

  1. Debug! Don't Guess

    Don't trust yourself unless you're an experienced programmer. Don't guess what your code would do unless you have already used that code before. Always debug the code before even running it. When I write a piece of code for the first time, I go line by line, add my debug variables and use debugger to step through line-by-line and variable-by-variable to see if the values of these variables are passing my tests. You can avoid this if you use #7.

    7. Write Test Cases

    Visual Studio 2010 and later versions come with a very powerful tool to write test cases for your project. Use it. You can also use third-party open source products such as Nunit. 

    8. One Thing at a Time

    I have seen some programmers write code for one week straight and then do the testing. Write code based on a smaller unit of functionality and test it before you move to the next functionality.

    9. Think Modular

    I remember the days when a code file would have thousands of lines and just keep going and going. If possible, try to break down your code into chunks based on the function, and create a method or a class as applicable. Use proper Object Oriented Programming best practices. Use proper design patterns. Make a good use of libraries, classes, functions, and other modern programming language features that are available to you. 
  2. Do Not Trust Your Testing Team

    Do not rely on your testing team and think that they will find all the bugs. You are the one who knows code and functionality more than anybody else. You test it and then hand it over to the testing team.

    11.    Why don't you add one ;).

    What is your list? Please share!


    12. Good Team Player

    Building software is teamwork. One person can build small software, but when you work on large projects, it is a team effort. A developer must be a good team player. It does not matter how smart or expert you are, if you are not helping your team and not sharing with others, the project will suffer.

 

  1. Ask Questions. Ask Again and Again

    Some developers (I was the same in my early career) think asking questions of a client or manager will make them look foolish or stupid. This is not true at all. I would rather explain the same thing four times than get something that is not right. So make sure you get the requirements right before starting to write code.

 

  1. Be Ahead. Give 110 Percent

    This is from my personal experience. I was named the "crack programmer," "coder on crack," and other names for solving problems instantly. Most of the time, I got the requirements and they were done before the deadlines. So when my manager would come ask, "Is that feature done?" My answer would be, "Yes, it is live already."  

    There are three ways to work:

    1. Do what you were told to do.
    2. Do less than what you were told to do and still be working on it.
    3. Do more than what you were told to do.

    Do not assume that your boss knows more than you. He/She may know more than you but it does not mean that you cannot give your ideas or suggestions. You may have better ideas. Even if they are not better, it does no harm to open up and let him/her know.

    15. Got any advice? Share with us here . . . 

 

LINK: http://www.c-sharpcorner.com/blogs/top-10-things-every-developer-must-do

Top 8 Things You Should Not Say To a Developer

8 điều bạn không lên nói với nhà phát triển (Developer)

Last week, I wrote an article, Top 10 Things You Should Never Say To Your Boss. This week, I am writing the other side of the coin and focusing on the team owners and what they should not say to their developers.

I've been working in the software industry for 17 years. Most of the points discussed here are based on my personal experience. The article is written for business owners, project owners, technical managers, team leaders and seniors who manage a team of developers.

One thing worth mentioning is that most bosses have bosses. If an employee is trying to do something that is in the best interests of the boss's employer it is actually the boss that should obey the employee. That is of course an over-simplification; it is a general concept, not a rule.


Here is a list of my things not to say to a developer.

I don't have time for this.

So you're busy and you really don't have time for your developer. I suggest you find some time. By not giving time enough to your developer, you're actually hurting the project and hence yourself.

There are many possible solutions. A really good boss is creative, flexible and open to alternatives. One solution is to get it in writing and when you do, give it the attention it deserves. It could be that a developer has already tried to communicate in writing. If so and you tell them you do not have time then that leaves the employee without a reasonable solution. The problem might be personal or the problem might be a problem for the company, either way ignoring it has consequences. 

Just do it the way I like it

Coding is not food. Your taste does not matter as long as the developer is doing his/her job. These days, the technology and features are being released rapidly. You should encourage your developers to adapt the latest features, trends and technologies that benefit the organization and project. It is your responsibility to know what is best and that is not easy to do. You need to analyze the costs and benefits of the latest features, trends and technologies. It is reasonable to restrain developers from using something just because it is new but it can also be a mistake to avoid converting to something new. The longer you delay implementing something new, the more it could cost to do the conversion.

One of my long time clients asked me to review one of his projects. I met the architect and the tech lead of the project and started the code review. The project was developed using .NET 4.5 and Visual Studio 2013 but what I saw was the developers still using coding that complied with .NET 1.1 and 2.0. I questioned the architect and he replied, this is the way like it. We've been doing this for a long time. It is easy to understand. The problem is that the longer they delay developing code using the latest capabilities, the more it will cost to convert when it becomes necessary. 

Just leave it. I will do it.

In my early days, I made this mistake myself. Sometimes to move things faster, you end up doing it yourself. I suggest you stop that. To scare your development and grow your organization and team, you must know how to train your developers. I know it can be very frustrating from time to time but for the long run, it will actually help you.

One of the key attributes of a good leader is an ability to create his/her own replacement. In software development, as a project owner, you must consider “what if”. What if I am sick tomorrow?

We use computers to do as much of the detailed work as possible. The philosophy is that it frees us to do the things that computers cannot do. You need to delegate to your employees everything they can do so it frees you to do the things that they cannot.

Also avoid keeping the fun stuff for you to do yourself. Employees are likely to resent that.

You're taking too much time

You must determine why a developer is taking more time than your expectations. There must be a valid reason behind it. If the developer is not skilled, it is your job to find a replacement. If a developer is not motivated, it is your job to figure out why. Again, it all falls on you. All of that can of course be difficult to do. It is easy to avoid doing it. A common way to avoid doing it is to blame the developer for not getting the work done on time and when that is done to avoid finding problems, there are consequences.

Your projects will proceed much more smoothly if you are realistic about the time required. Setting unrealistic deadlines might get the work done on time but end up being very costly later. Employers need to attempt to employ developers that are able to make reasonable estimates that can be relied on. If however a deadline is used because the employer thinks the employee is not productive then that is a problem. The ideal is to have a trustworthy employee that is trusted.

One suggestion is to maintain a record of estimates compared to actual times, especially if that is done for many developers and many projects. There are software systems and other methodologies available to help get other opinions of time estimates.

He can do faster than you

Everybody has their own pace. Everybody has their own strengths and weaknesses. Some people are fast and some are perfectionists. Some are slow but workhorses. When you hire a new employee, it is your job to determine their pace and skills and maximize what they are capable of.

Be careful about judging an employee as being faster if they only seem faster because they put in more hours. Longer hours might seem to be an advantage but it is not necessarily an advantage. If for example a developer actually puts in more hours to get something done faster then it might be a symptom of carelessness if they must do a lot of testing. An extended amount of time spent testing could result in costlier maintenance in the future if the testing begins with buggier code. It is your responsibility to determine what applies.

Do it now

Yes it is very difficult not to say this. Trust me, I've been a developer. I have worked under projects. I have managed teams and projects and now I am managing companies. There are many times, I want things now.

But I know, I am wrong. Sometimes things can't be done now.

Think of it in terms of the amount of time spent switching gears from one thing to another. You should assume that asking a developer to do something that takes 10 minutes will take an hour away from something else. That is not a problem if it is done once and/or when it is important enough but the cost could accumulate if done carelessly.

Can you use a template or this is really simple

Oh, this one pisses me off. This does not apply to a technical person. This usually comes from amateur business owners who do not understand software at all. I hear this a lot from non-technical business owners.

Oh yea, if it's that simple, why can't you do it yourself?

A student can do it

You've just not only insultated your developer, but you've also demoralized him/her. Reality is, no a student can't do it. That's why you hired an experienced developer and pay lot more than you would pay a student.

Summary

In this article, I talked about some things you should not say to a developer. I am sure you have your own list. I would like to get your feedback and your items that you don't want your boss or other people to say.

LINK: http://www.c-sharpcorner.com/UploadFile/mahesh/top-8-things-you-should-not-say-to-a-developer/

Thơ Tự Sự - Lưu Quang Vũ

Dù đục dù trong, con sông vẫn chảy
Dù cao dù thấp, cây lá vẫn xanh
Dù người phàm tục hay kẻ tu hành
Vẫn phải sống từ những điều rất nhỏ

Ta hay chê rằng cuộc đời méo mó
Sao ta không tròn ngay tự trong tâm
Đất ấp ôm cho mọi hạt nảy mầm
Những chồi non tự vươn lên tìm ánh sáng

Nếu tất cả đường đời đều trơn láng
Chắc gì ta đã nhận ra ta
Ai trong đời cũng có thể tiến xa
Nếu có khả năng tự mình đứng dậy

Hạnh phúc cũng như bầu trời này vậy
Không chỉ dành cho một riêng ai!

(Lưu Quang Vũ)

SOLID Architectural Pattern With Real Time Example

In an interview, an interviewer often asks for a real time example of a SOLID design pattern. Thus, I decided to write some real time examples of the SOLID design pattern.

What is SOLID?

SOLID is an acronym for five principles of architecture.

S – Single Responsibility Principle

O – Open Close Principle

L – Liskov Substitution Principle

I –Interface Segregation Principle

D – Dependency Inversion Principle

Single Responsibility Principle (SRP)

It says that every class should have single responsibility. A class should not have more than one reason to change.

Example

Suppose, you have created a class XmlValidator for XML validation, which has the responsibility to validate XML.

If there is a need to update XML, then a separate class should be created for the same. XmlValidator class should not be used for updating XML.  

public class XmlValidator   

    {  

        public void Validate()  

        { 

        } 

    }   



For updating a new class, it should be created. 

public class XmlUpdate  

    {  

        public void DoUpdate()  

        {  

        } 

    }   



Open Close Principle (OCP)

A class should be open for an extension and closed for the modification.

Example

Suppose, we have a class name Customer, which has a property InvoiceNumber, which has an integer type 

public class Customer  

    {  

        public int InvoiceNumber  

        {  

            get;  

            set;

        }  

    }   



In the future, if the requirement changes now, InvoiceNumber should be alphanumeric rather than only an integer. Hence, in this case, you should create a subclass CustomerNew with a same property but different datatype rather than modifying the previous one. 

public class CustomerNew : Customer  

    {  

        public new String InvoiceNumber  

        {  

            get;  

            set; 

        }  

    }   



Liskov Substitution Principle (LSP)

A parent object should be able to replace its child during runtime polymorphism.

Example

Suppose, you have two classes, Cooler and Fan, both are inherited from a common interface named ISwitch, which has three methods- On, Off and Regulate. 

public interface ISwitch  

    {  

        void On();  

        void Off();  

    }  

    public class Cooler : ISwitch  

    {  

        public void On()  

        {    

        }  

        public void Off()  

        {  

        }  

        public void Regulate()  

        {  

        }  

    }  

    public class Fan : ISwitch  

    {  

        public void On()  

        {  

        }  

        public void Off()  

        {  

        }  

        public void Regulate()  

        {  

        }  

    }  

  

    public class MainClass  

    {  

        public void AddObject()  

        {  

            List<ISwitch> Switch = new List<ISwitch>();  

            Switch.Add(new Cooler());  

            Switch.Add(new Fan());  

            

            foreach (var o in Switch)  

            {  

                o.Regulate();  

            }  

        }  

    }   



Everything was fine until a new class introduced for same interface named Bulb, which has only two methods On and Off. It does not have Regulate method. Thus Bulb class is given below.  

public class Bulb : ISwitch  

    {  

        public void On()  

        {  

        }  

        public void Off()  

        { 

        }  

        public void Regulate()  

        {  

            throw new NotImplementedException();  

        }  

    }   



Now, AddObject method will be updated, as shown below. 

 
public void AddObject()  

        {  

            List<ISwitch> Switch = new List<ISwitch>();  

            Switch.Add(new Cooler());  

            Switch.Add(new Fan());  

            Switch.Add(new Bulb());            

            foreach (var o in Switch)  

            {  

                o.Regulate();  

            }  

        }  


In this case, Regulate method will throw an error.

One horrible solution to this problem is to put an if condition. 

foreach (var o in Switch)  

        {  

    if(o is Bulb)  

    continue; 

      o.Regulate();  

     }   



This is an example of bad design, if above condition is used somewhere, it clearly means that there is a violation of LSK principle.

Interface Segregation Principle (ISP)

Client specific interfaces are better than general purpose interfaces.

Suppose, we have one interface for clicking.

public interface IClick{   

    void onClick(Object obj);  

}  



As time passes, new requirement comes for adding one more function onLongClick. You need to add this method in already created interface.

public interface IClick{   

    void onClick(Object obj);  

    void onLongClick(Object obj);  

}  



After some time, one new requirement comes for adding function for touch also and you need to add the method in the same interface

public interface IClick{   

    void onClick(Object obj);  

    void onLongClick(Object obj);  

    void onTouch(Object obj);  

}  



 

At this point, you need to decide to change the name of interface too because touch is different than click.

In this way, this interface becomes a problem—generic and polluted. At this stage, ISP comes into play.

Why Generic Interface creates problem?

Suppose, some clients need only onClick function and some need only onTouch function, then one will be useless for both. Hence ISP gives the solution, which splits the interface into two interfaces.

ITouch and IClick. The client which has required onClick can implement IClick, which needs onTouch. It can implement ITouch and when it needs both, it can implement both.

public interface IClick{   

    void onClick(Object obj);  

    void onLongClick(Object obj);  

}  

public interface ITouch{   

    void onClick(Object obj);  

    void onTouch(Object obj);  

}  



Dependency Inversion Principle (ISP)

It states two points, where the first point is a higher level module, which should not depend on a low level module. Both should depend on abstraction. The second point is abstraction, which should not depend on detail.

Detail should depend on abstraction.

In other words, no object should be created inside a class. They should be passed or injected from outside. When it  is received, it will be an interface rather than a class.

Here is a bad design without using Dependency Injection. 

class Student  

{  

    // Handle to EventLog writer to write to the logs  

    LogWriter writer = null;  

    // This function will be called when the student has problem  

    public void Notify(string message)  

    {  

        if (writer == null)  

        {  

            writer = new LogWriter();  

        }  

        writer.Write(message);  

    }  

}   



This is also a bad design. 

class Student  

{  

    // Handle to EventLog writer to write to the logs  

    LogWriter writer = null;  

Public Student(LogWriter writer)  

    { 

     This.writer = writer;  

}  

    // This function will be called when the student has problem  

    public void Notify(string message)  

    {  

        writer.Write(message);  

    }  

}   



The written classes given above are bad designs because in the case of a change in LogWrite, you have to disturb Student class. We should use an interface inside Student instead of a class.

With Dependency Injection, the code is given, as shown below. 

 
class Student  

{  

    // Handle to EventLog writer to write to the logs  

    ILogWriter writer = null;  

Public Student(ILogWriter writer)  

    { 

      This.writer = writer;  

}  

    // This function will be called when the student has problem  

    public void Notify(string message)  

    {  

        writer.Write(message);  

    }  

}  



LINK: http://www.c-sharpcorner.com/article/solid-architectural-pattern-with-real-time-example/