何时重构？

因此,我写了我的第一个Python应用程序,其大小不但很小,而且我按程序进行了操作,因为这是迄今为止我最能吸收的信息.我现在想对其进行重构,以尝试并(最终)理解类和OOP.我的问题是有关从一个简单的开始就设计课程的最佳实践.

假设我有一个应用程序可以模拟空头认沽期权的投资组合.这意味着在任何给定的时间,我都可以拥有由空头看跌期权和多头股票(来自后来行使/分配的空头期权)组成的投资组合(容器).

因此,就名词而言,正在发生很多事情.有适用于任何股权期权的数据/属性/方法,特定于看跌期权的数据/属性/方法(相对于看涨期权)和特定于短期看跌期权的数据/属性/方法(相对于长期看跌期权) .从概念上讲,我可以拥有：

class Option(object):
    """Describes an Option"""
    pass

class Put(option):
    """Describes an Option that is a Put"""
    pass

class Call(option):
    """Describes an Option that is a Call"""
    pass

class ShortPut(Put):
    """Describes a Put that is written (sold short)"""
    pass

class LongPut(Put):
    """Describes a Put that is purchased"""
    pass

class ShortCall(Call):
    """Describes a Put that is written (sold short)"""
    pass

class LongCall(Call):
    """Describes a Put that is purchased"""
    pass

# then more classes to describe stocks, holdings of a 
# given quantity of a stock or option at a specific price 
# on a specific date, and a portfolio to contain all the 
# holdings etc etc 

我正在走向完整的分类法.也许继承太多,我读过的继承可能是一件坏事.但是它确实描述了一个对象,并且随着添加了其他/不同的属性而允许不同的行为/数据.但是,感觉就像我有大量的脚手架,什么也不做,因为我可以仅用ShortPut对象来描述此阶段所需的一切.

另外,我一直非常专注于学习良好的单元测试,使事情保持简单并随需而建.所以实际上我认为它应该像这样：

class ShortPut(object):
    """Describes a short put"""
    pass

这是我目前在模拟中唯一的选择,因此我将其视为“接口”.在我看来,如果我正确地封装了这个对象,那么我只能从这个对象开始,然后等待重构为某种更大的分类法.例如,如果以后需要长卖权,那么我将在这个新对象内重复进行卖权描述,这将违反DRY.因此,我将创建一个更高级别的(基类)来保存通用代码,并使用单独的继承类描述行为上的差异：

class Put(object):
    """Describes an Option that is a Put"""
    pass

class ShortPut(Put):
    """Describes a Put that is written (sold short)"""
    pass

class LongPut(Put):
    """Describes a Put that is purchased"""
    pass

然后,随着我的描述和用例变得越来越复杂,我可以继续执行递归过程.但是,如果封装正确,我的目标应该是永远不需要调整任何“下游”代码-当我想要ShortPut时,无论其复杂程度和分布如何,我都应能够继续发出相同的请求.最后,我代码中的所有内容实际上都与预期结果有关,因此单元测试对结果有意义.

我是否在正确考虑这个问题？对我来说,这似乎很明显,但是后来我不得不撕掉我过去写的很多东西,因为我原来认为“显而易见”的东西完全是错误的.如果这看起来太基础,或者我没有完全理解所有术语,我深表歉意-我仍在学习.我阅读的所有内容都集中在有关如何设计类和说明诸如继承或重载之类的概念的简短示例上,但是我并没有太多地考虑如何简单地着眼于未来的复杂性或可扩展性.谢谢！

解决方法:

Am I thinking about this problem correctly?

差不多了尤其是如果您是刚接触OOP的人,则不应基于概念上的纯正性或完整性将结构强加到代码中. “编写良好的单元测试,使事情简单并按需构建”通常是编写(Python)程序的好方法.但是,不要指望永远不必在整个代码库中更改界面并追逐破坏的用法,这不仅是“构建”,而且有时是“随行就破坏和重建”.

标签：oop,encapsulation,python
来源： https://codeday.me/bug/20191122/2056895.html