优化EPUB电子书结构：清洁架构与代码展示指南

需积分: 9 145 浏览量更新于2024-07-18 收藏 7.34MB PDF 举报

"《Clean Architecture：软件结构与设计的手工艺人指南》是一本深入探讨软件架构设计原则和技术实践的专业书籍。该书主要关注于构建高质量、可维护的软件系统，强调清晰的分层结构，以便在日益复杂的技术环境中保持灵活性和可扩展性。 EPUB是一种开放且广泛接受的电子书格式，它为读者提供了丰富的阅读体验。然而，不同设备和应用程序对EPUB的支持程度不一，因此用户可以根据个人偏好调整阅读设置。常见的自定义选项包括字体选择、字体大小、单列或双列布局、横屏模式（landscape）和纵屏模式（portrait），以及可以点击放大查看的图表。为了获得最佳代码和配置示例呈现，推荐使用单列横屏模式，并将字体大小调整至最小，以确保代码细节清晰可见。书中还包含代码和配置的可流式文本格式展示，这有助于保持阅读流畅。但有时，为了保持代码列表的打印质量，会提供链接引导读者点击到高分辨率的图片格式，这种"点击此处查看代码图像"功能确保了专业级的代码呈现。返回前一页时，只需在设备或应用上点击后退按钮即可。此外，《Clean Architecture》可能还会涵盖诸如SOLID原则、依赖倒置原则、接口隔离原则等设计原则，以及如何通过遵循这些原则来构建模块化、可测试和可维护的架构。作者可能会提供实例和最佳实践，帮助读者理解如何在实际项目中实施这些理论。这本书不仅是一份技术指南，也是一本实践手册，旨在帮助读者掌握现代软件结构设计的艺术和技巧，使之能够在不断变化的技术环境中创建出结构清晰、易于理解和维护的软件产品。无论你是经验丰富的开发者还是刚入门的学习者，都能从中受益匪浅。"

The path we are most interested is the cleanest one. It recognizes the softness of software and aims to

preserve it as a first-class property of the system. It recognizes that we operate with incomplete

knowledge, but it also understands that, as humans, operating with incomplete knowledge is

something we do, something we’re good at. It plays more to our strengths than to our weaknesses. We

create things and we discover things. We ask questions and we run experiments. A good architecture

comes from understanding it more as a journey than as a destination, more as an ongoing process of

enquiry than as a frozen artifact.

Architecture is a hypothesis, that needs to be proven by implementation and measurement.

—Tom Gilb

To walk this path requires care and attention, thought and observation, practice and principle. This

might at first sound slow, but it’s all in the way that you walk.

The only way to go fast, is to go well.

—Robert C. Martin

Enjoy the journey.

—Kevlin Henney

May 2017

PREFACE

The title of this book is Clean Architecture. That’s an audacious name. Some would even call it

arrogant. So why did I choose that title, and why did I write this book?

I wrote my very first line of code in 1964, at the age of 12. The year is now 2016, so I have been

writing code for more than half a century. In that time, I have learned a few things about how to

structure software systems—things that I believe others would likely find valuable.

I learned these things by building many systems, both large and small. I have built small embedded

systems and large batch processing systems. I have built real-time systems and web systems. I have

built console apps, GUI apps, process control apps, games, accounting systems, telecommunications

systems, design tools, drawing apps, and many, many others.

I have built single-threaded apps, multithreaded apps, apps with few heavy-weight processes, apps

with many light-weight processes, multiprocessor apps, database apps, mathematical apps,

computational geometry apps, and many, many others.

I’ve built a lot of apps. I’ve built a lot of systems. And from them all, and by taking them all into

consideration, I’ve learned something startling.

The architecture rules are the same!

This is startling because the systems that I have built have all been so radically different. Why should

such different systems all share similar rules of architecture? My conclusion is that the rules of

software architecture are independent of every other variable.

This is even more startling when you consider the change that has taken place in hardware over the

same half-century. I started programming on machines the size of kitchen refrigerators that had half-

megahertz cycle times, 4K of core memory, 32K of disk memory, and a 10 character per second

teletype interface. I am writing this preface on a bus while touring in South Africa. I am using a

MacBook with four i7 cores running at 2.8 gigahertz each. It has 16 gigabytes of RAM, a terabyte of

SSD, and a 2880×1800 retina display capable of showing extremely high-definition video. The

difference in computational power is staggering. Any reasonable analysis will show that this

MacBook is at least 10

more powerful than those early computers that I started using half a century

ago.

Twenty-two orders of magnitude is a very large number. It is the number of angstroms from Earth to

Alpha-Centuri. It is the number of electrons in the change in your pocket or purse. And yet that number

—that number at least—is the computational power increase that I have experienced in my own

lifetime.

And with all that vast change in computational power, what has been the effect on the software I

write? It’s gotten bigger certainly. I used to think 2000 lines was a big program. After all, it was a full

box of cards that weighed 10 pounds. Now, however, a program isn’t really big until it exceeds

100,000 lines.

The software has also gotten much more performant. We can do things today that we could scarcely

dream about in the 1960s. The Forbin Project, The Moon Is a Harsh Mistress, and 2001: A Space

Odyssey all tried to imagine our current future, but missed the mark rather significantly. They all

imagined huge machines that gained sentience. What we have instead are impossibly small machines

that are still … just machines.{xx}

And there is one thing more about the software we have now, compared to the software from back

then: It’s made of the same stuff. It’s made of if statements, assignment statements, and while loops.

Oh, you might object and say that we’ve got much better languages and superior paradigms. After all,

we program in Java, or C#, or Ruby, and we use object-oriented design. True—and yet the code is

still just an assemblage of sequence, selection, and iteration, just as it was back in the 1960s and

1950s.

When you really look closely at the practice of programming computers, you realize that very little

has changed in 50 years. The languages have gotten a little better. The tools have gotten fantastically

better. But the basic building blocks of a computer program have not changed.

If I took a computer programmer from 1966 forward in time to 2016 and put her

in front of my

MacBook running IntelliJ and showed her Java, she might need 24 hours to recover from the shock.

But then she would be able to write the code. Java just isn’t that different from C, or even from

Fortran.

And if I transported you back to 1966 and showed you how to write and edit PDP-8 code by punching

paper tape on a 10 character per second teletype, you might need 24 hours to recover from the

disappointment. But then you would be able to write the code. The code just hasn’t changed that

much.

That’s the secret: This changelessness of the code is the reason that the rules of software architecture

are so consistent across system types. The rules of software architecture are the rules of ordering and

assembling the building blocks of programs. And since those building blocks are universal and

haven’t changed, the rules for ordering them are likewise universal and changeless.

Younger programmers might think this is nonsense. They might insist that everything is new and

different nowadays, that the rules of the past are past and gone. If that is what they think, they are

sadly mistaken. The rules have not changed. Despite all the new languages, and all the new

frameworks, and all the paradigms, the rules are the same now as they were when Alan Turing wrote

the first machine code in 1946.

剩余359页未读，继续阅读

柚子君.

粉丝: 3957
资源: 555

优化EPUB电子书结构：清洁架构与代码展示指南

语音三维语谱图(matlab实现)

Clean Architecture A Craftsman's Guide to Software Structure and Design azw3

Clean Architecture：软件架构与设计匠艺（英文版）

Clean Architecture: A Craftsman's Guide to Software Structure and Design

Clean Architecture: A Craftsman’s Guide to Software Structure and Design

Clean Architecture 干净的架构

Clean Architecture 2017 , Uncle Bob

霸屏天下源码java-Clean-Architecture-Notes:我在罗伯特·马丁(RobertMartin)所著的《清洁架构：软件结构

掌握软件架构：Clean Architecture 指南

软件架构的艺术： Clean Architecture 指南

最新资源