手游建筑美術(shù)資源

下面是命名的OOP方法，這我想在我的代碼遵循一個(gè)簡(jiǎn)單的原則：這是一個(gè)動(dòng)詞 ，如果它操縱 ，這是一個(gè)名詞 ，如果它的基礎(chǔ)之上 。 而已。 兩者之間什么都沒(méi)有。 諸如saveFile()或getTitle()不適合使用，必須重命名和重構(gòu)。 此外，“操作”的方法必須始終返回void ，例如print()或save() 。 讓我解釋。

首先，我必須說(shuō)，這種想法與Bertrand Meyer在他的《面向?qū)ο蟮能浖?gòu)造》一書(shū)中提出的想法非常相似，他在書(shū)中提出，我們將一個(gè)對(duì)象的方法分為兩個(gè)明顯分開(kāi)的類別：查詢和命令。

這個(gè)原理背后的思想是很哲學(xué)的。 讓我們從構(gòu)建器開(kāi)始，這些構(gòu)建器應(yīng)該創(chuàng)建或找到一個(gè)對(duì)象然后返回它。 假設(shè)我有一個(gè)書(shū)店，請(qǐng)我給我一本書(shū)的名字：

interface Bookshelf {Book find(String title); }

顯然，它是一個(gè)“構(gòu)建者”（或用邁耶的術(shù)語(yǔ)來(lái)說(shuō)是一個(gè)“查詢”）。 我要一本書(shū)，這本書(shū)已經(jīng)送給我了。 但是，問(wèn)題出在方法的名稱上。 它被稱為“查找”，這意味著我知道如何處理這本書(shū)。 將會(huì)發(fā)現(xiàn)。

但是，這不是我們應(yīng)該如何對(duì)待對(duì)象的方式。 我們絕不能告訴他們?nèi)绾巫鑫覀兿Ｍ麄冏龅墓ぷ鳌?取而代之的是，我們必須讓他們決定是要找到，構(gòu)造這本書(shū)，還是從內(nèi)存緩存中取出這本書(shū)。 查詢時(shí)，我們必須說(shuō)出要查找的結(jié)果，然后讓對(duì)象決定如何構(gòu)建該結(jié)果。 此方法更合適的名稱是book() ：

interface Bookshelf {Book book(String title); }

經(jīng)驗(yàn)法則是：構(gòu)建者始終是名詞。 如果該方法返回某些內(nèi)容，則必須為名詞。 最好其名稱應(yīng)說(shuō)明該方法返回的內(nèi)容。 如果是一本書(shū)，則將其命名為book() 。 如果是文件，則調(diào)用方法file()等。以下是一些好的構(gòu)建器示例：

interface Foo {float speed(Actor actor);Money salary(User user);File database();Date deadline(Project project, User user); }

相反，以下是一些名稱不正確的生成器的示例：

interface Foo {float calculateSpeed(Actor actor);Money getSalary(User user);File openDatabase();Date readDeadline(Project project, User user); }

在構(gòu)建者名稱中沒(méi)有動(dòng)詞的位置！

順便說(shuō)一句，不僅是名字。 由于其名稱不包含動(dòng)詞，因此構(gòu)建器不應(yīng)對(duì)封裝的實(shí)體進(jìn)行任何修改。 它只能創(chuàng)建或找到某些東西并將其返回。 就像純函數(shù)一樣 ，它一定不能有任何副作用。

接下來(lái)，有“操縱者”（或用邁耶的術(shù)語(yǔ)來(lái)說(shuō)是“命令”）。 它們?yōu)槲覀冏隽艘恍┕ぷ?#xff0c;修改了對(duì)象封裝的實(shí)體。 它們與構(gòu)建者相反，因?yàn)樗鼈儗?shí)際上是對(duì)由對(duì)象抽象的世界進(jìn)行更改。 例如，我們要求Bookshelf向其添加一本新書(shū)：

interface Bookshelf {void add(Book book); }

該方法將書(shū)籍添加到存儲(chǔ)中。 我們不知道存儲(chǔ)將如何修改。 但是我們知道，由于方法的名稱是動(dòng)詞，因此會(huì)進(jìn)行修改。

而且，操縱器不得返回任何東西。 我們將其視為回應(yīng)的類型始終是void 。 這主要是為了將代碼的命令性部分與聲明性部分分開(kāi)。 我們要么接收對(duì)象，要么告訴他們?cè)撛趺醋觥?我們絕不能將這些活動(dòng)混為一談。

這些規(guī)則的目的是使代碼更簡(jiǎn)單。 如果您遵循它們，并且所有構(gòu)建器僅返回對(duì)象，而機(jī)械手僅修改世界，則整個(gè)設(shè)計(jì)將變得更易于理解。 方法將更小，其名稱更短。

當(dāng)然，通常很難找到這些名稱。 有時(shí)，您可能想從操縱器返回某些東西，或者讓您的構(gòu)建器進(jìn)行一些更改，例如對(duì)緩存進(jìn)行更改。 嘗試抵制這種誘惑并堅(jiān)持原則：方法要么是構(gòu)建器，要么是操縱器，中間沒(méi)有東西。 上面的示例相當(dāng)原始，現(xiàn)實(shí)生活中的代碼要復(fù)雜得多。 但這就是原理將幫助我們的事情-使代碼更簡(jiǎn)單。

我也知道名詞/動(dòng)詞原則，該原則建議始終將類命名為名詞，并將其方法命名為動(dòng)詞。 我認(rèn)為這是一個(gè)錯(cuò)誤的主意，因?yàn)樗粫?huì)將制造商與操作員區(qū)分開(kāi)，并鼓勵(lì)我們始終根據(jù)命令性指令進(jìn)行思考。 我相信，即使我們有時(shí)不得不從其他對(duì)象獲取它們，而不是通過(guò)構(gòu)造函數(shù)實(shí)例化它們，OOP也必須更多地涉及對(duì)象的聲明性組合。 這就是為什么我們?cè)诖蠖鄶?shù)情況下確實(shí)需要構(gòu)建器的原因，并且還必須看到它們與其他方法（操縱器）之間的明顯區(qū)別。

翻譯自: https://www.javacodegeeks.com/2018/08/builders-and-manipulators.html

手游建筑美術(shù)資源

總結(jié)

以上是生活随笔為你收集整理的手游建筑美术资源_建筑商和机械手的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。