I get where you're coming from, but this just shifts the coupling from the code to the data. Which is totally fine if you're in a situation where you have complete control over all of your datasources and there aren't any aberrations from the model that was defined at inception, but you can fail pretty hard on what could be valid data if you go too far down this road.
I think there's definitely merit into asking yourself whether or not an associative array is appropriate for your use case before forging ahead, but taking it as a maxim is just gonna line you up for all sorts of different trouble.
Having strictly defined interfaces solely for data in a language that's (I've been assuming by design) not strictly typed seems like trying to make a sledgehammer into a bandsaw by yelling at it to be sharper. Why not build your test suite around standardized return data if that's a requirement instead of trying to make PHP into Java cough*zend*cough.
Frankly, i'm not really sure if it's that good design to return these sort of reports. To me that means the service has knowledge that there's is some sort of UI where those values are somewhat important. I left myself a backdoor by giving SenderReport a method to print itself which gives the object some behaviour.
I do however think that it's useful to give data some context by encapsulating it into an object. It allows us to fall back on sane defaults and handle other data related issues in a very limited scope. After all you can't tell data to do anything. With objects you can.
I can't say i have much experience about this, but just a hunch that a system can be more robust when the focus is not on what kind of data is processed but what kind of services objects provide for each other.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I get where you're coming from, but this just shifts the coupling from the code to the data. Which is totally fine if you're in a situation where you have complete control over all of your datasources and there aren't any aberrations from the model that was defined at inception, but you can fail pretty hard on what could be valid data if you go too far down this road.
I think there's definitely merit into asking yourself whether or not an associative array is appropriate for your use case before forging ahead, but taking it as a maxim is just gonna line you up for all sorts of different trouble.
Having strictly defined interfaces solely for data in a language that's (I've been assuming by design) not strictly typed seems like trying to make a sledgehammer into a bandsaw by yelling at it to be sharper. Why not build your test suite around standardized return data if that's a requirement instead of trying to make PHP into Java cough*zend*cough.
Thanks for your comment!
Frankly, i'm not really sure if it's that good design to return these sort of reports. To me that means the service has knowledge that there's is some sort of UI where those values are somewhat important. I left myself a backdoor by giving SenderReport a method to print itself which gives the object some behaviour.
I do however think that it's useful to give data some context by encapsulating it into an object. It allows us to fall back on sane defaults and handle other data related issues in a very limited scope. After all you can't tell data to do anything. With objects you can.
I can't say i have much experience about this, but just a hunch that a system can be more robust when the focus is not on what kind of data is processed but what kind of services objects provide for each other.