假設沒有，將普通代碼移動到基類是否是一個好習慣？

我需要打印定期報告和批量報告。我正在使用podofo庫。我打算爲每個報告使用不同的類，但每個類都需要下面的一些通用函數（現在在另一個項目的一個類中）。假設沒有，將普通代碼移動到基類是否是一個好習慣？

int CPdfBatchReport::CalculateMaxRowsInEmptyPage(void) 
{ 
    int rows = MaxPageHeight/PDF_TABLE_STANDARD_ROW_HEIGHT; 

    // because the first will always be the column header in every page, we substrct 1 to account for that 
    rows = rows - 1; 

    return rows; 
} 

// Calculates the max rows in current page. The current page is determined 
// by the current x, y position 
int CPdfBatchReport::CalculateMaxRowsInCurrentPage(void) 
{ 
    float AvailablePageHeight = pPage->GetPageSize().GetHeight() - PDF_BOTTOM_MARGIN - y; 

    int rows = AvailablePageHeight/PDF_TABLE_STANDARD_ROW_HEIGHT; 

    // because the first will always be the column header in every page, we substrct 1 to account for that 
    rows = rows - 1; 

    return rows; 
} 


void CPdfBatchReport::StartPage(void) 
{ 
    x = PDF_LEFT_RIGHT_MARGIN; 
    y = PDF_TOP_MARGIN; 
}

用這個通用代碼創建基類並在派生類中進行實際打印是否有意義？這是一個好習慣嗎？

所以基本上我會有基類說PrintBase與它上面的函數和它的兩個派生類PrintBatchReport和PrintItemReport這實際上將使用這些函數。

來源

2015-09-28 zar

是的，絕對是一個好主意，將通用代碼放在基類中。「不要重複自己」 - 乾燥 - 是一種很好的編程風格。避免複製粘貼編程。

唯一不希望基類中的內容是當它是接口類時。但在這種情況下似乎並不是這種情況。

來源

2015-09-28 21:28:55

謝謝，但我確實認爲我也會做基礎接口類。像基類上的'print（）'方法一樣可以打印批處理報告或簡單報告。通過接口類，我的意思是它可以有純虛函數和常規函數，爲什麼這不好？它似乎會做的很好！ – zar

對，所以真正的接口類和具有虛擬功能的常規基類是有區別的。真正的接口類沒有數據成員，也沒有實現的功能。一個可以有成員和實現函數的基類。只有當一個類繼承了多個基類（多重繼承）時，才真正需要擁有一個真正的接口類，此時沒有數據成員，只有未實現的函數纔有助於使接口「純」。 –

「繼承的構成」，我想 – ggrr

是的，絕對是一個好主意，將通用代碼放在基類中。

我想展開@Mats的答案。只要您提取到基類中的所有代碼都遵循單一責任原則，這真是一個好主意。避免盲目使用繼承進行常見的代碼提取。面向對象的編程不止於此。

想想責任。在許多情況下，你應該贊成合成而不是繼承。你真的需要任何父母課程來完成你的任務嗎？可能的是，現有的功能跨越了幾個職責，並可以分成幾個類，您可以將其傳入或實例化到其中。

來源

2015-10-09 09:03:29

這似乎是一個完全合理的解決方案。在這種情況下，你繼承了一個通用的實現，所以我強烈建議使用私有繼承而不是公有的。然後你只是實例化正確的子類來完成這項工作。這肯定比在多個類中複製代碼更好。

另一種選擇是將通用參數/功能封裝到第三個類中，並且每個特定報告都具有這些類中的一個，將各種職責委託給幫助類。

來源

2016-04-06 16:07:01

假設沒有，將普通代碼移動到基類是否是一個好習慣？

回答

相關問題