Self-Implementation of LINQ to objects: 1-Introduction

This article is translated from Jon Skeet's blog series "edulinq ".

Address: http://msmvps.com/blogs/jon_skeet/archive/2010/09/03/reimplementing-linq-to-objects-part-1-introduction.aspx

About a year and a half ago, I gave a speech at the DDD campaign. At that time, I tried to re-implement LINQ to objects. How much can I implement in one hour. According to the feedback after the meeting, I did it too quickly... and I was far from complete. However, in any case, I still think it is very interesting to re-implement LINQ to objects, so I think I should do it again in a simple and easy-to-use way.

This series of blog posts will be labeled with "edulinq". You can use this method to filter out this series of blog posts.

General idea

 

My plan is to completely re-implement LINQ to objects and use each blog to explain a method (or a set of methods ). I will try my bestCodeWriting quality is achieved, but I won't write any XML document comments-since I have already written a blog to explain it, I don't want to repeat it in the code. I will make some optimizations as appropriate, and I hope it will be better than the implementation of LINQ to objects itself.

I will adopt a fairly simple method: I will write some unit tests for every LINQ method (most of these unit tests will not appear in the following blog), and ensure that. net can be implemented through these unit tests. Then I will comment out the reference to system. LINQ and introduce jonskeet. LINQ. In this case, the unit test will fail, and I will implement the method for the test, so that the unit test can pass the green light. This is not the same as TDD, but it is quite useful.

I will write a blog post for each LINQ operator, which will contain almost all the finished code, but I will only paste the interesting part of the test code. When encountering an important model, I will mark it with emphasis, which is exactly half of the meaning of this exercise.

At the end of each blog post, I will attach a link to download the latest code. For future readers, I will separate numbers for these downloaded files, instead of constantly updating the same file. However, I dare say that these files will be modified in the future.

Our goal is not to make a project similar to linqbridge: I will use. net 3.5 (mainly because I can directly use the extension method without creating a custom attribute), and I certainly won't worry about installation packages or other things. This series of blog posts is purely educational: If you read these series one by one, as long as luck is not too bad, you will have a deeper understanding of the overall knowledge of LINQ, in particular, I have a deeper and more detailed understanding of LINQ to objects. For example, there are a lot of misunderstandings like delayed execution: But if you have read the code, you will be able to clearly understand the clues.

 

Test

I will use nunit to write unit tests (just because I am more familiar with it ). Obviously, we will often need to test whether the two sequences are equivalent. We will do this by using the testextensions type in morelinq (I copied this type to the Project ). I will only install C # express 2010 on the netbook used to write this series of blog posts, so I will use nunit's external GuiProgram. I set the project startup Item to nunit GUI program... in C # Express, this setting cannot be done directly, but it is also very easy to modify the project file:

<Startaction> Program </startaction>

<Startprogram> C: \ Program Files \ NUnit-2.5.7.10213 \ bin \ net-2.0 \ nunit-x86.exe </startprogram>

Although this method is a bit improper, it is completely available. Set "additional command line parameters" to jonskeet. LINQ. Tests. dll-the current directory is bin/debug by default, so that you are ready. Obviously, if you install resharper or other tools and run these unit tests on your own, you will find that the test results will be integrated into Visual Studio.

Although I want to write a reasonable industrial quality code, I feel that I may not write so many unit tests in a real production environment. Even so, I still have a reason to believe that the amount of testing code will exceed the amount of finished code. This is because there are too many cases to test the sides and corners... and sometimes there are a lot of heavy loads. However, remember that our purpose is to study interesting features in LINQ.

 

Code Distribution

Just like the original version of LINQ to object, I will create a static type called enumerable... however, I will use the Division class. Each method (including multiple overloading) occupies one code file. For example, the where method will be implemented in where. CS, and its test code will be written in wheretest. CS.

 

First download code

download the code here: Linq-To-Objects-1.zip. There is no finished code yet. There are only four where methods for unit testing. The main purpose is to check whether nunit can work normally. Next step... implement the where method.