Is coupling functionality desired when the usage of a function can be predicted with near-perfect confidence?

softwareengineering.stackexchange https://softwareengineering.stackexchange.com/questions/409518

  •  10-03-2021
  •  | 
  •  

Question

I have a function whose job is to look through a string that is a post's content and find certain pieces:

public static function findInsidePostContent( $post = Null )
{

    //post_content comes from a WP_Post object.
    $post_blocks = \parse_blocks( $post->post_content );
    //Look inside, do some things.

}

The function has an absolute truth that we can always rely on: it only and solely works with a WP_Post object.

But, naturally, since the parameter is Null, there is a clear contradiction here, so, let's try to solve it by adding a specific line right at the start of the function:

$post = Utils::getPostObject( $post ); if( \is_wp_error( $post ) ) return $post;

Great, that function is always supposed to return a WP_Post object, unless something wrong happened.

But what we just did was heavily couple two seemingly unconnected pieces of code and, usually, that's bad. We also hid a dependency. But what if we can predict that in all the cases, you will always work with a WP_Post object? You'll always have to work resolve that WP_Post object somewhere before:

$post = Utils::getPostObject( 21 );
Utils::findInsidePostContent( '', [], $post );

This "call path" will never, ever change.

Wouldn't the coupling be justified?

Was it helpful?

Solution

Lets first see if calling the function getPostObject is justified at all, independent of the apparent coupling it produces.

The answer here depends entirely on what promises findInsidePostContent makes towards its callers. If findInsidePostContent has a precondition that it must be called with an WP_Post object, then inside the function there should at most be a check that the $post parameter really is a WP_Post object, but certainly no attempts to turn it into one.
On the other hand, if findInsidePostContent is supposed to be able to accept any argument that can be resolved into a WP_Post object, then the call to getPostObject is very legitimate.

To answer the question on coupling, I will assume that the call is legitimate.

While getPostObject should be blissfully unaware of the existence of findInsidePostContent, the latter function needs the services of getPostObject to do its job, because the post's content can only be accessed after it has been resolved/converted into a WP_Post object, which is exactly the job of getPostObject.

This means that the coupling is just as necessary as the coupling with \parse_blocks and the other functions that findIndidePostContent calls.

Licensed under: CC-BY-SA with attribution
scroll top