2014-01-05 57 views
0

有人在IRC上告訴我,這是不好用類作爲包裝 - 其中有人,我認爲他有蟒蛇
一些經驗,我從.NET是它是使用包裝類常見的做法包裝類是'壞'嗎?

爲什麼使用包裝類應該是不好的風格?

當然,我可以使用tulpe - 但我看不到它的任何好處。
作爲volcano說,tulpes也不可改變
此外,他們是不可繼承

包裝類

class Movie(object): 
    def __init__(self): 
     self.title = '' 
     self.plot = '' 
     ... 
    # no functions/methods in here - only variables 

使用Movie該類

class Foo(object): 
    def bar(self): 
     movie = Movie() 
     movie.title = 'Ice Age' 
+0

這看起來像['namedtuple']的工作(http://docs.python.org/2/library/collections.html#collections.namedtuple)。 – user2357112

+2

@ user2357112,取決於。 namedtuple是不可變的 – volcano

+0

如果你沒有使用'class'作爲合適的類,那麼你將它有效地用作命名空間,並且類的命名空間部分實際上是一個'dict' ....所以你可能會以及使用:'電影= {'標題':'冰河時代'}'並使用'['標題']'訪問(如果你真的想要的話,你可以使用支持屬性訪問的'dict'的變體)。 。如果你想要限制屬性的創建,那麼你可以使用'__slots__'類,或者有其他方法來處理其他行爲,但是除非它是一個實際的類,否則你幾乎肯定不需要一個Movie類(如圖所示)。 ... –

回答

0

內如果包裹每個屬性只是一個對象對象 - 這似乎有點無用。特別是在Python中,您可以動態地將屬性添加到對象/類。 如果你想「包裝」的多個對象 - 詞典/名單看起來就像一個自然的選擇

+0

也許沒用 - 但不是'壞'...? – Lucas

+0

@Lucas,當您無故添加數據引用級別時,通常會影響執行時間。對於可能不好的真實代碼。 – volcano

1

你看這一個公平位與SQLAlchemy的,其中一個模型可以被定義爲:

class Note(Base): 
    __tablename__ = 'notes' 
    id = Column(Integer, primary_key=True) 
    name = Column(Text, unique=True) 
    html = Column(Text) 
    created = Column(DateTime) 
    tags = relationship('Tag', secondary=note_tags) 

class Tag(Base): 
    __tablename__ = 'tags' 
    id = Column(Integer, primary_key=True) 
    name = Column(Text, unique=True) 

...然後存在一個輔助類,並在其上進行各種操作,以便通過查看一個文件中的類可以輕鬆理解該模型,而不是分散在下面的分散輔助函數。

我不明白爲什麼這是一個可怕的想法的任何特定原因。

通常,您不應該使用類函數。這可能是評論起源的地方?名稱空間(模塊)已經執行了該角色。

即。如果你有一個類Foo,而你經常使用:

package.Foo.bar(...) 

簡單的地方了吧方法直接在包裝內,並使用它像這樣:

package.bar(...) 

有沒有必要把在一個班上這樣的功能;這是一個非常常見的c#模式。 ......但它只適用於類函數,以及靜態函數,這些靜態函數沒有任何真正意義上的理由讓它們附加到類上。

1

我可能是錯的,但評論可能會針對避免anemic domain model,如突出hated by Martin Fowler。總之,那些人提出這樣的問題:「爲什麼首先使用面向對象,反正你只使用DTO。 DTO是數據傳輸對象,即沒有行爲的對象,更像結構。那些傢伙喜歡有entities and value objects

儘管你的朋友意味着什麼,但很難說清楚,因爲在面向對象設計方面有許多想法。

事實上,你的包裝器確實缺乏存在的理由。它目前的功能也可以由構造函數或工廠函數/方法處理,也可以作爲Movie的類方法處理。如果您打算使用包裝通常將行爲與數據分開,請參閱上面的討論,並選擇一邊。 ;)