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

4星 · 超过85%的资源需积分: 50 147 浏览量更新于2024-07-26 收藏 4.22MB PDF 举报

“.NET C#5.0教程” .NET C#5.0是微软推出的面向对象的编程语言，它的发音为“see sharp”。C#语言功能强大，适用于各种类型的软件开发，包括网页应用、桌面应用、游戏、手机应用以及命令行工具。自推出以来，C#就一直是Windows开发者的核心选择，尤其是在微软宣布Windows 8将引入全新风格的触摸优化应用（被称为 Metro 风格应用）时，C#自然而然地成为首批提供全面支持的四种语言之一，与C++、JavaScript和Visual Basic并列。值得注意的是，尽管C#由微软发明，但其语言规范和运行时环境已经由国际标准组织ECMA进行文档化，这意味着任何人均可实现C#。这并非理论上的可能性，开源项目Mono（http://www.mono-project.com/）就是一个实例，它提供了在Linux、iOS和Android等平台上构建和运行C#应用程序的工具。选择C#的原因可能因个人需求和喜好而异。C#具有许多优势，比如： 1. **强大的类型系统**：C#拥有严谨的强类型系统，有助于防止在程序执行期间出现意外的类型错误。 2. **面向对象编程**：C#支持面向对象编程原则，如封装、继承和多态，使得代码结构清晰，易于维护。 3. **丰富的库支持**：.NET框架提供了大量预建的类库，可以快速实现常见功能，如网络通信、数据库操作、图形用户界面等。 4. **现代语言特性**：C# 5.0引入了异步编程模型（async/await），使得编写异步代码更加简洁，提高了程序的响应性和性能。 5. **跨平台支持**：随着.NET Core的发布，C#的跨平台能力进一步增强，可以在Windows、Linux、macOS等多个操作系统上开发和运行应用。 6. **IDE支持**：Visual Studio作为C#的主要开发环境，提供了强大的集成开发环境（IDE）和调试工具，提升开发效率。 7. **社区活跃**：C#拥有庞大的开发者社区和丰富的学习资源，遇到问题时可以方便地获取帮助和解决方案。然而，与其他语言相比，C#可能存在一些不足，比如学习曲线较陡峭，对新手来说可能更具挑战性；此外，某些特定领域的开发，如Web前端或移动端原生应用，可能有其他更专业的语言（如JavaScript和Swift）更适合。选择C#作为编程语言主要取决于你所从事的项目类型、目标平台以及个人的编程习惯和偏好。对于希望在Windows生态或跨平台开发中寻找强大且成熟的解决方案的开发者来说，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页未读，继续阅读

scallydev

粉丝: 0
资源: 2

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

Microsoft.NET 编程语言C#教程

Microsoft.NET编程语言C#教程

ACCP5.0 深入.NET和c#编程

.NET 5.0(.Net Core 5.0)_(4105P).pdf

.NET Reflector 5.0

.net reflector5.0

e-commerce-asp.net-5.0:带有asp.net 5.0的电子商务网站

C#加密 Eziriz .NET Reactor 5.0.0.0 破解可用

.NET Reflector 5.0 ReleaseCodeModelViewer

.NET Reflector 5.0 Release

最新资源