We also created a bunch of empty folders, which you can see on the side right now, for presentation, domain, and data.

我們還創建了一堆空文件夾，你現在可以在邊上看到，分別用於展示、域和數據。

This is for the Number Trivia app we are building.

這是我們正在開發的數字瑣事應用程序。

And now it's time to start filling in these empty folders with actual code, of course, using test-driven development.

現在是時候開始用實際代碼填充這些空文件夾了，當然要使用測試驅動開發。

Hello, welcome to ResoCoder, where you are getting prepared for real app development by building better, faster, more stable apps.

您好，歡迎來到 ResoCoder，在這裡，您將通過構建更好、更快、更穩定的應用程序，為真正的應用程序開發做好準備。

So subscribe and hit the bell if you want to grow your coding skills.

如果你想提高編碼技能，請訂閱並按鈴。

So, of course, whenever you are building an app, you should start with the UI and user experience first, but I've done that homework for you.

當然，無論何時創建應用程序，您都應該首先從用戶界面和用戶體驗入手，但我已經為您做了這方面的功課。

As you've seen in the previous tutorial, the app looks something like this.

正如您在前面的教程中所看到的，應用程序看起來是這樣的。

The app looks like this, the actual coding process, though, will happen from the innermost stable layers and will progress toward the outer layers.

應用程序看起來是這樣的，但實際的編碼過程將從最內層的穩定層開始，然後向外層推進。

So in the case of clean architecture, as it was proposed by Uncle Bob, we can see that we should start from the domain layer, particularly from entities.

是以，就鮑勃大叔提出的 "簡潔架構 "而言，我們可以看到，我們應該從領域層入手，尤其是從實體入手。

So we are going to create an entity right now.

是以，我們現在要創建一個實體。

Before we do that, though, before we can create an entity for the number trivia, we have to add some packages over to pubspec.yaml, because we are going to be using quite a lot of packages to make things easier for us, of course.

不過，在此之前，在為數字瑣事創建實體之前，我們必須在 pubspec.yaml 中添加一些套裝軟體，因為我們將使用大量套裝軟體來簡化工作。

And with that, I have to tell you to make sure you check out the written tutorial from the link in the description, where you can find all of the code written in this video, all of the links, and all of that good stuff.

是以，我必須告訴大家，請務必通過說明中的鏈接查看書面教程，在那裡你可以找到本視頻中編寫的所有代碼、所有鏈接以及所有好東西。

And go through this lesson at your own pace.

請按照自己的節奏來學習本課。

This pubspec.yaml file is one of the few things which I'm going to just copy and paste over on video so that I don't bore you to death.

這個 pubspec.yaml 文件是我要在視頻中複製粘貼的少數幾個文件之一，這樣就不會讓你覺得無聊了。

So let's just delete all of these unnecessary comments.

所以，還是把這些不必要的評論都刪掉吧。

We'll just clutter up the pubspec.yaml file.

我們只會讓 pubspec.yaml 文件變得雜亂無章。

And then the dependencies and dev dependencies will be the following.

然後，依賴項和開發依賴項如下。

So we have getit, which is the service locator.

我們有 getit，它是服務定位器。

I've added all of the dependencies right now so that we later do not have to come back to this yaml file and just lose time on that.

我現在已經添加了所有的依賴項，這樣我們以後就不必再回到這個 yaml 文件，以免浪費時間。

So we have getit.

所以我們得到了它。

Then we have flutter block for state management, equatable for value equality.

然後，我們用 flutter 塊來進行狀態管理，用 equatable 來實現值相等。

Then we are going to touch on some functional programming concepts.

然後，我們將學習一些函數式編程概念。

Then for remote API, we have connectivity and HTTP packages, of course.

當然，對於遠程 API，我們還有連接和 HTTP 包。

And for local cache, we are going to be using just simple shared preferences.

對於在地緩存，我們將使用簡單的共享首選項。

As for dev dependencies, these are the ones which do not get packaged together with your app once you build it.

至於開發依賴項，這些依賴項在您構建應用程序時不會與應用程序打包在一起。

We have flutter test.

我們進行了飄動測試。

This was here even before I think by default.

我想，這在默認情況下就已經存在了。

And then we have Mockito for creating mocks.

此外，我們還有用於創建模擬的 Mockito。

We are going to get to all of this as we progress forward with this tutorial.

隨著本教程的深入，我們將瞭解所有這些內容。

But just so that you have all of the packages already present, we've added them over here.

不過，為了讓大家能看到所有的套裝軟體，我們已經把它們添加到了這裡。

And I'm just going to delete all of the other comments so that they don't clutter up pubspec.

我將刪除所有其他評論，以免它們擾亂 Pubspec。

And here we go.

我們開始吧。

The pubspec.yaml file is completely finished.

pubspec.yaml 文件已全部完成。

All right.

好的

So let's now move on to creating the actual entity.

現在，讓我們開始創建實際的實體。

The first question we have to ask ourselves is what kind of data will the NumberTrivia operate with?

我們要問自己的第一個問題是，NumberTrivia 將使用什麼樣的數據？

Well, of course, with NumberTrivia entities.

當然，有了 NumberTrivia 實體。

So we can create a new file under the domain entities.

是以，我們可以在域實體下創建一個新文件。

Let's call it NumberTrivia.dart, of course.

當然，我們就叫它 NumberTrivia.dart。

And now we have to take a look at the JSON response from the API because based on that response, we are going to model our class here.

現在，我們必須查看一下來自 API 的 JSON 響應，因為根據該響應，我們將在這裡為我們的類建模。

So if you go to numbersapi.com forward slash 42 or some other number and then question mark JSON, so it's a query parameter, you will obtain the following response.

是以，如果您訪問 numbersapi.com 的正斜槓 42 或其他數字，然後用問號標記 JSON，將其作為一個查詢參數，您將得到以下響應。

And of course, this link is also available from the written tutorial.

當然，這個鏈接也可以從書面教程中獲取。

So this is the response which we will be operating with throughout our app.

是以，這就是我們將在整個應用程序中使用的響應。

And we need to model our NumberTrivia entity so that it can contain this kind of data.

我們需要為 NumberTrivia 實體建模，使其能夠包含此類數據。

So what do we actually really need from this JSON object?

那麼，我們到底需要這個 JSON 對象做什麼呢？

Well, we need the text, obviously, because that's the core, so to say, functionality of our NumberTrivia app.

顯然，我們需要文本，因為這是我們的 NumberTrivia 應用程序的核心功能。

We are going to store the number, but then we have two interesting fields, which are found and type.

我們要存儲的是數字，但還有兩個有趣的字段，分別是 "找到 "和 "類型"。

We are not going to need those at all because found is completely irrelevant for our case, and the type will be always trivia.

我們根本不需要這些，因為 "發現 "與我們的情況完全無關，而 "類型 "永遠是瑣事。

And why is found completely irrelevant?

為什麼發現完全無關緊要？

Well, if I search for a number other than 42, so for example, some complete gibberish long number, which doesn't have any entry in the numbers API and search for that, you can see that found is false, but we still obtain some kind of a reasonable response that this is an uninteresting number.

好吧，如果我搜索一個 42 以外的數字，例如，一個完全胡言亂語的長數字，在數字應用程序接口中沒有任何條目，然後搜索這個數字，你可以看到發現是假的，但我們仍然得到了某種合理的迴應，即這是一個無趣的數字。

So we can still display even this message to the user in the app.

是以，我們仍然可以在應用程序中向用戶顯示這條資訊。

We do not need to worry at all whether or not the number was found.

我們完全不必擔心號碼是否被找到。

So the bottom line is that we need the text and number fields to map to properties in our app.

是以，我們需要將文本和數字字段映射到應用程序中的屬性。

So let's create a class, NumberTrivia, which will extend Equatable.

是以，讓我們創建一個名為 NumberTrivia 的類，它將擴展 Equatable。

And let's import Equatable here.

讓我們在這裡導入 Equatable。

This is so that value equality is made simple because by default, Dart supports only referential equality.

這樣做的目的是使值相等變得簡單，因為默認情況下，Dart 只支持引用相等。

So even two objects which contain completely the same data will not be equal unless they are referencing to the same point in memory.

是以，即使是包含完全相同數據的兩個對象也不會相等，除非它們引用的是內存中的相同點。

With Equatable, this is completely changed.

有了 Equatable，情況就完全不同了。

When two objects contain the same values, the same data, they will be equal.

當兩個對象包含相同的值、相同的數據時，它們就會相等。

And we do not need to override equal operator or hash code, anything like that.

我們不需要覆蓋等號運算符或哈希代碼之類的東西。

Equatable does that for us.

Equatable 為我們做到了這一點。

So it saves us a bunch of boilerplate.

這樣就省去了一大堆模板。

And now we need to store the text and number.

現在我們需要存儲文本和數字。

So final string text, and then final int number.

所以是最終字符串文本，然後是最終 int 數字。

And of course, we need to put them into constructor.

當然，我們需要將它們放入構造函數中。

So we can just hit control dot, at least in VS code, and create constructor for all of these fields here.

是以，至少在 VS 代碼中，我們可以直接點擊控制點，為所有這些字段創建構造函數。

But we are not just going to have this kind of a constructor with unnamed arguments.

但我們並不打算只使用這種帶有未命名參數的構造函數。

We want to have them named.

我們希望為他們命名。

And of course, we are going to make them required.

當然，我們也會把它們變成必需品。

So we need to import meta package.

是以，我們需要導入元套裝軟體。

So meta dot Dart.

所以元點飛鏢。

And let's just make these required.

讓我們把這些變成必需品吧。

And also this one will be required here.

這裡也需要這個。

And we mustn't forget to pass these over to the super constructor, because Equatable needs to know which properties to make equality happen on.

我們不能忘記將這些屬性傳遞給超級構造函數，因為 Equatable 需要知道在哪些屬性上實現平等。

So we are going to pass them in as a list.

是以，我們要將它們作為一個列表傳入。

So we pass in text and also number to the super constructor, which is Equatable.

是以，我們將文本和數字傳遞給超級構造函數，也就是 Equatable。

And you may have noticed that we didn't do any test driven development here.

你可能已經注意到，我們在這裡沒有進行任何測試驅動開發。

That's because this class is really, it doesn't have any logic.

這是因為這個類實在是沒有任何邏輯可言。

There is why we aren't writing any tests for this number trivia entity.

這就是為什麼我們沒有為這個數字瑣事實體編寫任何測試的原因。

Should you have any logic inside your entity, you would write test even for entity, but that's not the case with this one.

如果您的實體內有任何邏輯，您甚至會為實體編寫測試，但這個實體並非如此。

All right, now let's talk about use cases.

好了，現在我們來談談使用案例。

They are where the business logic gets executed.

它們是執行業務邏輯的地方。

And sure, there won't be much logic in the number trivia app, because all a use case will do is to get data from a repository.

當然，數字瑣事應用程序中不會有太多邏輯，因為用例所做的只是從存儲庫中獲取數據。

So just so you can see that, here we go with the diagram.

所以，為了讓你看清楚，我們在這裡用圖表來說明。

We have use case here.

我們這裡有使用案例。

It will get data from the repository and they will communicate together through these entities.

它將從存儲庫中獲取數據，並通過這些實體進行通信。

And we have created just one such entity called number trivia a few moments ago.

剛才我們就創建了一個這樣的實體，叫做數字瑣事。

And we are going to have two use cases in our finished app, getConcreteNumberTrivia and getRandomNumberTrivia.

在我們完成的應用程序中，將有兩個用例：getConcreteNumberTrivia 和 getRandomNumberTrivia。

By looking at this diagram, as I've already said, you know that use cases get data from repositories, and then they pass that data, which in this case are entities, over to the presentation logic holders and to the whole presentation layer.

通過觀察這個圖表，正如我已經說過的，你會知道用例從存儲庫中獲取數據，然後將這些數據（在本例中是實體）傳遞給呈現邏輯持有者和整個呈現層。

So it kind of makes sense that when a use case is communicated with repositories, the repository should return an entity, right?

是以，當用例與資源庫通信時，資源庫應該返回一個實體，這也是合情合理的，對嗎？

But because we have to allow for asynchronous operations, we are going to wrap this entity, which in this case is number trivia, into a future.

但是，由於我們必須允許異步操作，所以我們要把這個實體（在本例中是數字瑣事）包裝成一個未來。

But that's not the actual case of what we are going to do.

但這並不是我們要做的實際情況。

We have to think about error handling as well, because is it the best choice to let exceptions freely propagate?

我們還必須考慮錯誤處理，因為讓異常自由傳播是否是最好的選擇？

Having to remember, and when you have to remember something, you know that that's not cool.

必須記住，而當你必須記住一些東西時，你就會知道那並不酷。

We have to remember to cache them somewhere else in the code if we let exceptions just nicely propagate at their own peril.

如果我們任由異常自顧自地傳播，就必須記住在代碼的其他地方緩存它們。

I do not think that this is the best choice.

我認為這不是最佳選擇。

Instead, we want to catch exceptions as early as possible inside the repository here, and then return failure objects from the repository methods.

相反，我們希望儘早在版本庫中捕獲異常，然後從版本庫方法中返回失敗對象。

So unlike exceptions, you will not have to try and catch all of these exceptions.

是以，與異常不同，您不必嘗試捕獲所有這些異常。

You will have failure objects, which are returned as regular objects, return types from methods.

您將從方法中獲得失敗對象（作為普通對象返回）和返回類型。

There will be no special error flow, nothing like that.

不會有特殊的錯誤流程，不會有類似的情況。

It will be just like a regular data flow without any kind of try-catch-finally blocks in the rest of the app from the repository upwards.

這就像一個普通的數據流，從存儲庫開始，應用程序的其他部分不會出現任何 try-catch-finally 塊。

So to recap, repository and then subsequently use cases will return both number trivia objects, and also they will return failure objects from their methods.

是以，概括地說，存儲庫和隨後的用例既會返回數字瑣事對象，也會從其方法中返回失敗對象。

So how is something like that possible?

那麼，這樣的事情怎麼可能發生呢？

How can we return number trivia or failure from the same method?

我們如何從同一個方法中返回數字瑣事或失敗？

Welcome functional programming, and that's why we have imported the darts package over to our app.

歡迎使用功能編程，這也是我們將飛鏢套裝軟體導入應用程序的原因。

This functional programming darts package allows us to simply use an either type.

這個函數式編程飛鏢套裝軟體允許我們簡單地使用任一類型。

While I will not pretend that I am some functional programming pro, at least not yet, you don't need to know any really advanced stuff about either type, which is a functional programming concept, will allow us to return either number trivia or failure, which we are going to create next.

雖然我不會假裝自己是函數式編程專家，至少現在還不是，但你不需要知道任何關於這兩種類型的高級知識，這是函數式編程的一個概念，它將允許我們返回數字瑣事或失敗，接下來我們將創建這兩種類型。

Obviously, we still do not have any failure classes.

顯然，我們仍然沒有任何不及格的班級。

So let's define them right now.

那麼我們現在就來定義它們。

We are going to create an error subfolder under core, and this will hold failures.dart.

我們將在 core 下創建一個錯誤子文件夾，其中將存放 failures.dart。

And the failure here will be really only a simple class.

而這裡的失敗其實只是一個簡單的類。

It will be abstract actually, because then later on, we are going to create some concrete implementations of failure objects.

實際上，它將是抽象的，因為稍後我們將創建一些故障對象的具體實現。

And again, we are not writing this in test-driven development manner, because there is nothing to test in an abstract class.

再說一遍，我們並不是以測試驅動開發的方式編寫的，因為抽象類中沒有什麼需要測試的。

So this will be abstract class failure.

是以，這將是抽象類的失敗。

Let's again extend equitable, so that the class is extending failure later on, should they have any fields like message or some error code or something like that, their equality will be able to be checked based on those fields.

讓我們再次擴展 equitable，這樣，該類在擴展失敗後，如果有任何字段，如消息或錯誤代碼之類的，就可以根據這些字段檢查它們的平等性。

So for that, to use equitable in this abstract base class, we have to have a constructor here, which will accept a list of properties, which will equal const dynamic, which will be an empty list.

是以，要在這個抽象基類中使用 equitable，我們必須在這裡設置一個構造函數，它將接受一個屬性列表，該列表等於 const dynamic，而 const dynamic 將是一個空列表。

And then we will pass this list of properties over to the super constructor.

然後，我們將把屬性列表傳遞給超級構造函數。

This is nothing really to worry about.

這其實沒什麼好擔心的。

This is just what's going on with this Dart analyzer.

這就是達特分析儀的工作原理。

This is just simply the way that things work with equitable.

這就是公平的工作方式。

So we pass in properties over to the super constructor.

是以，我們將屬性傳遞給超級構造函數。

And again, this is only an abstract class.

再說一遍，這只是一個抽象類。

We are going to create concrete classes in the next parts of this course.

我們將在本課程的後續部分創建具體的類。

Then as you hopefully remember from the last part, and as is signified by this diagram here, a repository from which a use case gets its data is both inside the domain layer and inside the data layer as well at the same time.

希望大家還記得上一部分的內容，正如本圖所示，用例從中獲取數據的存儲庫既位於領域層內部，也同時位於數據層內部。

Or to be more precise, the definition of a repository, or as we are going to call it, a repository's contract is present in the domain layer.

或者更準確地說，資源庫的定義，或者我們將稱之為資源庫的契約，就存在於領域層中。

This upper half of this gradient is pink or what is this color or whatever.

這個漸變的上半部分是粉紅色，或者是什麼顏色之類的。

And then the concrete implementation of a repository, this green side of the gradient is in the data layer.

然後是存儲庫的具體實施，梯度的綠色部分位於數據層。

This will allow for total independence of the domain layer.

這將使域層完全獨立。

But there is also another benefit, which we haven't talked about yet.

但還有一個好處，我們還沒有談到。

And that is testability.

這就是可測試性。

That's right.

這就對了。

Testability and separation of concerns go together extremely well.

可測試性和關注點分離這兩者結合得非常好。

And this is the absolute beauty of clean architecture because it really complements test-driven development because without architecture, you cannot even test anything because spaghetti code, believe it or not, cannot be tested.

這就是簡潔架構的絕對魅力所在，因為它是對測試驅動開發的真正補充，因為沒有架構，你甚至無法測試任何東西，因為意大利麵條代碼（信不信由你）是無法測試的。

How will this allow for this?

這將如何實現？

This will be an abstract repository class, will allow us to write tests, test-driven development style, of course, for the use cases, even without having an implementation of the repository.

這將是一個抽象的存儲庫類，允許我們為用例編寫測試，當然是測試驅動開發風格，甚至不需要存儲庫的實現。

Something like this is called mocking.

這樣的事情叫做嘲弄。

And we are, of course, going to get to that later on.

當然，我們稍後會討論這個問題。

For now, let's create the so-called contract of the repository.

現在，讓我們創建所謂的存儲庫合同。

Inside the domain folder, under repositories, let's create a new file, NumberTriviaRepository.dart.

在域文件夾下的存儲庫中，創建一個新文件 NumberTriviaRepository.dart。

And inside of here, we will have an abstract class, NumberTriviaRepository.

在這裡，我們將有一個抽象類 NumberTriviaRepository。

And this class will have the following interface.

該類將具有以下接口

We want to have two methods here, one for getting concrete number trivia, for which we have to pass in a number.

我們希望在這裡有兩個方法，一個用於獲取具體的數字瑣事，為此我們必須輸入一個數字。

And don't worry, I will come back to the return types in just a bit.

別擔心，我稍後會再談返回類型的問題。

So getConcreteNumberTrivia, int number.

是以，getConcreteNumberTrivia，int number。

If I could write number.

如果我能寫出數字

And then, of course, it's going to have getRandomNumberTrivia, which will not have any parameters.

當然，它還會有 getRandomNumberTrivia（隨機數字瑣事），但不帶任何參數。

So let's just rename concrete to random.

所以，我們就把 "具體 "改名為 "隨機 "吧。

And what is going to be its return type?

它的返回類型是什麼？

Well, we are going to use that either type, which I have described previously.

那麼，我們將使用我之前介紹過的這兩種類型。

So let's go bit by bit.

那我們就一點一點來吧。

It will, of course, still return a future, because it will be an asynchronous operation to get the concrete or data sources.

當然，它仍將返回一個 future，因為這將是一個獲取具體數據或數據源的異步操作。

And what's interesting is the type which the future will wrap.

有趣的是，未來的包裝會是什麼樣的。

It will be either, which comes from the darts package.

要麼是飛鏢包裡的。

So let's import that.

是以，讓我們導入它。

And then, either gets two type parameters.

然後，任一類型都會得到兩個類型參數。

One is left, so L, and R for right, of course.

一個是左，所以是 L，R 當然是右。

And the left side is always, for this kind of error handling, the failure.

對於這種錯誤處理，左側始終是失敗。

So let's import failure here.

所以，讓我們在這裡輸入失敗。

And the right side is always the success kind of data.

右側總是成功的數據。

So in this case, it will be the entity number trivia.

是以，在這種情況下，它將是實體數字瑣事。

And we, of course, need to import even that right over here.

當然，我們也需要把這些東西進口到這裡來。

And then this return type will be the same for getRandom number trivia.

然後，該返回類型將與 getRandom 數字瑣事的返回類型相同。

We will cover this in greater detail later on, how to actually work with this either type.