這是不好的風格？

Question

我最後寫一些代碼雲：

Asteroid *a = new Asteroid(asteroidCollection) ; 

而事實證明，我並不需要變量a，因爲在Asteroid構造函數中，new Asteroid最終將自身添加到asteroidCollection。

所以我最終能夠寫出：

new Asteroid(asteroidCollection) ; 

這是不良作風，考慮到我也不需要回報？我應該讓

asteroidCollection->createNew() ; 

或者

asteroidCollection->add(new Asteroid()) ; 

？

Answer 1

我會說這是不好的風格，因爲它在閱讀代碼時很混亂。首先想到的是你有內存泄漏。只有在查看構造函數的內部並弄清楚該對象將自己添加到稍後要移除的某個列表後，混淆纔會蒸發。

也想到可能的例外情況。將分配的對象存儲在某種智能指針中然後將其添加到集合中會更好。

Answer 2

你的問題，我寧願

asteroidCollection->add(new Asteroid()) ; 

比其他兩種風格。

它比第一更好，因爲new Asteroid(asteroidCollection) ;並不比類似

Foo(barCollection); 

其中foo是一個類更好，你new在其構造一個酒吧對象，並將其添加到集合，它太晦澀知道發生了什麼事。

它也比第二個好，因爲IMO asteroidCollection不應該關心如何創建的Asteroid，它是一個集合，以便做什麼藏品做。

Answer 3

這看起來確實有問題，是誰管理小行星的壽命？

它真的在小行星的使用者和集合之間共享，如果是這樣的話，你應該有一個shared_ptr給小行星，讓最後一個人把它清理乾淨。

如果無法將小行星放入小行星集合中，則無法創建小行星，那麼集合就擁有了一生。

如果你在棧上創建一個小行星會發生什麼？如果我堅持在那的unique_ptr小行星或shared_ptr的，而不是直接調用新會發生什麼，例如：

auto asteroid = std::make_shared(asteroidCollection) 

將它被刪除兩次？

如果你不想讓任何人對小行星做任何事情，那麼對小行星集合createAsteroid或addAsteroid的方法可能更合適。簡單地調用createNew方法聽起來像是在創建一個新的AsteroidCollection，我認爲這不是你想要的。

Answer 4

風格問題總是有點主觀。所以在某些方面我有點像回答他們。這是我的2美分...

只要考慮一下，你想能夠創建從Asteroid派生的對象，並將它們添加到您的收藏。如果add()方法恰巧調用Asteroid上可能是（或使用）虛函數的任何函數，那麼您可以打開自己以訪問尚未完全構建的對象的可能性。

我認爲，在構造函數中執行一些像這樣的操作讓用戶理解發生了什麼是令人困惑的。

我寧願只做一個簡單的功能。它甚至沒有成爲一個類的一部分...

Asteroid *CreateAsteroid(AsteroidCollection *coll) 
{ 
    Asteroid * a = new Asteroid(); 
    coll->add(a); 
    return a; 
} 

如果你確實想留在你的構造方法，你至少可以把你原來的代碼行此功能，並評論其一個非常明確的描述正在發生的事情。

基本上，儘量不要在幕後做有趣的事情。如果這是不可避免的（或者在某種程度上可取的話），儘量不要強迫編碼人員理解這種古怪，無論這個編碼器是你還是其他人。

至少在這種情況下，它不是真的那奇怪。事情可能會更糟！ =）

只是爲了把你的最後兩個例子......

1. asteroidCollection->createNew();

2. asteroidCollection->add(new Asteroid());

我認爲1號是好的，如果你知道它總是一個類型Asteroid正在創建，並且你不希望你的班級的用戶擔心它。如果Asteroid無法在集合中共享，則執行此操作是有意義的。這與我所建議的功能類似，但是這種集合類可能會提供支持代碼，而這些代碼可能不應該。

如果您可以存儲派生的Asteroid類型，或者在將小行星添加到集合之前想對小行星做特別的事情，則2號碼非常有用。這是所有三種方法中最靈活的。