令人意想不到的意外中的消息唤醒了各种各样的回忆，但并非如此。 我也从她那儿得到这篇文章 ，马上就怀旧了，在过去的七年中，我想扮演她的重磅省略号。
Dephi是一个绝对出色的解决方案。 好吧，您知道，就像披头士乐队一样，它是带有鼠标控制的图形计算机界面，是内燃机。 这个巧妙的解决方案已经广泛应用到我们的生活中，以至您甚至无法相信它曾经不存在，在Windows中绘制窗口，复选框和按钮可能真是太痛苦了。
Delphi的绝对精巧部分是VCL-用于Windows窗口的同一组复选框和按钮，它们突然变得如此容易和简单地拖放到彼此，并创建了精美而独特的Windows应用程序。
就像任何体面的UI一样，根据事件模型，这当然起作用。 按钮对象中的OnClick描述了按钮的所有操作，在输入文本字段时进行OnChange，就像成年人一样。 但是此后-更不幸的是，还没有任何东西。
我的意思是，我们现在所不知道的事。 例如，MVC-Delphi，认为它由一个V组成，那么一切都由开发人员控制。 直接从OnClick提取请求到数据库？ 是的，请。 在OnChange中，打开一些文件并尝试对其进行写入，如果在适当的位置文件并没有因诸如Memory Access Violation之类的问题而安静地崩溃，则在每个步骤（但是，这与Delphi作为平台无关）。
我必须说，多年来，这对每个人来说都是完全快乐的，有些人对此仍然非常满意。 纤细美观的UI组件库的好处是显而易见的，无论是在开发的第一年还是在源代码的前百千字节中，任何控制器和模型的好处都是显而易见的。
即使已经变得很容易忘记，但这里仍然存在思维陷阱，就像那些在互联网上激烈争论的视觉和听觉幻觉一样。 因此，让我尝试从Delphi到对UI的现代理解之间架起一座小桥梁，我们可以弄清楚会发生什么。
因此，关键思想是：我们将表示形式与数据，小部件分开，将其中包含信息的所有工作分开。 如何分开？ 说，按钮上仍然有一个题词，有时还有一个图标。 用户本人可以将这个题词驱动到文本字段中，有时文本字段中还会有另一个题词向用户解释他确切地驾驶了什么。 一般规则：窗口小部件至少要显示（SIC！）逻辑，其中可能只有一个与显示相关联，而没有其他逻辑。 假设按钮尚未准备好随其上的铭文一起伸展-应当以某种方式裁切该铭文（例如，在工具提示中显示省略号和完整版本），或者在尝试设置超出其适合范围的值时给出错误（尽管想法很一般，这样的错误很可能已经在程序执行期间最不适当的时候出现了。
如果是单行，则文本输入字段可以从文本中删除回车符翻译，但是例如，不必要求仅输入数字-这不是他的工作。 就像在按钮单击处理程序中不需要检查，无需重画调用一样，按钮处理程序必须提取外部代码，该代码已经负责UI和整个应用程序的逻辑。
而且，如果您生活在一个美丽的新喷气式飞机世界中，那么瞧瞧所有这些OOP事件，那么原理就保持不变：按下按钮可以通过添加相应的Action来更改其状态，然后添加一些代码，而该代码不会与UI元素相关联的内容，请查看此Action，并得出适当的结论，并更改状态，以便在UI上可以显示一些内容。
也就是说，无论环境，平台和范例如何，视觉元素本身都具有最少的功能和零逻辑。 它们以最通用的形式接收信息，因此，如果您有一个TextBox，它也是Input，它也是一个用于输入文本的字段，它需要一个字符串并给出一个字符串。 将行变成数字，某人的名字或更狡猾的任务不再适用于该小部件。
好了，然后由Controller或Presenter处理结果并产生结果。 按照您的习惯称呼他，只是不要在他身上弹出任何视觉元素。
什么是利润？ 我认为从最明显到最重要的顺序列出了最基本的顺序。
首先，可重用性。 实际上，要花很多时间才能理解，用于输入邮寄地址，用于输入姓氏和用于输入金额的字段实际上是同一字段。 一个和相同的小部件，具有相同的一组功能，这些功能归结为拉出文本输入事件或更新状态。 并且只有使用其中的文本的逻辑可能有所不同。 生活中“如何不做”的例子：创建一个用于输入金额的字段（最多两位小数），然后摆弄很长时间，重做一次，以便有时还可以输入数量（最多4位小数） 。 中断该过程中所有在应用程序中输入金额的地方，并在半夜紧急修复它们。 尽管事实是，按照他们的工作逻辑，他们在小数点后三位有差异。 您可以撰写有关如何使用继承和上帝的话语将用于输入电子邮件地址的字段转换为用于输入地理地址的字段的诗。
其次：可测试性。 您也可以测试UI。 几乎所有的UI。 但是，就花费在开发测试和运行测试上的时间和资源而言，这将是昂贵的，并且不太可能在每次重建时都启动它们，但是当测试在发行版上崩溃时，这将是不可抗力的。 但是就分解而言，UI组件风险最高，它们通常（通常），最明显，最痛苦地破裂。 但是，从小部件本身撕下来的代码确实包含在单元测试中。 而且单元测试要便宜得多-编写起来更容易，而且您可以在进行任何更改后立即运行它，并始终确保没有任何问题。
第三，我认为最重要。 将一个UI与一个逻辑一起绘制成一个整体，很难克服懒惰并更深入地思考它的工作方式。 为了弄清理想的情况（除了理想的情况之外），当用户输入的正是他的期望，执行了要求的东西并获得了他想要的东西时。 那个神圣的程序员“一切都对我有用”。
视觉部分与逻辑部分的分离使您首先想到了视觉部分的工作原理：它所包含的内容，它所产生的内容，如果不期望进出的某些内容无法解决该怎么办。 与控件分开编写逻辑将迫使您在某些情况下编写该控件，即根据在特定位置使用特定应用程序的可能情况，包括在此处出现的处理错误，并帮助用户解决他在此处遇到的困难。 是的，是的，不是总是，或者不是在所有方面，总的来说，解决方案比针对特定案例量身定制的解决方案更好。
总结一下。 如果您的代码已经超出了“一个模型，一个查询，一个结果”的公式，那么您可以用Delph或iOS应用程序编写代码，折磨那些饱受折磨的网络，使它们变成0，或者用Python铆钉一些微控制器游戏。我强烈建议果断地将小部件从其工作的任何逻辑上分开，然后有可能使您的肉饼中的苍蝇更少。 尽管这种解决方案的优点一开始是完全不明显的，但您使用它的时间越长，这些优点就越多。