C# 5.0编程指南： Metro风格应用与跨平台支持

5星 · 超过95%的资源需积分: 50 8 浏览量更新于2024-07-27 3 收藏 4.22MB PDF 举报

"Programming C# 5.0 是一本关于C#编程语言的详细指南，涵盖了C# 5.0版本的特性和应用。该书旨在介绍C#在各种应用程序开发中的使用，包括网页、桌面应用、游戏、手机应用以及命令行工具。C#自Windows开发领域占据核心地位已近十年，因此当微软宣布Windows 8将引入一种针对平板电脑触摸交互优化的新式应用（即Metro风格应用）时，C#自然而然地成为首批支持这些应用的四种语言之一，其他语言包括C++、JavaScript和Visual Basic。C#虽然由微软发明，但其语言规范和运行时环境由ECMA标准化，允许任何人实现C#，比如开源项目Mono提供了在Linux、iOS和Android上运行C#应用的工具。选择C#编程可能是因为其在特定任务中的适用性，以及个人对编程语言的偏好。" 在《Programming C# 5.0》这本书中，读者将深入学习C# 5.0的关键特性，如异步编程（async/await），这使得编写高性能的并发和非阻塞代码变得更加容易。此外，还会介绍面向对象编程的基础，包括类、对象、接口、继承和多态等概念。书中还涵盖了泛型，使开发者可以创建类型安全且可重用的数据结构。C#的委托和事件机制对于构建响应式的用户界面和处理异步操作至关重要。书中详细阐述了C#的类型系统，包括值类型和引用类型，以及垃圾收集机制，帮助开发者理解内存管理。同时，介绍了 LINQ（Language Integrated Query，语言集成查询）这一强大的数据查询工具，它简化了与数据库、集合和其他数据源的交互。对于高级主题，如反射和元数据，本书也会有深入探讨，这些特性允许在运行时检查和操作程序集的结构。此外，C#的预处理器指令和编译期条件编译也是开发者编写灵活代码的重要工具。本书还涉及了异常处理，这是任何编程语言中必不可少的部分，用于处理运行时错误。C#的命名空间和程序集管理则帮助组织大型项目，而模块化设计是保持代码清晰和可维护的关键。对于C# 5.0的新特性，例如动态类型和匿名方法，开发者可以通过实例和练习来掌握它们的用法。动态类型允许在运行时确定变量的类型，而匿名方法和Lambda表达式简化了短小的回调函数的定义。最后，书中将介绍如何使用Visual Studio IDE进行C#开发，包括调试技巧和代码编辑器的功能。通过阅读《Programming C# 5.0》，无论是初学者还是经验丰富的程序员，都能提升自己的C#技能，更好地利用这一强大语言开发各类应用。

O’Reilly Media, Inc. 3/13/2012

Writing a Unit Test

Now I need to write a test. Visual Studio has provided me with a test class to get me

started in a file called UnitTest1.cs, but that’s not a very informative name. I need to call

it something else. There are various schools of thought as to how you should structure

your unit tests. Some developers advocate one test class for each class you wish to test,

but I like the style where you write a class for each scenario in which you want to test a

particular class, with one method for each of the things that should be true about your

code in that scenario. As you’ve probably guessed from the project names I’ve chosen,

our program will only have one behavior: it will display a “Hello, world!” message when

it runs. So I’ll rename the UnitTest1.cs source file to WhenProgramRuns.cs. This test

should verify that the program prints out the required message when it runs. The test

itself is very simple, but unfortunately, getting to the point where we can run the test is a

bit more involved. Example 1-1 shows the whole source file; the test is near the end, in

bold.

Example 1-1. A unit test class for our first program

using System;

using Microsoft.VisualStudio.TestTools.UnitTesting;

namespace HelloWorld.Tests

{

[TestClass]

public class WhenProgramRuns

{

private string _consoleOutput;

[TestInitialize]

public void Initialize()

{

var w = new System.IO.StringWriter();

Console.SetOut(w);

Program.Main(new string[0]);

_consoleOutput = w.GetStringBuilder().ToString().Trim();

}

[TestMethod]

public void SaysHelloWorld()

{

Assert.AreEqual("Hello, world!", _consoleOutput);

}

I will explain each of the features in this file once I’ve shown the program itself. For

now, the most interesting part of this is that it defines some behavior we want our

program to have. The test states that the program’s output should be the message “Hello,

world!” If it’s not, this test will report a failure. The test itself is pleasingly simple, but

the code that sets things up for the test is a little awkward. The problem here is that the

obligatory first example that all programming books are required by law to show isn’t

very amenable to unit testing of individual classes, because you can’t really test anything

less than the whole program. We want to verify that the program prints out a particular

message to the console. In a real application, you’d probably devise some sort of

O’Reilly Media, Inc. 3/13/2012

abstraction for output, and your unit tests would provide a fake version of that abstraction

for test purposes. But I want my application (which Example 1-1 merely tests) to keep to

the spirit of the standard “Hello, world!” example. To avoid overcomplicating my

program, I’ve made my test intercept console output so that I can check that the program

printed what it was supposed to. (Chapter 16 will describe the features I’m using from the

System.IO namespace to achieve this.)

There’s a second challenge. Normally, a unit test will, by definition, test some isolated

and usually small part of the program. But in this case, the program is so simple that there

is only one feature of interest, and that feature executes when we run the program. This

means my test will need to invoke the program’s entry point. I could have done that by

launching my HelloWorld program in a whole new process, but capturing its output

would have been rather more complex than the in-process interception done by Example

1-1. Instead, I’m just invoking the program’s entry point directly. In a C# application, the

entry point is usually a method called Main defined in a class called Program. Example

1-2 shows the relevant line from Example 1-1, passing an empty array to simulate

running the program with no command line arguments.

Example 1-2. Calling a method

Program.Main(new string[0]);

Unfortunately, there’s a problem with that. A program’s entry point is typically only

accessible to the runtime—it’s an implementation detail of your program, and there’s not

normally any reason to make it publicly accessible. However, I’ll make an exception

here, because that’s where the only code in in this example will live. So to get the code to

compile, we’ll need to make a change to our main program. Example 1-3 shows the

relevant line from the code from the Program.cs file in the HelloWorld project. (I’ll show

the whole thing shortly.)

Example 1-3. Making the program entry point accessible

public class Program

{

public static void Main(string[] args)

{

...

I’ve added the public keyword to the start of two lines to make the code accessible to

the test, enabling Example 1-1 to compile. There are other ways I could have achieved

this. I could have left the class as it is, made the method internal, and then applied the

InternalsVisibleToAttribute to my program to grant access just to the test

suite. But internal protection and assembly level attributes are topics for later chapters (3

and 15 respectively) so I decided to keep it simple for this first example. I’ll show the

alternative approach in Chapter 15.

Microsoft’s unit testing framework defines a helper class called

PrivateType, which provides a way to invoke private methods for

test purposes, and I could have used that instead of making the entry

point public. However, it’s considered bad practice to invoke private

methods directly from tests, because a test should only have to verify

the observable behavior of the code under test. Testing specific details

of how the code has been structured is rarely helpful.

O’Reilly Media, Inc. 3/13/2012

The file begins with a series of using directives. These are optional, but almost all source

files contain them, and they tell the compiler which namespaces we’d like to use, raising

the obvious question: what’s a namespace?

Namespaces

Namespaces bring order and structure to what would otherwise be a horrible mess. The

.NET Framework class library contains over 10,000 classes, and there are many more

classes out there in 3

party libraries, not to mention the classes you will write yourself.

There are two problems that can occur when dealing with this many named entities. First,

it becomes hard to guarantee uniqueness unless everything either has a very long name,

or the names include sections of random gibberish. Second, it can become challenging to

discover the API you need—unless you know or can guess the right name, it’s difficult to

find what you need from an unstructured list of thousands of things. Namespaces solve

both of these problems.

Most .NET types are defined in a namespace. Microsoft-supplied types have distinctive

namespaces. When the types are part of the .NET Framework, the containing namespaces

start with System, and when they’re part of some Microsoft technology which is not a

core part of .NET, they usually begin with Microsoft. Libraries from other vendors

tend to start with the company name, while open source libraries often use their project

name. You are not forced to put your own types into namespaces, but it’s recommended

that you do. C# does not treat System as a special namespace, so nothing stops you

using that for your own types, but it’s a bad idea because it will tend to confuse other

developers. You should pick something more distinctive for your own code, such as your

company or project name.

The namespace usually gives a clue as to the purpose of the type. For example, all the

types that relate to file handling can be found in the System.IO namespace, while those

concerned with networking are under System.Net. Namespaces can form a hierarchy.

So the framework’s System namespace doesn’t just contain types. It also holds other

namespaces, such as System.Net, and these often contain yet more namespaces, such

as System.Net.Sockets and System.Net.Mail. These examples show that

namespaces act as a sort of description, which can help you navigate the library. If you

were looking for regular expression handling, for example, you might look through the

available namespaces, and notice the System.Text namespace. Looking in there,

you’d find a System.Text.RegularExpressions namespace, at which point

you’d be pretty confident that you were looking in the right place.

Namespaces also provide a way to ensure uniqueness. The namespace in which a type is

defined is part of that type’s full name. This lets libraries use short, simple names for

things. For example, the regular expression API includes a Capture class representing

the results from a regular expression capture. If you are working on software that deals

with images, the term ‘capture’ is more commonly used to mean the acquisition of some

image data, and you might feel that Capture is the most descriptive name for a class in

your own code. It would be annoying to have to pick a different name just because the

best one is already taken, particularly if your image acquisition code has no use for

regular expressions, meaning that you weren’t even planning to use that Capture type.

But in fact it’s fine. Both types can be called Capture, and they will still have different

names. The full name of the regular expression capture class is effectively

System.Text.RegularExpressions.Capture, and likewise your class’s full

O’Reilly Media, Inc. 3/13/2012

name would include its containing namespace, e.g.

SpiffingSoftworks.Imaging.Capture.

If you really want to, you can write the fully qualified name of a type every time you use

it, but most developers don’t want to do anything quite so tedious, which is where the

using directives at the start of Example 1-4 come in. These state the namespaces whose

types this source file intends to use. You will normally edit this list to match your file’s

requirements, but Visual Studio provides a small selection of commonly used ones to get

you started. It chooses different sets in different contexts. If you add a class representing

a user interface control, for example, Visual Studio would include various UI-related

namespaces in the list.

With using declarations like these in place, you can just use the short, unqualified name

for a class. When we finally add the line of code that enables our HelloWorld example to

do its job, we’ll be using the System.Console class, but because of the first using

directive, we’ll be able to refer to it as just Console. In fact, that’s the only class we’ll

be using, so we could remove all the other using directives.

Earlier, you saw that a project’s References describe which libraries it

uses. You might think that References are redundant—can’t the

compiler work out which external libraries we are using from the

namespaces? It could if there were a direct correspondence between

namespaces and libraries, but there isn’t. There is sometimes an

apparent connection—System.Web.dll contains classes in the

System.Web namespace for example. But there often isn’t—the class

library includes System.Core.dll but there is no System.Core

namespace. So it is necessary to tell Visual Studio which libraries your

project depends on, as well as saying which namespaces any particular

source file uses. We will look at the nature and structure of library files

in more detail in Chapter 12.

Even with namespaces, there’s potential for ambiguity. You might use two namespaces

that both happen to define a class of the same name. If you want to use that class, then

you will need to be explicit, referring to it by its full name. If you need to use such

classes a lot in the file, you can still save yourself some typing: you only need to use the

full name once because you can define an alias. Example 1-5 uses this to resolve a clash

that I’ve run into a few times: .NET’s user interface framework, the Windows

Presentation Foundation (WPF) defines a Path class for working with Bézier curves,

polygons and other shapes, but there’s also a Path class for working with filesystem

paths, and if you want to write code that produces a graphical representation of the

contents of a file, you will need both namespaces, meaning that the simple name Path is

ambiguous if unqualified. But as Example 1-5 shows, you can define distinctive aliases

for each.

Example 1-5. Resolving ambiguity with aliases

using System.IO;

using System.Windows.Shapes;

using IoPath = System.IO.Path;

using WpfPath = System.Windows.Shapes.Path;

With these aliases in place, you can use IoPath as a synonym for the file-related Path

class, and WpfPath for the graphical one.

剩余285页未读，继续阅读

hanyuqy

粉丝: 0
资源: 9

C# 5.0编程指南： Metro风格应用与跨平台支持

c# 5.0编程 Early Release（Programming C# 5.0 Early Release）.pdf

C#5.0PDF教程

Ian Griffiths的《Programming C# 5.0》英文版详解

A Programmer's Guide to C# 5.0 pdf

Professional C# 5.0 and .NET 4.5.1 pdf

C#5.0参考手册

C# 5.0 in a Nutshell

微软.Net编程规范5.0--原版.pdf

[Wrox] C# 5.0 Programmer's Reference

C# 5.0 All-in-One For Dummies

最新资源