如何实现嵌套对象自引用？咨询更优方案及是否为反模式

Hey there! Great question—this is such a common headache when working with nested JavaScript objects, especially once you move past those basic examples you mentioned. Let's dive into this properly.

First, Let's Clarify the Goal #

You want every method inside each nested object to have this refer to the object it belongs to, right? No accidental fallback to the outer object or global scope. That makes total sense if each nested level has its own state and behavior.

Better Implementation Options #

Let's go through a few clean, maintainable approaches depending on your use case:

1. Factory Functions (Most Straightforward) #

Factory functions are perfect here because they create a closed scope for each object, ensuring methods naturally bind to the correct this. They're easy to read and modify:

function createTodoList() {
  // Create inner object first to lock in its context
  const itemManager = {
    addItem(text) {
      console.log(`Adding item to manager: ${text}`);
      console.log("This refers to:", this); // Points to itemManager
    }
  };

  return {
    title: "My Todo List",
    getTitle() {
      console.log(`List title: ${this.title}`); // Points to the outer todo list object
      return this.title;
    },
    items: itemManager
  };
}

const myList = createTodoList();
myList.getTitle(); // Logs the outer object
myList.items.addItem("Buy milk"); // Logs itemManager

2. ES6 Classes (For Reusable Structures) #

If you plan to create multiple instances of this nested structure, classes are a great choice. Each instance (and its nested instances) will have their own this context:

class ItemManager {
  constructor() {
    this.items = [];
  }

  addItem(text) {
    this.items.push(text);
    console.log(`Added to manager: ${text}`);
    console.log("This refers to:", this); // Points to the ItemManager instance
  }
}

class TodoList {
  constructor(title) {
    this.title = title;
    this.itemManager = new ItemManager();
  }

  getTitle() {
    console.log(`List title: ${this.title}`); // Points to the TodoList instance
    return this.title;
  }
}

const groceryList = new TodoList("Grocery Run");
groceryList.getTitle(); // Logs TodoList instance
groceryList.itemManager.addItem("Eggs"); // Logs ItemManager instance

3. Object.create (For Prototype-Based Inheritance) #

If you need to share methods across multiple nested objects via prototypes, Object.create works well. It lets you define reusable method templates while keeping each object's this unique:

// Reusable prototype for inner managers
const itemManagerProto = {
  addItem(text) {
    this.items.push(text);
    console.log("This refers to:", this); // Points to the specific manager instance
  }
};

// Create outer object with nested inner instance
const todoList = Object.create({}, {
  title: { value: "Work Tasks", enumerable: true },
  getTitle: {
    value() {
      console.log(`List title: ${this.title}`); // Points to todoList
      return this.title;
    },
    enumerable: true
  },
  itemManager: {
    value: Object.create(itemManagerProto, { items: { value: [], enumerable: true } }),
    enumerable: true
  }
});

todoList.getTitle(); // Logs todoList
todoList.itemManager.addItem("Finish report"); // Logs the itemManager instance

Is This an Anti-Pattern? #

Short answer: It depends on your use case.

• Not an anti-pattern if: Each nested object is a distinct, independent entity with its own state and behavior. For example, a TodoList with an ItemManager that handles its own item logic—this is a clean separation of concerns, and having this point to each entity is exactly what you want.
• Could be an anti-pattern if: Your nested objects are just groups of properties (not independent entities) and you're forcing this context where it's unnecessary. For example, if an inner "group" only exists to organize outer object properties, and its methods need to access the outer object's state, tying this to the inner group would force you to write extra code (like passing parent references) to access the parent context, which is messy.

Quick Pro Tip #

Avoid over-nesting! If your object structure goes 3+ levels deep, it's probably time to split it into separate modules or classes. Deep nesting makes code harder to read, test, and maintain—even with perfect this context.

内容的提问来源于stack exchange，提问作者vilbur