探索F#：微软MVP的函数式编程指南

需积分: 0 48 浏览量更新于2024-07-22 收藏 4.83MB PDF 举报

"The Book of F#(NoStarch,2014) 是一本由Dave Fancher编著的书籍，旨在向.NET框架开发者介绍功能优先编程语言F#，并帮助他们转变编码思维。F#是微软Windows生态系统中的一个强大工具，它提供了默认不可变性、管道操作、类型推断和模式匹配等特性，使得代码更简洁、可靠和可预测。本书适合习惯于C#和Visual Basic的传统.NET开发者阅读，以领略F#的魅力并提升编程效率。" 在《The Book of F#》中，作者深入浅出地介绍了F#的核心概念和实践技巧。首先，F#作为一门函数式编程语言，它的主要优势在于将函数视为第一类公民，这意味着函数可以像其他数据类型一样被处理，例如作为参数传递或返回值。这种设计模式鼓励编写无副作用的代码，增强了程序的可预测性和测试性。其次，F#中的默认不可变性是另一个关键特性。这要求开发者在不创建新对象的情况下，不能改变对象的状态，从而减少了并发编程中的许多问题，如数据竞争和死锁。不可变数据结构在多线程环境中特别有价值，因为它们天生就具有线程安全的属性。管道操作（|>）是F#中的一种独特语法，它允许将函数应用于表达式的输出，使得代码更加流畅和易于阅读。通过管道，你可以构建出清晰的从左到右的数据流，而不是嵌套的函数调用。类型推断是F#的另一大亮点。编译器能够根据代码的上下文自动推断变量的类型，减少了显式声明类型的繁琐，同时也减少了类型错误的可能性。这使得代码更简洁，也更易于维护。模式匹配是F#中强大的控制流构造，它允许开发者根据值的不同形态执行不同的代码块。这在处理数据结构，特别是处理枚举、元组和自定义类型时非常有用，简化了条件判断和解构过程。此外，书中还涵盖了F#与其他.NET语言（如C#和VB.NET）的互操作性，以及如何利用F#在数据分析、机器学习和Web开发等领域的应用。技术审查者Kevin Miller和Tomas Petricek的专业审阅确保了内容的准确性和实用性。《The Book of F#》是一本全面介绍F#语言的指南，无论是对.NET开发者初次接触函数式编程，还是希望深化对F#理解的高级开发者，都能从中受益。通过阅读此书，读者不仅可以学习到F#的语法和特性，还能体会到函数式编程思想对提升软件开发质量和效率的积极影响。

xiv Contents in Detail

Aggregating Data .......................................... 213

Detecting Items ............................................ 214

Joining Multiple Data Sources .................................. 215

Extending Query Expressions .................................. 219

Type Providers ................................................... 221

Available Type Providers ..................................... 222

Using Type Providers ........................................ 223

Example: Accessing an OData Service............................ 224

Example: Parsing a String with RegexProvider....................... 226

Summary ...................................................... 228

ASYNCHRONOUS AND PARALLEL PROGRAMMING 229

Task Parallel Library ............................................... 230

Potential Parallelism ......................................... 231

Data Parallelism............................................ 231

Task Parallelism ............................................ 234

Asynchronous Workflows ........................................... 241

Creating and Starting Asynchronous Workflows ..................... 242

Cancelling Asynchronous Workflows ............................. 245

Exception Handling ......................................... 247

Asynchronous Workflows and the Task Parallel Library................. 248

Agent-Based Programming .......................................... 250

Getting Started ............................................ 250

Scanning for Messages ...................................... 251

Replying to Messages........................................ 252

Example: Agent-Based Calculator ............................... 253

Summary ...................................................... 255

COMPUTATION EXPRESSIONS 257

Anatomy of a Computation Expression .................................. 258

Example: FizzBuzz................................................ 261

Example: Building Strings ........................................... 264

Summary ...................................................... 269

INDEX 271

www.it-ebooks.info

xvi Foreword

Continuous improvement seemed more than just a way to make wid-

gets; it felt like a way to live life. It echoed Socrates’s concept of virtue; it

evoked the story of Siddhartha, who sought truth over comfort. These are

ideas about “what should be,” about merit, about substance over rhetoric,

about correctness.

After graduation I rolled into a software development career. Depend-

ing on the company, it was either clown cars and cowboys, or rigid waterfall.

Both were exciting, but no one in either environment was talking about

quality or continuous improvement. When I would bring it up, I would get

sad smiles from grizzled developers. Their eyes said, “Son, don’t you realize

this is war?” The operating systems were crashy, the dev tools were buggy,

and everything was closed source and proprietary. Thucydides said war is

“a rough master that brings most men’s characters to a level with their for-

tune.” Likewise, when the development environment is bad, most developers

will write bad code.

In 2001, a group of conscientious software developers got together

in Snowbird, Utah and signed the Agile Manifesto. About a year later I

discovered it. From my perspective, it seemed like a retelling of Deming,

operations management, and Lean manufacturing. It was the ﬁrst time

in my career that I’d heard developers discussing quality and continuous

improvement. There was hope!

After ﬁve years of test-driven development, pair programming, the

SOLID principles (single responsibility, open/closed, Liskov substitution,

interface segregation, and dependency inversion), and Scrum, my hope had

mostly worn away. I continued to ﬁght my tools, and it remained difﬁcult to

build quality software. Without discipline it was a train wreck. With disci-

pline, process, and diligence, it was a hard slog.

Through pure good luck I encountered Erlang in 2007, and in 2009 I

began working with F#. Functional programming consumed me. I learned

about immutability, recursion, pattern matching, higher-order functions,

referential transparency, code as data, and separation of behavior from

data. As I learned and practiced I began to see the huge cost of OO. So

much of what made my day-to-day coding life miserable was solvable with

Erlang and F#. As I told people about FP, I again received those sad smiles

that asked, “Don’t you know we are at war?” I took it differently this time. I

decided, “OK, sure. Let’s call it war. I’ll be on the side that’s looking at the

root cause of defects. I’ll be on the side that wants to ﬁx the problem at the

source.”

The next stage for Agile must be to fully unravel itself from OO.

Object-oriented programming had boldly promised “to model the

world.” Well, the world is a scary place where bad things happen for no

apparent reason, and in this narrow sense I concede that OO does model

the world. OO as we have it mingles data and behavior; the result is low

cohesion and tight coupling. In OO, there is shared mutable state, which

makes concurrency impossibly difﬁcult. In OO, logic is nondeterministic.

In OO, the result of a function doesn’t simply depend on the arguments

we pass in. The result may vary depending on arguments passed on previ-

ous calls to the function. How about mutations from other functions? How

www.it-ebooks.info

剩余313页未读，继续阅读

vanridin

粉丝: 108
资源: 1187

探索F#：微软MVP的函数式编程指南

The Book of F#

The Book of PF(NoStarch,3ed,2014)

expert F＃book

The GNU Make Book(NoStarch,2015)

JingyuTongdlut#book-note#redis实战1

Penglq#book-1#Builder模式1

EngineerThomas#book-2#选择排序1

AYSP#book-3#线程中断1

[F#] F# for C# Developers (英文版)

lovXin#book-2#栈和队列1

最新资源