blocks|key|1527159|text|例如，典型的操作可能包括以只对BigStructure对象有意义的方式遍历大型结构实例。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1527160|1527161|也许您可以编写一些生成器作为BigStructure的方法，以完成繁琐的遍历工作。然后，OperationsOnBigStructure可以在执行任务时循环遍历迭代器，这可能会提高代码的可读性。|1527162|因此，通过使用两个类而不是一个类，您可以在两个阶段提升抽象级别。|1527163|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|I|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|J|8|@]|9|@]|A|$]]|$1|C|3|D|5|6|7|K|8|@]|9|@]|A|$]]|$1|E|3|F|5|6|7|L|8|@]|9|@]|A|$]]|$1|G|3|-4|5|6|7|M|8|@]|9|@]|A|$]]]|H|$]]

<blockquote>
 For example, a typical operation may consist of traversing a big
 structure instance in a way that is only meaningful for a BigStructure
 object.
</blockquote>

Perhaps you could write some generators as methods of BigStructure that would do the grunt work of traversal. Then, OperationsOnBigStructure could just loop over an iterator when doing a task, which might improve readability of the code. 

So, by having two classes instead of one, you are raising the level of abstraction at two stages.

blocks|key|4587389|text|我在想，将操作转移到一个新的类中是很自然的，比如OperationsOnBigStructure类。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4587390|4587391|我要说的是，这与面向对象的设计完全相反。OOD背后的思想是将数据和方法保持在一起。|4587392|通常，一个(太)大的类是责任太大的标志:即你的类只是做了太多的事情。看起来您首先定义了一个数据结构，然后向其中添加了函数。您可以尝试将数据结构分解为子结构，并为这些子结构定义独立的类(即使用聚合)。但如果不知道更多就很难说...|4587393|当然，有时候，一个程序只需要一个大的类就可以很好地运行。但是如果你自己对它感到不舒服，这是一个强烈的提示，开始做一些事情来反对……|4587394|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|K|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|L|8|@]|9|@]|A|$]]|$1|C|3|D|5|6|7|M|8|@]|9|@]|A|$]]|$1|E|3|F|5|6|7|N|8|@]|9|@]|A|$]]|$1|G|3|H|5|6|7|O|8|@]|9|@]|A|$]]|$1|I|3|-4|5|6|7|P|8|@]|9|@]|A|$]]]|J|$]]

<blockquote>
 I was thinking that it would be natural to move the operations into a new class, say class OperationsOnBigStructure.
</blockquote>

I would say, that's quite the opposite of what Object Oriented Design is all about. The idea behind OOD is to keep data and methods together.

Usually a (too) big class is a sign of too much responsibility: i.e. your class is simply doing too much. It seems that you first defined a data structure and then added functions to it. You could try to break the data structure into substructures and define independent classes for these (i.e. use aggregation). But without knowing more it's difficult to say...

Of course sometimes, a program just runs fine with one big class. But if you feel incomfortable with it yourself, that's a strong hint to start doing something against ...

blocks|key|4587424|text|“现在，我有两个类，但感觉好像没有改进任何东西。实际上，我将事情变得稍微复杂一些，因为我现在需要将BigStructure对象传递给OperationsOnBigStructure中的方法，而它们需要在内部存储该对象。”|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4587425|我认为一种自然的方法是让"OperationsOnBigStructure“继承bigstructure+--因此你把所有相关的代码放在一个地方，不需要传递额外的参数，因为它需要操作的数据将包含在"self”中。|4587426|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

"""Now, I have two classes, but it feels like I haven't improved anything. In fact, I made things slightly more complicated, since I now need to pass the BigStructure object to the methods in OperationsOnBigStructure, and they need to store that object internally."""

I think a natural approach there would be to have "OperationsOnBigStructure" to inherit from bigstructure - therefore you have all the relevant code in one place, without the extra parameter passing,as the data it needs to operate on will be contained in "self".

blocks|key|506457|text|首先，确保你有很高的测试覆盖率，这会提升你的重构体验。如果没有或没有足够的单元测试，就创建它们。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|506458|然后进行合理的小重构步骤，并保持单元测试正常工作：|506459|根据经验，尽量将核心功能集中在一个大类中。如果有太多的耦合，尽量不要画边框。|506460|首先，将子任务重构为独立库中的函数。如果可以对事物进行抽象，则将该功能转移到库中。|506461|然后让代码更整洁，重新排序，直到你能看到它真正“想要”的结构。|506462|如果最后你觉得你仍然可以把它分成两个类，根据内部结构这是很自然的，那么考虑真的去做吧。|506463|始终保持足够高的测试覆盖率，并在做出一些更改后始终重构。AFter有时候你会有更漂亮的代码。|506464|entityMap^0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Q|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|R|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|S|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|T|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|U|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|V|8|@]|9|@]|A|$]]|$1|N|3|-4|5|6|7|W|8|@]|9|@]|A|$]]]|O|$]]

At first make sure you have high test coverage, this will boost your refactoring experience. If there are no or not enough unittests, create them.

Then make reasonable small refactoring steps and keep the unittests working:

As a rule of thumb try to keep the core functionality together in the big class. Try not to draw a border if there is too much coupling.

At first refactor sub tasks to functions in seperate libraries. If it is possible to abstract things, move that functionality to libraries.

Then make the code more clean and reorder it, until you can see the structure it really 'wants' to have.

If in the end you feel you can still cut it in two classes and this is quite natural according to the inner structure, then consider really doing it.

Always keep the test coverage high enough and refactor always after you made some changes. AFter some time you will have much more beautiful code.

blocks|key|506481|text|对于这个问题，我想出的解决方案是创建一个包含类的包。大致是这样的：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|506482|MyClass/
++++__init__.py
++++method_a.py
++++method_b.py
++++...|code-block|syntax|javascript|506483|在我的例子中，__init__.py包含实际的数据结构定义，但不包含方法。要将方法‘附加’到类中，我只需将它们导入到类的命名空间中。|offset|length|style|CODE|506484|method_a.py的内容：|506485|def+method_a(self,+msg):
++++print+'a:+%25s'+%25+str(msg)|506486|__init__.py的内容|506487|class+MyClass():
++++from+method_a+import+method_a
++++from+method_b+import+method_b

++++def+method_c(self):
++++++++print+'c'|506488|在python控制台中：|506489|>>>+from+MyClass+import+MyClass
>>>+a+=+MyClass()
>>>+dir(a)
['__doc__',+'__module__',+'method_a',+'method_b',+'method_c']
>>>+a.method_a('hello+world')
a:+hello+world
>>>+a.method_c()
c|506490|这对我很有效。|506491|entityMap^0|0|0|7|B|0|0|B|0|0|0|B|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|12|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|13|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|14|8|@$I|15|J|16|K|L]]|9|@]|A|$]]|$1|M|3|N|5|6|7|17|8|@$I|18|J|19|K|L]]|9|@]|A|$]]|$1|O|3|P|5|D|7|1A|8|@]|9|@]|A|$E|F]]|$1|Q|3|R|5|6|7|1B|8|@$I|1C|J|1D|K|L]]|9|@]|A|$]]|$1|S|3|T|5|D|7|1E|8|@]|9|@]|A|$E|F]]|$1|U|3|V|5|6|7|1F|8|@]|9|@]|A|$]]|$1|W|3|X|5|D|7|1G|8|@]|9|@]|A|$E|F]]|$1|Y|3|Z|5|6|7|1H|8|@]|9|@]|A|$]]|$1|10|3|-4|5|6|7|1I|8|@]|9|@]|A|$]]]|11|$]]

The solution I came up with for this problem was to create a package to contain the class.
Something along the lines of:

<pre><code>MyClass/
 __init__.py
 method_a.py
 method_b.py
 ...
</code></pre>

in my case <code>__init__.py</code> contains the actual datastructure definition, but no methods. To 'attach' the methods to the class I just import them into the class' namespace.

Contents of <code>method_a.py</code>: 

<pre><code>def method_a(self, msg):
 print 'a: %s' % str(msg)
</code></pre>

Contents of <code>__init__.py</code>:

<pre><code>class MyClass():
 from method_a import method_a
 from method_b import method_b

 def method_c(self):
 print 'c'
</code></pre>

In the python console:

<pre><code>&gt;&gt;&gt; from MyClass import MyClass
&gt;&gt;&gt; a = MyClass()
&gt;&gt;&gt; dir(a)
['__doc__', '__module__', 'method_a', 'method_b', 'method_c']
&gt;&gt;&gt; a.method_a('hello world')
a: hello world
&gt;&gt;&gt; a.method_c()
c
</code></pre>

This has worked for me.

I have a class <code>BigStructure</code> that builds a complicated data structure from some input. It also includes methods that perform operations on that data structure.

The class grew too large, so I'm trying to split it in two to help maintainability. I was thinking that it would be natural to move the operations into a new class, say class <code>OperationsOnBigStructure</code>.

Unfortunately, since class <code>BigStructure</code> is quite unique, <code>OperationsOnBigStructure</code> cannot be reasonably reused with any other class. In a sense, it's forever tied to <code>BigStructure</code>. For example, a typical operation may consist of traversing a big structure instance in a way that is only meaningful for a <code>BigStructure</code> object.

Now, I have two classes, but it feels like I haven't improved anything. In fact, I made things slightly more complicated, since I now need to pass the <code>BigStructure</code> object to the methods in <code>OperationsOnBigStructure</code>, and they need to store that object internally.

Should I just live with one big class?

splitting a class that is too large

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我有一个BigStructure类，它从一些输入构建复杂的数据结构。它还包括在该数据结构上执行操作的方法。这个类变得太大了，所以我试着把它一分为二，以提高可维护性。我在想，将操作移动到一个新的类中是很自然的，比如OperationsOnBigStructure类。不幸的是，由于类BigStructure是独一无二的，O...

问拆分过大的类
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问拆分过大的类EN