2 回答

TA貢獻1804條經(jīng)驗 獲得超2個贊
對象為自己負責
通常在面向對象編程 (OOP) 中,我們希望對象對自己負責。應該在內(nèi)部處理有關其內(nèi)部狀態(tài)完整性的業(yè)務規(guī)則(或委托給構建者——見下文)。這個想法是 OOP 中正式稱為封裝的一部分。
所以在你的例子中,Professor班級不應該擔心Student班級的規(guī)則,比如學生姓名的長度。該Student級應執(zhí)行其自身的完整性。我們希望這些完整性規(guī)則的邏輯位于一個地方,而不是分散在整個應用程序中。
事實上,Professor類不應該實例化Student對象。在您的示例中暗示,必須有其他方將學生分配給教授。也許是一個Tutorial負責跟蹤由教授監(jiān)督的幾個學生的作業(yè)和進度的對象。這Tutorial應該是實例化Student對象,或者傳遞Student從其他來源(例如數(shù)據(jù)庫服務對象)接收的對象。
當Student對象到達 時Professor,它們應該是有效的。本Professor類不應該是什么讓一個被關注Student的有效與否。該Professor只應是什么讓一個有關Professor有效。
class Professor{
List< Student > students;
…
public void addStudent( Student student ){
Objects.requireNonNull( student , "Received NULL rather than a Student object. Message # 68a0ff63-8379-4e4c-850f-e4e06bd8378a." ) ; // Throw an exception if passed a null object.
Objects.requireNonNull( this.students , "Collection of Student objects is NULL. Message # c22d7b22-b450-4122-a4d6-61f92129569a." ) ; // Throw an exception if the `students` list is not established.
this.students.add( student ) ;
}
}
除了對象對自己負責的想法之外Professor,不實例化Student對象的另一個原因是方便測試。如果Student對象來自某個其他來源,則該來源可以使用尚未完成、禁用某些功能(例如數(shù)據(jù)庫訪問)或被設計用于測試場景的虛假數(shù)據(jù)替代的類或接口提供虛假對象Student。
建造者模式
如果您有多個需要驗證才能實例化新對象的屬性,您可能需要使用Builder 模式。您定義了一個額外的類,例如,StudentBuilder它具有為學生所需的每個部分的方法。
通常,這些方法都返回相同的StudentBuilder對象以方便調(diào)用鏈。
不同的人對建筑商有不同的風格。一種方法是提供一種有效性檢查方法,或者一種提供阻止構建所需對象的問題列表的方法。
有些人使用 likewith而不是 accessor 方法set來表明,雖然我們暫時在構建器上設置一個屬性,但真正的意圖是在另一個類的對象上設置一個屬性。
StudentBuilder sb = new StudentBuilder().withFirstName( "Alice" ).withLastName( "Coleman" ).withEmail( "x@y.com" );
if( sb.isValid() ) {
Student s = sb.build() ;
…
}

TA貢獻1815條經(jīng)驗 獲得超10個贊
在簡單的程序中,沒有太大關系。在復雜的應用中,有許多因素決定了這一點:
在某些情況下,具有無效值的對象是否仍然存在?(即使它們包含無效值,它們是否有意義?)
驗證很貴嗎?(是否需要計算、網(wǎng)絡連接或數(shù)據(jù)庫操作?)
可以驗證嗎?(我們是否已經(jīng)擁有驗證所需的所有信息?)
驗證是否有自己的階段,在這個階段與其他對象一起驗證或針對其他對象進行驗證?
是否有現(xiàn)有的約定或要求?
等等...
因此,大多數(shù)情況下,這將由架構或設計約束或與更大應用程序相關的其他因素決定。在非常小的程序中,您可能找不到任何決定驗證最佳位置的因素。
在上面顯示的示例對象創(chuàng)建代碼中,您通常不會默默地跳過超過 20 個字符的值,但在這種情況下通常會拋出異常。如果這是數(shù)據(jù)處理而不是有意過濾短于 20 個字符的記錄,您不想默默地忽略不合適的記錄。(想象一下,誰會手動檢查為什么在 1000 條記錄的集合中,有 5 條記錄丟失了,并且沒有錯誤消息表明出了什么問題。所以你可能會看到,上述方法無論如何都沒有實際使用。)
添加回答
舉報