我想停止在javascript中使用OOP,而是使用委派

I want to stop using OOP in javascript and use delegation instead

本文关键字:OOP 委派 javascript      更新时间:2023-09-26

在接触javascript一段时间后,我逐渐相信OOP不是正确的方法,或者至少不是广泛的方法。拥有两到三个级别的继承是可以的,但像在Java中那样使用完全OOP似乎并不合适。

该语言支持本机合成和委派。我只想用它。然而,我在复制OOP的某些好处时遇到了困难。

即:

  1. 我该如何检查一个对象是否实现了某种行为?我想到了以下方法
    • 检查对象是否具有特定方法。但这意味着要标准化方法名称,如果项目很大,它可能会很快变得麻烦,并导致java问题(object.hasMethod('emailRegexValidatorSimpleSuperLongNotConflicingMethodName')。。。它只会移动OOP的问题,而不是解决它。此外,如果存在方法,我找不到关于查找性能的信息
    • 将每个合成的对象存储在一个数组中,并检查该对象是否包含该合成器。类似于:object.hasComposite(compositorClass)……但这也不是真正优雅的,而且再次是OOP,只是不是标准的方式
    • 让每个对象都有一个"implements"数组属性,并让对象负责说明它是否实现了某个行为,无论是通过组合还是本机实现。灵活简单,但需要记住一些惯例。到目前为止,这是我的首选方法,但我仍在寻找
  2. 如何在不重复合成对象的所有设置的情况下初始化对象?例如,如果我有一个"textInput"类,它使用一定数量的验证器,这些验证器必须用变量初始化,而"emailInput"类使用完全相同的验证器,那么重复代码会很麻烦。如果验证器的接口发生了变化,那么使用它们的每个类中的代码都必须发生变化。我该如何轻松设置呢?我正在考虑的API应该像做object.comporters一样简单('emailValidator','lengthValidator'和'…')
  3. 让应用程序中运行的大多数函数通过应用程序()是否会导致性能损失?由于我将广泛使用委托,基本对象很可能几乎没有方法。所有方法都将由合成对象提供
  4. 有什么好的资源吗?我读过无数关于OOP与委派的帖子,以及委派的好处等等,但在一个大框架的范围内,我找不到任何关于"javascript委派做得好"的文章

编辑

进一步解释:

  1. 我还没有代码,我一直在研究纯OOP的框架,我陷入了困境,需要多重继承。因此,我决定彻底停课。所以我现在只是在理论层面上,并试图从中理解
  2. "作曲"可能是个错误的词;我指的是复合模式,它对树状结构非常有用。的确,在前端很少有树结构(当然,除了DOM),但我是为node.js开发的
  3. 我所说的"从OOP切换"的意思是,我将放弃定义类,使用"new"运算符,等等;我打算使用匿名对象,并用delegator来扩展它们。示例:

    var a = {};
    compositor.addDelegates(a,["validator", "accessManager", "databaseObject"]);
    

因此,"类"将是一个具有预定义delegator的函数:

  function getInputObject(type, validator){
       var input = {};
       compositor.addDelegates(input,[compositor,renderable("input"+type),"ajaxed"]);
       if(validator){input.addDelegate(validator);}
       return input;
  }

这有道理吗?

1) 我该如何检查一个对象是否实现了某种行为?

大多数人不会像这样去测试方法的存在。

  • 如果你想测试方法,以便分支并做不同的事情,如果它被发现或没有被发现,那么你可能正在做一些邪恶的事情(这种instanceof通常是OO代码中的一种代码气味)

  • 如果你只是检查一个对象是否实现了一个用于错误检查的接口,那么如果没有找到方法,那么不测试并让异常抛出也没什么好。我不知道有谁经常做这种检查,但我确信有人在做…

2) 如何在不重复合成对象的所有设置的情况下初始化对象?

如果将内部对象构造代码封装在函数或类中,那么我认为可以避免大部分重复和耦合。

3) 让应用程序中运行的大多数函数通过应用程序()是否会导致性能损失?

根据我的经验,除非绝对必要,否则我宁愿避免与this打交道。this很麻烦,在回调内部中断(我广泛使用它来进行迭代和异步),而且很容易忘记正确设置它。我试着用更传统的方法来构图。例如:

  1. 每个拥有的对象都是完全独立的,不需要查看其兄弟姐妹或所有者。这允许我直接调用它的方法,并让它成为自己的this

  2. 以属性的形式或作为传递给其方法的参数,为所属对象提供对其所有者的引用。这允许合成单元访问所有者,而不依赖于是否正确设置了this

  3. 使用mixin,在一个级别中压平单独的组成单元。这有重大的冲突问题,但让每个人都能看到彼此并分享相同的"这个"。Mixin还将代码与组合结构的变化解耦,因为不同的组合划分仍然会变平为相同的混合对象。

4) 有什么好的资源吗?

我不知道,所以如果你找到一个,告诉我:)