Return to Answer

if(!$uri) {
    //get currenturl
    ...
if(!is_array($uri)) {
    ...
} else {

if(!$uri) {
    //get currenturl
    ...
}
if(!is_array($uri)) {
    ...
} else {

if(!$uri) {
    //get currenturl
    ...
}
if(is_string($uri)) {
    ...
    return;
}
// it's not empty and it's not a string.

OR

Yet the code in the question isn't simple. It's 180 lines of code that mostly duplicates 2 built-in php functions. To wrap the functionality in a class, simple would be (example and almost pseudo-code):

Also from the question, the class:

relies a lot on that functionality (eg the Router class and some HTML helpers)

Yet the code in the question has no dependencies at all. That kind of implies that the class may not actually fit the purpose it has been written for.

In this way the embedded logic in the build method is more obvious - and the repetative in_array !empty logic is avoided.

Yet the code in the question isn't simple. It's 180 lines of code that mostly duplicates built-in php functions. To wrap the functionality in a class, simple would be (example and almost pseudo-code):

In this way the embedded logic in the build method is separated and more obvious - and the repetative in_array !empty logic is avoided. It also becomes possible to run the _prepare function whenever the data changes rather than each time a call is made to return output.

Assuming your code already works you're in a perfect position to write a few unit tests for your class (if you don't already have some) - and then start tweaking it. Writing unit tests will give you the confidence to rip the guts out of any code and know that if/when the tests pass - you've safe to commit your changes and benefit from your shiny(er) code and/or new-found knowledge.

The way the class works is only 'easy' to use if you want an absolute url. The build method should be refactored to permit only real possibilities. If you're already using the class with more permutations than just absolute and relative urls - you'll need to decide whether to change the calls or the code so that it still works.

Assuming your code already works you're in a perfect position to write a few unit tests for your class (if you don't already have some) - and then start tweaking it. Writing unit tests will give you the confidence to rip the guts out of any code and know that if/when the tests pass - you've safe to commit your changes and benefit from your shiny(er) code and/or new-found knowledge.