Oop 面向对象、耦合与opengl

耦合似乎是糟糕的编程实践。为什么OOPS提倡这种范式？例如，我查看了Java、.net和Android矩形类。每个定义都不同。此外，您必须实例化一个矩形来绘制它

使用OpenGL，绘制矩形不会与矩形对象耦合。这种将矩形的绘制与对象分离的方法使API更加健壮。您可以将矩形绘制为类似lambda的函数，而无需创建矩形对象

将动作与对象耦合可能是抽象功能或制作组件的一种方式。但在我看来，它似乎限制了使用，强制执行全部或全部不执行。要么使用我的对象和方法，要么什么都不使用。然后，用不同的方法定义的相同对象大量涌现

库倾向于将对象的字段分解为完成任务所需的参数。这只会添加到函数名中。例如，在oops中，它将是“rectangle.draw（）”，在opengl中，它将是：“drawRectangle（x1，y1，x2，Y2）”

为什么oops会将绘图与形状相结合。看起来很奇怪。此外，如果绘图方法访问硬件并添加了新的GPU，则必须更改每个对象，而不是仅更改未耦合的绘图方法

图形是一个oops抽象不是最佳方法的领域，这是一个更好的细化问题

在oops中，我们不仅仅定义一个像c结构这样的对象，我们还定义了可以对该对象执行的操作，这些操作差别很大。然后我们将可以对对象执行的操作与对象耦合。这会导致相同对象的不同定义。没有人能假设知道对一个物体所能做的一切

例如，我们可能想要将一个矩形平分。向矩形对象添加新的对分方法，或创建采用矩形结构的对分函数。随着新功能的添加，结构不会改变，但对象的方法会改变，从而改变对象，因为它们是紧密耦合的

---

然后就结构达成共识。矩形是一种长度和宽度用数字表示的结构。使用矩形可以做什么取决于您选择的库。

我将首先回答。开发三层系统（SQL后端、业务对象作为中间层、GUI作为前端）消除了OOP。有了c#，重复太多了。你定义事物3次

我的意思是SQL是数据抽象的终极。积垢行为。创造，阅读。更新。删除。将数据视为解释REPL的fetch decode exe循环

这些操作是否与对象关联？汇编指令是基于对象的。Mov-Ax，Bx。在OOP中，这是Ax.mov（BX）对对象或寄存器的绑定操作

---

不要咆哮。

什么是“哎呀”？此外，OpenGL没有

drawRectangle

。Oops是面向对象的编程系统。在opengl中，绘制矩形类似于“glrectf（参数）”。我强调OpenGL似乎采取了一种像C一样的功能性方法，而不是像C++那样的OOP方法。在某种意义上，opengl函数没有显式地绑定到对象，可能隐式地绑定到图形驱动程序对象。@Daryl:Functional≠ 迫切的C语言肯定不是函数式语言（即函数作为一阶对象）。到目前为止，C是一种纯粹的命令式编程语言。你可以在C语言中引入类似函数式编程的结构，但你永远不会得到函数组合之类的东西。如果您想了解函数式编程，请了解OCaml、Haskell、Erlang、Scheme、Lisp、Closure或Scala。由于OpenGL的全局状态，它肯定无法正常工作；显然，将其绑定到纯函数式语言中是非常必要的，也是非常困难的。@Daryl:你说得越多，听起来就越不像是有人试图真正理解某些东西，而你听起来就越像是有人试图证明他们已经下定决心的想法是正确的。堆栈溢出不适用于伪装成问题的咆哮。