我指的是我在類中具有不同功能的情況，將其分解為較小的類是沒有意義的。
比如在Python中，我個人喜歡用
class DataStream:
################################
# Read stream functionality
################################
def read():
pass
def decode():
pass
################################
# Parse stream functionality
################################
def exract_data():
pass
def map_data_types():
pass
################################
# Analyze functionality
################################
def aggregated_data():
pass
def deduce_insights():
pass
AFAIK，沒有關于此類評論的約定。
在 Java 中有這樣的約定嗎？或者任何 Intellij 可以從中制作出有用的東西的格式？例如，如果 Intellij 能夠折疊這些部分，那就太好了。
uj5u.com熱心網友回復：
與其依賴于在源代碼中將相關的函式方法分組并指示與代碼注釋的關系，不如以利用語言特性并使目的明確的方式設計和實作代碼。
例如，您可以使用不同的類來實作，而不是將烹飪方法和烘焙方法分組在同一個類中：
public class BakingOven{
public Result bakeBread(){
}
public Result bakeCake(){
}
}
public class FryingPan{
public Result fryChicken(){
}
public Result frySteak(){
}
}
這可以通過將要烘焙或油炸的內容作為引數傳遞來進一步實作，或者您可以識別常見的介面，如 Fry 或 Bake，并讓類實作這些介面。
這更多是一種設計，以及如何更清晰地構建代碼的問題型別，而不是將其視為檔案型別的問題。
uj5u.com熱心網友回復：
您的示例中存在一些基本問題。
class Kitchen:
################################
# Getters/Setters
################################
def get_groceries():
pass
################################
# Cooking Methods
################################
def cook_chicken():
pass
def cook_pasta():
pass
################################
# Baking Methods
################################
def bake_bread():
pass
def bake_cake():
pass
首先Kitchen不要買雜貨。這意味著你的 Kitchen 在某些方面更像是一個資料結構，而不是一個物件；因為，您將雜貨暴露在廚房可能應該做的其他事情上。
其次，您正在創建復合方法，這樣您需要烹飪或烘焙的每個新專案都需要一種新方法。這是不好的命名實踐，因為這意味著如果Kitchen不重新編譯代碼就無法擴展。
def cook( recipe ):
將是一個更好的設計，因為它可以采用任何食譜并進行烹飪。
最后，烘焙和烹飪是同一種轉化，它們都將原料轉化為可食用的成品。由于歷史和技術的原因，它們往往有不同的名稱；但是，烹飪一條面包是一種非常有效的表達烤面包的高級方式（就像將自己運送到商店是說步行到商店的一種完全有效的方式一樣）。
所以你的整體類設計可能應該是：
class Kitchen:
def add( grocery )
def use( grocery )
def cook( recipe )
現在這個類更小，設計更好，可擴展且更易于除錯，為了完成圖片，讓我們實作雞肉、意大利面、面包和蛋糕的食譜：
interface Recipe:
abstract def cook():
class ChickenRecipe implements Recipe:
def cook(Kitchen kitchen):
kitchen.use("chicken breast")
kitchen.use("oil")
kitchen.use("salt")
kitchen.use("pepper")
return "cooked chicken"
class PastaRecipe implements Recipe:
def cook(Kitchen kitchen):
kitchen.use("pasta")
kitchen.use("water")
kitchen.use("salt")
kitchen.use("oil")
return"cooked pasta"
class BreadRecipe implements Recipe:
def cook(Kitchen kitchen):
kitchen.use("flour")
kitchen.use("water")
kitchen.use("salt")
kitchen.use("yeast")
return "bread"
class CakeRecipe implments Recipe:
def cook(Kitchen kitchen):
kitchen.use("flour")
kitchen.use("water")
kitchen.use("salt")
kitchen.use("sugar")
kitchen.use("butter")
return "cake"
現在，為了評估這種方法是否有用，讓我們問以下問題：
- 您可以在看到廚房和任何特定食譜后實施另一個食譜嗎？
- 您需要閱讀多少檔案才能制作新食譜？
- 即使烹飪技術不屬于兩個類別（烹飪和烘焙），您是否可以添加新專案來烹飪？
- 界面是否強迫您按照設計使用它？（與將所有物品從廚房中取出然后放入煮熟的物品相反）
如果你有一堆相關的方法，有時你不需要注釋來說明它們是相關的，你有一個介面，你沒有像介面那樣編碼。例如，你可以很容易地完成一個cook和一bake組方法，帶引數。雖然這可能更好地滿足英語的規則，但它實際上并沒有增加功能，而且它是一種不太有效的設計，因為您可以選擇使用錯誤的界面。
轉載請註明出處，本文鏈接：https://www.uj5u.com/gongcheng/370419.html