Programming Exercise Review

#Overview

This project contains a review of a programming exercise I encountered, where I was tasked with analyzing and implementing a data structure in PHP. The exercise presented an unusual design pattern, which I'll explain below. In this document, I will:

1. Explain the original approach I encountered.
2. Identify what’s bad about this approach.
3. Propose a better solution based on common best practices.

#The Original Approach

In the exercise, the following data structure was given to me to be used:

 1Example Object
 2(
 3    [1] => Example Object
 4        (
 5            [1] => Array
 6                (
 7                    [0] => Array
 8                        (
 9                            [name] => John
10                        )
11
12                )
13
14        )
15
16)

When I saw this, I was immediately confused. Out of my own curiosity, I couldn't help but wonder how someone would end up with a structure like this, so I reconstruct the object, just to see, like so:

 1#[\AllowDynamicProperties]
 2class Example {
 3    public function __construct($value = null) {
 4        $this->{1} = $value; // Dynamically assigning property "1"
 5    }
 6}

#Reconstructing the Original Structure

Now we can recreate the original structure like this:

 1$instance = new Example(new Example([['name' => 'John']]));
 2print_r($instance);

Which produces:

 1Example Object
 2(
 3    [1] => Example Object
 4        (
 5            [1] => Array
 6                (
 7                    [0] => Array
 8                        (
 9                            [name] => John
10                        )
11                )
12        )
13)

At this point, the mystery is solved. The structure is created by nesting instances of the same class and assigning values to a dynamically named property using a numeric key.

#Why This Is Problematic

While this technically works, there are several issues with this approach.

#1. Numeric Property Names

PHP does not allow numeric property names to be declared in a class. The only way to achieve this is through dynamic property assignment using $this->{1}.

This is not something most developers expect to see, and it makes the code harder to understand at a glance.

#2. Dynamic Properties Are Deprecated

As of PHP 8.2, dynamic properties are deprecated. This means that without the #[\AllowDynamicProperties] attribute, this code will raise warnings.

Future versions of PHP may remove this behavior entirely.

Relying on deprecated features is a strong signal that the approach is not future proof.

#3. Poor Readability

Looking at this structure:

 1$instance->{1}->{1}[0]['name'];

It is not immediately clear what each level represents. There is no semantic meaning behind the keys.

Compare that to something like:

 1$instance->users[0]['name'];

The second example is much easier to understand.

#4. Unnecessary Complexity

There is no clear benefit to wrapping arrays inside recursive objects like this. It introduces extra layers without adding meaningful structure or clarity.

#A Better Approach

If the goal is simply to store a list of records, a straightforward and idiomatic approach would look like this:

 1class Example {
 2    public array $items;
 3
 4    public function __construct(array $items = []) {
 5        $this->items = $items;
 6    }
 7}
 8
 9$instance = new Example([
10    ['name' => 'John']
11]);
12
13print_r($instance);

Output:

 1Example Object
 2(
 3    [items] => Array
 4        (
 5            [0] => Array
 6                (
 7                    [name] => John
 8                )
 9        )
10)

This is much clearer. The intent is obvious, and the structure is easy to work with.

#If Nesting Is Required

If there is a legitimate need for nesting, it is better to model that relationship explicitly:

 1class Node {
 2    public array $children;
 3
 4    public function __construct(array $children = []) {
 5        $this->children = $children;
 6    }
 7}
 8
 9$instance = new Node([
10    new Node([
11        ['name' => 'John']
12    ])
13]);
14
15print_r($instance);

Now the structure communicates intent. Each level represents a node with children, which is a common and understandable pattern.

#Final Thoughts

This exercise was a good reminder that just because something is possible does not mean it is a good idea.

The original structure relies on behavior that is:

• Non standard
• Difficult to read
• Deprecated in modern PHP

In real world development, clarity and maintainability matter far more than clever or obscure constructs.

#A Note on Interview Challenges

This also raises a broader point about programming exercises in interviews.

Challenges should reflect real world scenarios and encourage good practices. When exercises rely on obscure patterns or edge case behavior, they risk evaluating a candidate's ability to decipher confusion rather than their ability to write solid, maintainable code.

As developers, we should aim to do better. Interviews should help surface how someone thinks, how they structure solutions, and how they communicate intent through code.

#Conclusion

Reconstructing this data structure was an interesting exercise, but it highlights a clear gap between what is possible and what is practical.

The better approach is simple:

• Use clear property names
• Avoid dynamic properties
• Favor readability over cleverness

That is the kind of code that scales, survives, and actually helps teams move forward.