Title: Should a class be able to hold an instance of itself?
Tags: php;oop;instance;decoupling
Question: I am currently busy with a PSR-7 project with responses and requests.
Currently we are setting up an application in our index.php by doing something like:
$app = new Application();
$app-&gt;loadConfiguration(
'../config/global.yml',
// Should return the response?
$app-&gt;run((new ServerRequestFactory())-&gt;createServerRequestFromGlobals());
Here the run method also calls an emit method that is responsible for sending the headers and printing the body of the response.
The request and respons are now linked together in one call which makes it hard to test since you don't want to send the response with the headers straight to PHPUnit.
I have removed the emit call in the chain of the run method and added this to the index after the run method call:
// Send the response.
$app-&gt;send();
This way they are decoupled but the downside is I now have to hold a instance of my response in a response property inside my Application.php($app) class.
I want to move the response instance to the response class itself but my co-workers thinks a class should never hold an instance of itself. Yet when I look at frameworks this happens quite a lot. Is he right about this?
What arguments can I make to decouple my request and response besides easier testing?
I am pretty new to unit testing, one of the arguments I have already heard is that I should not test the full application anyways but rather separate components and therefore should not be worried about de-coupling the request and response.
Comment: @Andrew what exactly does it mean when you say "Neither should have knowledge of each other"? They work together, there will always be a point where you will have to pass a request to build up a response. Let's say I do split up my send method by holding a response instance to send later on, would this be correct?

Comment: @Andrew I thought so, thanks for clearing that up. Sometimes methods walk a fine line by doing a little bit too much though and it it hard to judge. Thanks for taking the time to respond!

Comment: You heard right, on both of your questions. Test components not whole applications. A class could hold an instance of itself but it's no the best idea in the world to do that. The request and response should be separate from each other, they will of course, interact with one another but neither should have knowledge of each other.

Comment: What I mean is they should never be tightly coupled. Of course at one point or another they will have to interact, there's no doubt about it, but the request shouldn't be responsable for the response or vice versa. Think of them as APIs, grab data from one to be used in the other.



{'source': 'StackExchangeDataset', 'subset': 'stackoverflow.com', 'metadata': {'AnswerCount': 0, 'CommentCount': 4, 'ContentLicense': 'CC BY-SA 3.0', 'CreationDate': '2016:00:11/28/16', 'FavoriteCount': None, 'PostTypeId': 1, 'Tags': '<php><oop><instance><decoupling>', 'Title': 'Should a class be able to hold an instance of itself?', 'ViewCount': 57, 'id': 40841816, 'user_AboutMe': "<p><strong>Hi there</strong></p>\n<p>I love programming, designing and coming up with fresh new ideas. My goto programming framework is Laravel complemented with Vue.js. I'm a quick learner and I love getting up to date on the latest technology.</p>\n<p>Helping people out with their programming conundrums is something I love to do.</p>\n", 'user_AccountId': 2652974.0, 'user_DisplayName': 'Stephan-v', 'user_Reputation': 17973.0, 'user_Views': 1007.0, 'user_id': 2294225.0}}