You're about half right - grouping related properties is the way to go. The core problem however is that whether the class is doing too much? If the class is long, with lists of properties than it's a good sign it could be broken up. For example, a HTTP Client should be handling the task of making HTTP requests and handling redirects, etc. Then to handle the data this requires I would have at least two more objects - Request and Response. This likely gets a lot of properties in the class you mentioned isolated in separate objects (you mentioned arrays, so not too far off this path).
For example, a good use case could be:
Code: Select all
$request = new Http_Request();
$request->setMethod(Request::GET);
$request->setUri('http://blog.example.com/rss');
$request->setHeader('Accept', 'application/rss+xml'); // content negotiation if enabled by target
// use client as a singleton instance
$response = Http_Client::getInstance()->request($request);
// have received a Http_Response object
if(!$response->isSuccess())
{
throw new Exception('Error occured or request could not complete. Received status code:' . $response->getStatusCode());
}
$rss = new SimpleXMLElement( $response->getBody() );
// do something with the RSS XML
If you follow the logic, the Response object contains all the results - response-headers, http codes and messages, the body of the response, etc. Similar thinking for the Request object - it's used to build a request separate from the client.
Bit of a ramble - but should offer some food for thought I hope

.