关于应用程序设计的问题 - 使用python类的OOP [英] Questions about app design - OOP with python classes

问题描述

嗨


我正在开发一个python应用程序，一个大纲（一个带有TreeCtrl的窗口

on

左边选择一个文件，右边的RichTextBox编辑

当前

doc）。


我很熟悉使用OOP概念和术语但我缺乏实用

经验

，所以欢迎任何评论/提示/指向文档。


到目前为止，我为我的应用程序的每个重要的

元素创建了一个单独的类

- 主框架（cFrmMain）

- TreeCtrl

- 右边的TextCtrl

- 一个包含整个文件的cDocument类，包含所有

docs

并管理创建/删除/保存到磁盘等

- 工具栏，菜单栏等的类


有了这个设计，几乎所有的东西封装在里面

各自

级。但是，这意味着主程序逻辑在Frame

类中。

Hi

I am working on a python app, an outliner(a window with a TreeCtrl
on the
left to select a document, and a RichTextBox at the right to edit the
current
doc).

I am familiarized with OOP concepts and terms but I lack practical
experience
, so any comment/tip/pointer to docs will be welcome.

So far, I have created a separated class for each important
element of my app
- the main Frame (cFrmMain)
- the TreeCtrl
- the TextCtrl at the right
- a cDocument class that contains the entire file with all
docs
and manages creation/deletion/saving to disk, etc
- classes for the toolbar, the menubar, etc

With this design, pretty much everything is encapsulated in it
respective
class. However, that means that the main program logic is in the Frame
class.

>从那里，它实例化其他类并负责

>From there, it instantiates the other classes and is responsable of

他们之间的沟通。


例如，用户删除树上的节点，这会引发一个

事件

在cFrmMain（主要的Frame类）上。在事件处理程序中，cFrmMain

通知

cDocument节点（和相关文本）已被删除所以

主人
文件也相应修改。


问题是，我一直在实施一些功能来对待

测试这个

设计，我已经实施了不到十几个操作，并且cFrmMain

已经增长了

超过可接受的范围，开始变得混乱。


这种设计感觉不太正确。对我来说，我一直在考虑

允许

不同的班级知道彼此的存在并通过

留言

他们之间。我会失去封装（我想），我不知道

如果那将是

（非常）糟糕......而且我不确定如果使用这种设计，我将获得或失去

清晰的代码。


我的问题（最后:-)）是：


？我应该坚持我的第一个设计理念，最终将代码

从

主框架转移到模块以获得清晰度？


？我提出的第二个想法是正确吗？ （我知道它会起作用，我想要的是什么？b $ b想要知道
知道是组织我的代码最清晰的方式）？


？我从一开始就做错了，必须使用另一个

设计吗？


感谢您阅读这篇长篇文章。任何评论，提示或指向

文档将非常感谢。


问候

AdriánGarrido

the
communication between them.

For example, the user deletes a node on the Tree, this raises an
event
on cFrmMain (the main Frame class). In the event handler, cFrmMain
notifies
cDocument that a node (and the associated text) has been deleted so
the master
file is modified accordingly.

The problem is, I have been implementing some funcionalities to
test this
design, I have less than a dozen operations implemented and cFrmMain
has grown
more than acceptable, starting to get confusing.

This design feels "not quite right" to me, I''ve been considering
allowing
the different classes to know of the existence of each other and pass
messages
between them. I would lose encapsulation (I think), and I don''t know
if that would be
(very) bad... and I''m not sure if with this design I will gain or lose
clarity on the code.

My questions ( at last :-) ) are:

?Should I stick to my first design idea, eventually moving code
from the
main Frame to modules to gain clarity?

?Is the second idea I present "correct" (I know it''ll work, what I
want to
know is the clearest way of organize my code)?

?Am I doing this wrong from the start and have to use another
design?

Thanks for reading this long post. Any comment, hint or pointer to
docs will
be greatly appreciated.

Regards
Adrián Garrido

推荐答案

ad ******** @ gmail.com écrit：

ad********@gmail.com a écrit :

嗨


我是在一个python应用程序上工作，一个大纲（一个带有TreeCtrl的窗口

在

左边选择一个文档，一个RichTextBox在右边编辑

当前

doc）。


我熟悉OOP概念和术语但我缺乏实用

经验

，所以任何评论/提示/指向文档都是受欢迎的。


到目前为止，我为每个重要的人创建了一个单独的类
我的应用程序的
元素

- 主框架（cFrmMain）

- TreeCtrl

- 右边的TextCtrl

- 一个cDocument包含所有

文档

的整个文件的类，并管理创建/删除/保存到磁盘等

- 工具栏的类，菜单栏等等

Hi

I am working on a python app, an outliner(a window with a TreeCtrl
on the
left to select a document, and a RichTextBox at the right to edit the
current
doc).

I am familiarized with OOP concepts and terms but I lack practical
experience
, so any comment/tip/pointer to docs will be welcome.

So far, I have created a separated class for each important
element of my app
- the main Frame (cFrmMain)
- the TreeCtrl
- the TextCtrl at the right
- a cDocument class that contains the entire file with all
docs
and manages creation/deletion/saving to disk, etc
- classes for the toolbar, the menubar, etc

作为旁注：匈牙利表示法在这里通常被视为不良表格。

在此查看通常的命名约定：
http://www.python.org/dev/ peps / pep-0008 /

使用这种设计，几乎所有内容都封装在其中

各自

等级。但是，这意味着主程序逻辑在Frame

类中。

With this design, pretty much everything is encapsulated in it
respective
class. However, that means that the main program logic is in the Frame
class.

你怎么称呼主程序逻辑？究竟是什么？

What do you call "main program logic" exactly ?

>>从那里，它实例化其他类并负责

>>From there, it instantiates the other classes and is responsable of

他们之间的沟通。


例如，用户删除树上的节点，这会引发一个

事件

在cFrmMain（主要的Frame类）上。在事件处理程序中，cFrmMain

通知

cDocument节点（和相关文本）已被删除所以

主人
文件相应地修改。

the
communication between them.

For example, the user deletes a node on the Tree, this raises an
event
on cFrmMain (the main Frame class). In the event handler, cFrmMain
notifies
cDocument that a node (and the associated text) has been deleted so
the master
file is modified accordingly.

好​​的。

Ok.

问题是，我一直在实施一些功能来

测试这个
设计，我实施了不到十几个操作，而且cFrmMain

已经增长了

超过可接受的，开始获得混乱。

The problem is, I have been implementing some funcionalities to
test this
design, I have less than a dozen operations implemented and cFrmMain
has grown
more than acceptable, starting to get confusing.

Ok。

Ok.

这种设计感觉不太正确。给我，

This design feels "not quite right" to me,

看起来差不多对我来说！ - ）

使用主框架作为不同小部件之间的中介是一个众所周知的设计模式，名为 - 令人惊讶的 - 中介。

的动机是避免每个小部件知道每个小部件的存在。你可能想要阅读这个模式

- 但是请注意，大多数关于设计模式的文章用静态类型语言（Java，C ++等）的
表示，并且动态

像Python这样的语言通常不需要那么多样板和

复杂化（IOW：尝试理解模式本身，而不是盲目地

适用它。


你在寻找恕我直言的是控制器是什么？部分 -

将视图粘合在一起的部分（主框架及其所有小部件）和

"模型" （主要是你的文件）。再次，谷歌搜索

" model / view / controller" （MVC）可能是一个好主意。

Looks "almost right" to me !-)

Using the main frame as a mediator between the different widgets is a
well-known design pattern, named - suprisingly - mediator. The
motivation is that it avoid each and every widget to know about the
existence of every other widget. You may want to read about this pattern
- but note that most litterature about design patterns is expressed in
terms of statically typed languages (Java, C++ etc), and that dynamic
languages like Python usually don''t need that much boilerplate and
complication (IOW : try to understand the pattern itself, not to blindly
apply it).

What''s your looking for IMHO is the "controller" part - the one that
glue together the "view" (main frame and all it''s widgets) and the
"model" (mostly, your document). Here again, googling for
"model/view/controller" (MVC) may be a good idea.

我一直在考虑

允许

不同课程要知道彼此的存在并传递

消息

他们之间。我会失去封装（我认为），

I''ve been considering
allowing
the different classes to know of the existence of each other and pass
messages
between them. I would lose encapsulation (I think),

至少这会在这些类之间引入太多耦合。


注意在你的问题中没有特定于Python的东西。但是因为

comp.object是世界上最糟糕的地方之一，对OO提出问题......

At least this would introduce too much coupling between these classes.

Note that there''s nothing Python-specific in your question. But since
comp.object is one of the worst places on earth to ask questions about OO...

3月1日，9日：下午45点，Bruno Desthuilliers

< bdesth.quelquech ... @ free.quelquepart.frwrote：

On Mar 1, 9:45 pm, Bruno Desthuilliers
<[e-mail]:

作为旁注：匈牙利语符号通常被认为是不好的形式。

在这里查看通常的命名约定： http://www.python.org/dev/peps/pep-0008/

感谢您的提示。这已经是VB6太多年了，而且很难留下旧习惯

落后:-)

Thanks for the tip. It''s been too many years of VB6, and its difficult
to leave old habits
behind :-)

>

>

使用这种设计，几乎所有内容都封装在其中

各自

class。但是，这意味着主程序逻辑在Frame

类中。

With this design, pretty much everything is encapsulated in it
respective
class. However, that means that the main program logic is in the Frame
class.

你叫什么主程序逻辑？到底？

What do you call "main program logic" exactly ?

我的意思是在框架代码中所有的决定是

。框架处理

其他控件事件，决定需要做什么，调用

其他控件的必要方法等。其他小部件只是

做的工作从框架调用时。但是这不是必然的坏事，正如你在下面指出的那样。

What I mean is that in the frame code is where all decisions are
taken. The frame handles the
other controls events, decides what needs to be done, calls the
necesary methods of the other controls, etc. The other widgets just
"do the work" when called from the Frame. But this is not
necesarily bad, as you point out below.

使用主框架作为不同小部件之间的中介是一个

众所周知的设计模式，名字 - 令人惊讶的 - 调解员。

的动机是避免每个小部件知道每个小部件的存在。你可能想要阅读这个模式

- 但是请注意，大多数关于设计模式的文章用静态类型语言（Java，C ++等）的
表示，并且动态

像Python这样的语言通常不需要那么多样板和

复杂化（IOW：尝试理解模式本身，而不是盲目地

适用它。


你在寻找恕我直言的是控制器是什么？部分 -

将视图粘合在一起的部分（主框架及其所有小部件）和

"模型" （主要是你的文件）。再次，谷歌搜索

" model / view / controller" （MVC）可能是一个好主意。

Using the main frame as a mediator between the different widgets is a
well-known design pattern, named - suprisingly - mediator. The
motivation is that it avoid each and every widget to know about the
existence of every other widget. You may want to read about this pattern
- but note that most litterature about design patterns is expressed in
terms of statically typed languages (Java, C++ etc), and that dynamic
languages like Python usually don''t need that much boilerplate and
complication (IOW : try to understand the pattern itself, not to blindly
apply it).

What''s your looking for IMHO is the "controller" part - the one that
glue together the "view" (main frame and all it''s widgets) and the
"model" (mostly, your document). Here again, googling for
"model/view/controller" (MVC) may be a good idea.

我明白（我已经在维基百科:-)）。现在Frame是

控制器以及

作为视图。移出控制器代码到另一个模块似乎

给我

路径。我会开始关注与MVC相关的材料。


我的问题是，虽然我知道OOP的基础知识，但我不知道怎么回事
完全适用它们。谢谢

你的回答，它清除了很多东西。

I understand (I''ve been in wikipedia :-) ). Right now the Frame is the
controller as well
as the view. Moving out the "controller" code to another module seems
to me the
path to follow. I''ll start to look out for MVC related material.

My problem was that, altough I knew OOP basics, I didn''t know how to
apply them exactly. Thanks
for your answer, it has cleared many things.

请注意，你的问题中没有特定于Python的内容。但是因为

comp.object是世界上最糟糕的地方之一，提出有关OO的问题....

Note that there''s nothing Python-specific in your question. But since
comp.object is one of the worst places on earth to ask questions about OO....

我正在开发中Python，所以我在这里发帖是有道理的。但是

你是对的，问题

是偏离主题的。对不起。


再次感谢和问候
$ b $bAdriánGarrido

I am developing in Python, so it made sense to me to post here. But
you are right, the question
is off-topic. Sorry for that.

Thanks again and regards
Adrián Garrido

< a href =mailto：ad ******** @ gmail.com> ad ******** @ gmail.com aécrit：

ad********@gmail.com a écrit :

3月1日下午9:45，Bruno Desthuilliers

< bdesth.quelquech ... @ free.quelquepart.frwrote：


我明白了（我去过维基百科:-)）。现在Frame是

控制器以及

作为视图。

On Mar 1, 9:45 pm, Bruno Desthuilliers
<[e-mail]:
I understand (I''ve been in wikipedia :-) ). Right now the Frame is the
controller as well
as the view.

是的。注意，这是常见的简化。 MVC - 微软

标记为文档/视图。


（剪辑）

Yeps. Note that this is a common "simplification" of the MVC - Microsoft
labelled it "Document/View".

(snip)

我的问题是，尽管我知道OOP的基础知识，但我还不知道如何将b $ b完全应用于他们。

My problem was that, altough I knew OOP basics, I didn''t know how to
apply them exactly.

这主要来自经验恕我直言。但是阅读GOF（我告诉你这个TLA所指的是谷歌！）可能并不是一个坏主意 - 它可能是最好的书OO设计到目前为止我已经阅读了，即使很多

描述的模式在高度动态的语言中变得不那么敏感，比如

Python。

It mostly comes out of experience IMHO. But reading the GOF (I let you
google for what this TLA refers to !-) may not be a bad idea - it''s
probably the best book about OO design I''ve read so far, even if lot of
the described patterns make less sens in an highly dynamic language like
Python.

>>请注意，您的问题中没有特定于Python的内容。但是因为
comp.object是世界上最糟糕的地方之一，对OO提出问题...

>>Note that there''s nothing Python-specific in your question. But since
comp.object is one of the worst places on earth to ask questions about OO...

我用Python开发所以我在这里发帖是有道理的。但是

你是对的，问题

是偏离主题的。对不起。

I am developing in Python, so it made sense to me to post here. But
you are right, the question
is off-topic. Sorry for that.

唉，相应的新闻组（comp.object）已经变成了我在网上认识的最不友善和最无聊的地方之一。

Alas, the appropriate newsgroup (comp.object) has turned into one of the
most unfriendly and sterile places I know on the net.

这篇关于关于应用程序设计的问题 - 使用python类的OOP的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！