Property Lookup Cache in JavaScript

Property lookup can be a performance bottleneck, especially when dealing with large objects or frequent access to the same properties. This challenge asks you to implement a caching mechanism that stores the results of property lookups, significantly speeding up subsequent accesses to the same properties. This is particularly useful in scenarios like rendering complex UI components or performing repetitive calculations based on object properties.

Problem Description

You are tasked with creating a PropertyCache class in JavaScript. This class should wrap an object and provide a method get(propertyName) that retrieves the value of a specified property from the wrapped object. The key feature is that the get method should cache the results of property lookups. The first time get(propertyName) is called for a given property, it should retrieve the value from the wrapped object and store it in the cache. Subsequent calls to get(propertyName) should return the cached value directly, without accessing the original object.

Key Requirements:

• Caching: Store property values after the first lookup.
• Return Cached Value: Return the cached value on subsequent calls with the same property name.
• Original Object Access: Only access the original object during the initial lookup.
• Handle Non-Existent Properties: If the property does not exist on the wrapped object, get(propertyName) should return undefined (just like accessing a non-existent property directly).
• Immutability of Wrapped Object: The PropertyCache should not modify the original object.

Expected Behavior:

The PropertyCache class should be instantiated with an object. The get method should behave as described above, caching property values and returning them efficiently.

Edge Cases to Consider:

• Null or Undefined Wrapped Object: Handle cases where the object passed to the constructor is null or undefined. Throw an error in these cases.
• Non-String Property Names: While less common, consider how your cache should handle non-string property names (e.g., numbers, symbols). For simplicity, assume property names will always be strings.
• Object Property Changes: The cache should not update if the original object's property changes after the initial lookup. The cached value should remain constant.

Examples

Example 1:

Input:
const obj = { a: 1, b: 2 };
const cache = new PropertyCache(obj);

cache.get('a'); // Returns 1 (and caches it)
cache.get('a'); // Returns 1 (from cache)
cache.get('b'); // Returns 2 (and caches it)

Explanation: The first call to cache.get('a') retrieves the value 1 from obj and caches it. The second call returns the cached value 1 directly. Similarly for 'b'.

Example 2:

Input:
const obj = { x: 10 };
const cache = new PropertyCache(obj);

cache.get('y'); // Returns undefined (property 'y' doesn't exist)
cache.get('x'); // Returns 10 (and caches it)
cache.get('x'); // Returns 10 (from cache)

Explanation: cache.get('y') returns undefined because 'y' is not a property of obj. The subsequent calls to cache.get('x') return the cached value.

Example 3: (Edge Case)

Input:
const obj = { z: 5 };
const cache = new PropertyCache(obj);

cache.get('z'); // Returns 5
obj.z = 15; // Modify the original object
cache.get('z'); // Returns 5 (still the cached value)

Explanation: Modifying the original object after the initial lookup does not update the cached value. The cache retains the original value of 5.

Constraints

• Object Size: The wrapped object can contain up to 1000 properties.
• Property Names: Property names will always be strings.
• Performance: Subsequent get calls for the same property should be significantly faster than the initial lookup (ideally O(1) time complexity).
• Memory Usage: The cache should not consume excessive memory.

Notes

Consider using a JavaScript object (or Map) to implement the cache. Think about how to handle the initial lookup and caching logic efficiently. The goal is to optimize property access performance without significantly increasing code complexity. Focus on clarity and correctness first, then consider performance optimizations.