OOP与程序化编程 - 页 12

新评论
 

如果我连类都装不进去，我怎么能使用OOP？我根本不需要它们。我不需要结构。这是一种人为的划分，我的程序的自我发展是没有理由的。正是如此--自我发展。没有其他的词来形容它。

因此，在这个过程中，代码块本身是按必要性划分的，这是在改进它们和增加新功能的过程中诞生的。首先，功能被创建，然后它们被逐渐组合成更大的区块，这些区块被打磨并以新的功能进行更新。随着时间的推移，这些区块会瓦解，新的区块会出现。一切都是自然发生的。我只 "旋转 "新的功能，以获得新的特性，然后把它磨成一个高质量的状态。同时，代码结构也在不断变化和转变。我没有保留任何明确的计划，一切都在不可预测的方向发展。突然间，在这个过程中，我发现有机会实现质的飞跃。而我做了这个飞跃。

这就是我的方案的演变过程。它膨胀，然后收缩，崩溃，并出现了转变。有全球变化，有质的飞跃，但也有长期稳定的状态。

在这个过程中，任何不必要的规则和外来的语言语法只会使事情变慢。

 
Реter Konow:

如果我连类都装不进去，我怎么能使用OOP？我根本不需要它们。我不需要结构。这是一种人为的划分，我的程序的自我发展是没有理由的。正是如此--自我发展。没有其他的词来形容它。

因此，在这个过程中，代码块本身是按必要性划分的，这是在改进它们和增加新功能的过程中诞生的。首先，功能被创建，然后它们被逐渐组合成更大的区块，这些区块被打磨并以新的功能进行更新。随着时间的推移，这些区块会瓦解，新的区块会出现。一切都是自然发生的。我只 "旋转 "新的功能，以获得新的特性，然后把它磨成一个高质量的状态。同时，代码结构也在不断变化和转变。我没有保留任何明确的计划，一切都在不可预测的方向发展。突然间，在这个过程中，我发现有机会实现质的飞跃。而我做了这个飞跃。

这就是我的方案的演变过程。它膨胀，然后收缩，崩溃，并出现了转变。有全球变化，有质的飞跃，但也有长期稳定的状态。

在这个过程中，任何不必要的规则和语法与外国语言的关系，只会使事情变得缓慢。


不过，也许值得花一个星期的时间来理清结构。"我不需要结构 "的说法看起来非常愚蠢。唯一的结论是，你根本不知道它是什么。

 
Dmitry Fedoseev:

有些任务无法以最佳方式按程序解决。

这取决于你说的 "最佳 "是什么意思 )

在我看来，OOP只是一个方便的包装，而不是解决任何问题的方法。这就是为什么这里的争论处于停滞状态。

总的来说，每个人似乎都同意，使用结构化程序方法，任何任务都能更快、更紧凑地得到解决。而花在包装成类上的时间比花在编码本身上的时间多。有时你会得意忘形，把一堆课程搞得一团糟，然后想，为什么要为这一切而烦恼呢？

关于 "使用函数指针的程序化编程 "还有一件事--为什么要把它放在一个单独的类别中？我认为函数指针只是一种结构化-程序化的风格。

 
Alexey Navoykov:

这取决于你所说的'最佳方式'是什么意思 )

在我看来，OOP只是一个方便的包装，而不是任何问题的解决方案。这就是为什么这里的争论处于停滞状态。

总的来说，每个人似乎都同意，使用结构化程序方法，任何任务都能更快、更紧凑地得到解决。而花在包装成类上的时间比花在编码本身上的时间多。有时你会得意忘形，把一堆课程搞得一团糟，然后想，为什么要为这一切而烦恼呢？

关于 "使用函数指针的程序化编程 "还有一件事--为什么要把它放在一个单独的类别中？我认为，函数指针只是结构化-程序化的风格。


除了函数指针之外，多态性 在程序化手段中是不可行的。OOP是明确的多态性，而在程序性编程中，不一定有指向函数的指针。

人们不应该把所有的东西都包在类里。

 
Dmitry Fedoseev:

我们不应该至少花一个星期的时间来处理这些结构吗？"我不需要结构 "的说法看起来非常愚蠢。唯一的结论是，你根本不知道它是什么。

结构是一个不言自明的东西。它结合了一组命名的不同类型的变量。我的程序中的主要类型是int。我只在少数地方使用双份。仅在一个特定的区块中的字符串。

为什么在OOP的背景下我需要结构？

我有一个属于内核的结构。也就是说，内核本身的结构在它里面。这就是我需要的一切。

 
Реter Konow:

结构不言而喻。它结合了一组命名的不同类型的变量。我的程序中的主要类型是int。我只在几个地方使用双份。仅在一个特定的区块中的字符串。

为什么在OOP的背景下我需要结构？

我有一个属于内核的结构。也就是说，内核本身的结构在它里面。这就是我需要的一切。


你必须在三年内为自己写一个程序。

 
Dmitry Fedoseev:

你可以，但要有不同的运作效率。支持不是这里的问题，它太相对了。

有些任务在程序上你无法以最佳方式解决。


我是OOP的支持者，但事实上，处理器对OOP的存在一无所知，它可以执行机器代码，仅此而已。在计算机诞生之初，他们以这种方式编写程序，直接用机器代码。

这就是为什么有那么多的女性程序员。因为男人们会因为这项工作而喝醉和发疯）。

 
Реter Konow:

毕竟，同意--解决方案的效率才是最重要的。

语法的重载和规则的复杂性从未有助于保持解决方案的效率。在代码块的简洁性、普遍性和可读性方面所表现出的简单性和简明性是有帮助的。

那么什么叫高效的解决方案呢？

我的编程规则是：更少的代码，更少的规则，更少的语法。

"我的规则：没有规则")))
 

我不是一个OOP的粉丝。

但就可维护性、可扩展性和第三方使用的便利性而言，TC（彼得，不是卡尔普托夫）所推动的只是石器时代。

我强烈认为，每个 程序员都 应该在一个团队中工作，最好是4个人以上，只是要明白，代码的效率和通用性并不意味着这个代码是好的。

 
Alexey Volchanskiy:

我是OOP的支持者，但事实上，处理器对OOP的存在一无所知，它可以执行机器代码，仅此而已。在计算机的早期，你就是这样写程序的，直接用机器代码。

这就是为什么有那么多的女性程序员。因为男人喝了很多酒，并因为这项工作而变得疯狂）。


它是什么？到目前为止，一个结论是，在开始时你必须用机器代码编写大量的程序))

1...5678910111213141516171819...48
新评论