Python OO程序结构规划 [英] Python OO program structure planning

问题描述

我是OOP的初学者，我想创建一个包含三个类A，B和C的程序。该类的每个实例都由一组特征Achar1，Achar2等定义。

该程序应该创建包含A元素，B元素和C元素的开始和结束日期的 。有A和B的子类，所以A的某些元素只能连接到B的某些元素。程序的主要功能是列出A，B和C的元素及其贡献，列表使用，并建议新的使用，将使用最少的类的实例避免重复。

我的第一本能就是使用三字典A，B和C以及使用字典。这似乎是直观和易于导入/导出到json或类似的。我试图重写它来使用类，但是我看不到有什么收获：这是很难（？）迭代类的实例，并且它们基本上是字典，因为这个数据不需要太多的其他。 p>

我做错了什么？从字典切换到对象可以获得什么？

编辑：有问题的代码（基于dict的）是 here 。第一个版本，我试图使其面向对象是 here 。

解决方案

从字典切换到对象可以获得什么？

这是一个非常大的问题。

在Python中，一个对象在语义上等同于一个字典是正确的，因为一个对象几乎是相当于它的 __ dict __ 属性（我不会详细说明这个几乎在这里，因为它是远离主题）。

我看到使用类而不是字典的两个主要好处：抽象和舒适。

抽象

当您处于设计阶段时，特别是对于中短程序，您通常希望在思考时编写代码的框架。

在某种情况下你需要建立互动模型S比自然想到在课堂上，因为它是中途演讲和编程之间。

这使得它更容易了解自己的问题。此外，它大大提高了您的代码的可读性，因为它似乎是自然的，即使读者不知道你的代码。

这带来了你的概念，如继承和多态性，丰富了OOP提供的抽象。

Comfort

Python的许多优点之一是数据模型。丰富的魔法方法和属性允许您使用非常简单的语法。另外，它可以在你的地方照顾一些操作。

以下是Python 中命令式和面向对象编程之间的一些比较。

当然，Python中的一切都是一个对象，所以我将使用点调用（ foo.bar（） ）

文件阅读

命令式

  f1 = open（in_path，'r'）
 f2 = open（out_path，'w'）
在f1中的行：
 processed = process（line）
 f2.write（processed）
 
＃糟糕，我忘了关闭我的文件... 
  

面向对象的方式

  with open（in_path，'r'）as f1，open（out_path，'w'）as f2：
 for line for f1：
 processed = process（line）
 f2.write （处理）
 
＃我没有收我的文件，巨蟒为我做
  

请注意在F线是一个广泛使用Python的面向对象数据模型的。想象一下，如果这个语法不存在，那么这个痛苦就好了（只需在C中尝试一下）。

空白测试

命令式

 如果len（some_list）== 0：
 print（空列表）
  

面向对象的方式

  if some_list：
 print（empty list）
  

序列上的迭代

强制性方式

  i = 0 
，而i < len（some_sequence）：
 print（some_sequence [i]）
i + = 1 
  

面向对象的方式

  for elt in some_sequence：
 print（elt）
  

---

但是，这个数据模型的实力是它可以让你重新定义很多魔法属性。例如，您可以通过实现 __ lt __ ， __ le __ 等等，使复杂的东西相媲美，这将重新定义行为的< ，< = 等等。此后，内置函数如 min ， max 或 sort 会理解如何比较你的对象。

这就是说，在各种各样的情况下，使用纯粹的字典就足够了。

在一天结束的时候，OOP只是一个范例，而命令式编程只是一样好。

I'm a beginner in OOP and I want to create a program with three classes, A, B, and C. Each instance of the class is defined by a set of characteristics, Achar1, Achar2 etc.

The program is supposed to create uses comprising of element of A, element of B and element of C with begin and end date. There are subclasses of A and B, so that some elements of A can only be connected to certain elements of B. The main functionality of the program is to list elements of A, B and C with their aributes, list uses and suggest new uses that would emply the instances of classes used the least to avoid repetition.

My first instinct is to use three dictionaries A, B and C and a dictionary for uses. This seems intuitive and easy to import/export into json or similar. I tried to rewrite it to employ classes, but I can't see any gain in doing so: it's hard (?) to iterate over instances of classes and also they basically are dictionaries since this data doesn't need much else.

What am I doing wrong? What can I gain from switching from dictionaries to objects?

Edit: the code in question (dict-based) is here. The first version, where I tried to make it object oriented is here.

解决方案

What can you gain from switching from dictionaries to objects?

This is a pretty vast question.

It is right, in Python, that an object is semantically equivalent to a dictionary, since an object is almost equivalent to its __dict__ attribute (I will not detail this "almost" here, since it is far off the topic).

I see two main benefits from using classes instead of dictionaries: abstraction, and comfort.

Abstraction

When you are in the design phase, especially for short to medium length programs, you generally want to write the skeleton of your code while thinking.

In a situation where you need to model interactions, it's more natural to think in classes, because it's halfway between speaking and programming.

This makes it easier to understand your own problematic. In addition, it greatly improves the readability of your code, because it seems natural, even when the reader does not know anything about your code.

This brings you concepts such as inheritance and polymorphism, that enrich the abstraction offered by OOP.

Comfort

One of Python's many strengths is its data model. The plenty magic methods and attributes allow you to use very simple syntaxes. In addition, it can take care of some operations in your place.

Here are some comparisons between imperative and object-oriented programming in Python.

Of course, everything in Python is an object, so I will use dot calls (foo.bar()) even in imperative examples.

Files reading

Imperative way

f1 = open(in_path, 'r')
f2 = open(out_path, 'w')
for line in f1:
    processed = process(line)
    f2.write(processed)

# Oops, I forgot to close my files...

Object-oriented way

with open(in_path, 'r') as f1, open(out_path, 'w') as f2:    
    for line in f1:
        processed = process(line)
        f2.write(processed)

# I don't have to close my files, Python did it for me

Note that for line in f is an extensive use of Python's object-oriented data model. Imagine the pain if this syntax did not exist (well, just try it in C).

Emptiness test

Imperative way

if len(some_list) == 0:
    print("empty list")

Object-oriented way

if some_list:
    print("empty list")

Iteration over a sequence

Imperative way

i = 0
while i < len(some_sequence):
    print(some_sequence[i])
    i += 1

Object-oriented way

for elt in some_sequence:
    print(elt)

---

But the actual strength of this data model is that it lets you redefine a lot of magic attributes. For instance, you can make complex things comparable just by implementing __lt__, __le__ and so on, which will redefine the behaviour of <, <=, and so on. Thenceforth, built-in functions like min, max or sort will understand how to compare your objects.

This said, the use of mere dictionaries can be more than enough in a large variety of cases.

And at the end of the day, OOP is only one paradigm, and imperative programming just works as fine.

这篇关于Python OO程序结构规划的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！