Javascript 在getter方法中实例化类是否内存效率低下？什么OOP设计可以防止这种情况？

我有一个getter方法，它从反序列化数据实例化类。我怀疑这是一种非常低效的做事方式

class Container {
  get content() {
    let contentList = []
    for (let c of this._content) { // this._content is an array of objects
      contentList.push(new ContentTypes[c.type](c)) //ContentTypes is a mapping between type names and classes
    }
    return contentList
  }
}

---

OOP领域中合适的设计模式是什么？

无论代码是在getter还是在方法中，效率都不会改变。但是改变的是使用您的类编写代码的人的期望

我不希望访问对象上的属性会产生太多开销。因此，当使用

容器

的实例时，如果我看到

contents

属性，我不会期望它做很多工作。你的有一点

我想：

保留您返回的内容的副本（使您返回的内容不可变），并且仅当它所依赖的内容发生更改或

使其成为一种方法（显式）

（或者我可以两者兼而有之。）

我希望方法调用比属性访问产生更多的开销。我不知道是否有一个特定的OOP原则可以引用，但这是我的经验观点（不管它是否值得）

但是，请注意，在野外也有反例。一个著名且直接适用的方法是DOM元素的

innerHTML

属性，它是一个访问器属性，在使用它时可以做很多工作

下面是一个返回您保留并重新返回的不可变对象的示例，但当其基础数据发生更改时将失效：

class Container {
    constructor() {
        this._content = [];
        this._exposedContent = null;
    }

    addContent(content) {
        this._content.push(content);
        this._exposedContent = null; // Invalidating the cached copy if any
    }

    get content() {
        // Do we have a cached copy?
        if (!this._exposedContent) {
            // No, create it
            this._exposedContent = this._content.map(
                c => Object.freeze(new ContentTypes[c.type](c))
            );
        }
        return this._exposedContent;
    }
}

（您也可能会在一段时间后使副本过期。）

---

但这是一个判断，它是否值得内存开销和复杂性与

内容中的实际代码相比。我的默认立场是使用方法代替（
getContent
或类似方法），而不是缓存，但这是一个判断调用。
“OOP领域中合适的设计模式是什么？”你到底想实现什么？我需要防止getter函数每次调用都初始化一个新对象，然后缓存它们并从缓存返回。但我的问题更广泛——您的代码试图做什么？您不会仅对代码行应用设计模式，而是对问题应用设计模式。也许你需要一个工厂模式，也许不是。我真的不知道。@t.J.Crowder，对！澄清。