给OOP专家的一个问题。 - 页 3

新评论
 
Artyom Trishkin:

生物。

植物群/动物群

亚种

种类

家庭

等。

这就是你想要的吗？

嗯，这是从基本实体 "Entity "简单继承而来。

但你可以更深入地了解--有单细胞/多细胞，这就是对生物的全部。但也有非生物的。这一切都取决于任务，为此你需要找到一个基础对象的属性，并从其继承。

如果你真的很疯狂，你可以进入原子，开始把它们分成若干部分，寻找一个基本的母体物体（要小心--裂变反应可能成为连锁反应，你会毁掉半个世界:)

对。乍一看，OOP概念似乎是构建层次结构的理想选择。但如何处理通过OOP建立的层次结构？由于对类和其内容的访问权，它是语法的海洋，也是链接之间过渡的复杂性。这就是开销的开始，是划分阶级的结果。一方面，OOP允许建立一个层次结构，另一方面，它使工作变得极其困难。
 
Реter Konow:
对。乍一看，OOP的概念是构建层次结构的理想选择。但你如何处理通过OOP建立的层次结构？由于对类和其内容的访问权，它是语法的海洋，也是链接之间过渡的复杂性。这就是开销的开始，是划分阶级的结果。 一方面，OOP允许你建立一个层次结构，另一方面，它使你的工作变得极其困难。

嗯，没有。OOP使人们能够非常容易地访问层次结构中任何位置的任何成员。

首先，找到你的基础对象，并使其具有最小的所需属性。

其余的对象都继承于它。为了避免重蹈覆辙，你的基础对象应该继承标准库的CObject类。这允许你创建你自己的对象层次结构，而不需要重新发明列表。

CObject --> CBaseObject --> 你的层次结构。

在CBaseObject中，你必须有一个虚拟方法来返回这个对象。那么每一个子孙都将相应地拥有这个方法，并且它将准确地返回子孙对象。CObject的基类已经有一个方法--Type()。如果你有相同的CBaseObject的虚拟方法，并且它将返回对象的类型，你将知道你访问了什么对象。

这就像你所有对象的基本基础。而且它们都应该存储在自己的列表中--每个列表只包含一种类型的对象--鱼、动物、人、神，等等。

也就是说，你需要为每个子类型准备一份清单。而且必须有一个列表，它将包含层次结构中的以下列表。这些列表中的每一个也必须有列表--再次--在层次结构中的下一个。以此类推。

也就是说，你还需要一个基础列表对象，你将在其中放置所需的列表。而这个基列表必须有一个Type()方法，而且必须有一个方法允许你通过索引返回存储在其中的任何对象。然后，如果这样做了，你将自动在任何一个列表中拥有一个方法，返回所需的对象。

一般来说，你必须首先考虑你的基础对象，然后是你的列表对象。你也不需要创建对象列表，它们已经存在。

然后就是技术问题了。而且你只需要知道你要找的对象的类型。在它的层次中会有很多类型，每一种类型都是你所知道的，你可以请求和接受它。

 

在我看来，在这种情况下，它与OOP没有关系。

在Peter的例子中，数组中的所有对象都是通过某个键来搜索的。 而且，如果你使用类，如果你使用数组，如果你使用一堆声明的对象，根本就没有区别。

OOP允许有一个对象的列表，每个对象都有GetColor()方法--用户通过所有对象来寻找正确的颜色。但是，如果没有OOP--我们有一个相同结构的数组，用户需要了解这些结构，以便从需要的地方获得颜色，有了OOP--用户不需要确切地知道颜色是如何存储的，存储在哪里--对象的GetColor()方法知道，从哪里获得颜色。

因此，对于OOP来说--用户不需要知道对象的颜色是如何和在哪里存储的。因此，如果我们突然需要添加一个 "盲人对象"，其中的颜色是由盲文的点来编码的，我们可以很容易地将这个对象添加到我们的列表中，只改变它的GetColor()方法，它将从盲文的点中接收颜色代码，并以常规形式返回。对于我们名单上的用户来说，什么都不会改变。

如果我们只有一个数组--我们不能把 "盲文点 "放在那里。我们在其中没有这样的领域。

 

当我们继承自CObject，然后创建一个对象的数组CArrayObj，然后通过只写比较函数--我们立即获得了快速排序和二进制搜索的能力，OOP的好处就真的很明显了。

粗略的说，对于我上面的例子，对于颜色--对于OOP--我们写一个比较函数，通过GetColor()获得颜色，我们可以按颜色给我们的对象排序，即使不知道我们有一半的对象是真正的颜色，一半是 "盲文点"。如果我们想添加一个具有新颜色编码的对象--同样，我们只需要编写GetColor()函数，这将使其颜色表示符合标准--然后，已经编写的排序 和搜索算法 将毫无问题地接受这个新对象。

也就是说，事实上，OOP允许我们在尚未写好的对象上有一个排序和检索的算法，在我们还没有决定它们到底如何被表示，如何被存储的时候。

 
Georgiy Merts:
OOP的好处真的很明显，当我们继承了CObject，然后创建一个对象的数组CArrayObj，然后，只写比较函数，我们就可以得到快速排序和二进制搜索。
我想把它告诉彼得，当他理解了向他提出的数据存储的概念。
 
Реter Konow:
由于对类和其内容的访问权限，这是一个语法的海洋，而且链接之间的过渡也很困难。这就是开销的开始，是划分阶级的结果。 一方面，OOP允许你建立一个层次结构，另一方面，它使你的工作变得非常困难。

访问权限修改器允许在编译时检测错误

一般来说，所有这些都不会使类的工作复杂化，不要使用它，把一切都写在公开的地方。然后就会更容易与他们合作。

SZZY：很多关于OOP、封装和继承的好词好句......。这一切都很好，但与其他编程风格相比，OOP最重要的优势是将所有的数据（类字段）和处理这些数据的功能（类方法）存储在一个地方（类）--在书中这就是封装。进一步说，OOP的使用 取决于任务，如果任务允许扩展类，那么就需要层次结构，会有基类和它们的子类--是否使用它，取决于你。

 
Georgiy Merts:
阿尔乔姆-特里什金。

我必须承认，在OOP概念中，"对象 "是在比我的 "内核 "更广泛的背景下提出的。但是，这并不奇怪，因为到目前为止我只处理了图形问题，而OOP被用于广泛的任务。我的对象 "菜单 "相当稀少，除了 "标签"、"元素"、"窗口 "之外，可能没有什么别的东西了......然而，对于图形界面来说，我已经没有什么需要了。

然而，现在出现了扩展 "对象 "的概念并建立一个层次的问题。一个简单的二维内核不能接受所有种类的知识库对象，因此要么为不同的对象创建不同的内核，要么就应该遵循OOP的概念。

从本质上讲，这是一个纯粹的技术问题。哪个更有效，哪个更快，哪个更可读，等等。

事实上，你可以简单地将一个数组中的所有对象作为一个属性列表，其中会有指向其他数组的指针，有其他对象等等。或者你可以明确地使用OOP。两种方法中无一例外地都有面向对象，只是实现的方法不同。同样的内存，同样的指针，同样的对象，同样的分类。只有代码形式是不同的...

 
Artyom Trishkin:
我想在彼得理解了向他提出的数据存储概念后，再告诉他这件事。
我将尝试理解这个数据存储和处理的概念。
 
Реter Konow:
我将尝试理解这个存储和处理数据的概念。
好的。我们可以当面谈一谈。或在Skype中--无论什么对你来说更方便。只是，具体情况不在这个主题上--据我所知--这里只有一般问题。
 
Artyom Trishkin:
好的。（笑）。我们可以当面聊一聊这个话题。或者在Skype上，根据你的喜好。只是具体内容不在这个主题上--按照我的理解，这里只是一般问题。
好吧，我考虑一下。如果有的话，我会亲自写。
12345678910...55
新评论