Object-Oriented – Why Use First Class Collections?

Books can be wrong or misleading. It is certainly true that having getters and setters for every field provides little more encapsulation than having those fields be public, and it's unfortunate that this kind of design is very widespread.

But it's nonsense to conclude that getters and setters should be avoided altogether. Instead, they should be added deliberately where appropriate, as part of the API design of the class:

1. If everything a field does can be handled by domain-specific methods, don't have a getter or setter - this is the best case.
2. If the value of a field is by itself useful and necessary for other classes, add a getter (not a setter)
3. If the fields represents something like a configuration value, a way for the behaviour of the object to be influenced from outside, add a setter (and a getter iff knowing this configuration could also be useful to other classes).

A Comparator could be seen as an example for case 2, especially if the Comparator is deliberately used instead of having the class implement Comparable. This indicates that the comparison logic is external to the class, and it depends on the field, so the field is useful outside the class.

A compromise might be to have a package private (default visibility) getter and keep the comparator in the same package - or even have it as an inner class that accesses the private field. That would be appropriate if you want the class itself to offer a choice of different sort orders.

If your only concern is that the sort order may change globally in the future, I'd actually stay with Comparable - it's still a change in once place, no need to separate it artificially.

I am not very sure about what you want from your question, but here are two methods I can think of, with the objectives to:

1. provide optimum performance
2. maintain flexibility through type abstraction

About your method: Why did you create the pageData class? Why couldn't you store them in a dynamic object/associative array? Then create an abstract method getTagType() in the FragmentBase abstract class, with implementations such as:

public function getTagType() : string{
    return "JS-FILES";
}

So you can, for example, store an object as $pageData[$fragment->getTagType()][] = $fragment;, then given the type from the HTML comment, search for the object from that array.

Another method: What about giving the fragments unique IDs? I cannot elaborate on this since I don't understand why you need to search for an instance from an array. Is there one corresponding object per fragment (HTML comment)? If that is the case, why not simply put the ID in the comment, then retrieve the object using the ID when you render the page? In this case, it gets even faster because direct numeric key to get from a single-dimensional array is always the fastest method to retrieve an element from an array.

Third method: I think this is really irrelevant with your case here. You can use an in-memory SQL database (such as new SQLite3(":memory:")) to create a table that indexes every object (every object needs a unique ID to be a placeholder in the table). Then you can easily use an SQL query to search from the many entries, more efficiently. However, I think that SQLite only improves performance when you are processing a really big amount of data (so that the time to prepare/parse statements is shorter than time for manually searching the data), especially when the data will retain for a long time (so not good for webpage-preprocessing PHP on HTTP servers) because the initialization of the database every time is time-consuming, and the data have to be really frequently reused so as to make the time for preparing statements negligible.