3 clarity
source | link

I'm primarily a web UI dev but it sounds to me like your intuitive discomfort might be less about the instance pass-through and more about the fact that you're going a bit procedural with that controller. Should your controller be sweating all these details? Why does it even reference more than one other object's name for getting audio played?

In OOP design, I tend to think in terms of what's evergreen and what's more likely to be subject to change. The subject to change stuff is what you're going to want to tend to put in your larger object boxes so you can maintain consistent interfaces even as players change or new options are added. Or you find yourself wanting to swap audio objects or components therein wholesale.

In this case, your controller needs to identify that there's a need to play an audio file and then have a consistent/evergreen way of getting it played. The audio player stuff on the other hand could easily change as technology and platforms get altered or new choices are added. All of those details should sit underneath an interface of a larger composite object, IMO, and you shouldn't have to rewrite your controller when the details of how audio gets played change. Then when you pass an object instance with the details like file location into the larger object all that swapping around is done in the interior of an appropriate context where someone is less likely to do something silly with it.

So in this case I don't think it's that object instance getting tossed around that might be bugging you. It's that Captain Picard is running down to the engine room to turn the warp core on, running back up to the bridge to plot the coordinates, and then hitting the "punch-it" button after turning the shields on rather than simply saying "Take us to planet X at Warp 9. Make it so." and letting his crew sort out the details. Because when he handles it that way, he can captain any ship in the fleet without knowing the layout of every ship and how everything works. And that's ultimately what good OOP's all aboutthe biggest OOP design win to shoot for, IMO.

I'm primarily a web UI dev but it sounds to me like you're going a bit procedural with that controller. Should your controller be sweating all these details? Why does it even reference more than one other object's name for getting audio played?

I tend to think in terms of what's evergreen and what's more likely to be subject to change. The subject to change stuff is what you're going to want to tend to put in your larger object boxes so you can maintain consistent interfaces even as players change or new options are added. Or you find yourself wanting to swap audio objects or components therein wholesale.

In this case, your controller needs to identify that there's a need to play an audio file and then have a consistent/evergreen way of getting it played. The audio player stuff on the other hand could easily change as technology and platforms get altered or new choices are added. All of those details should sit underneath an interface of a larger composite object, IMO, and you shouldn't have to rewrite your controller when the details of how audio gets played change. Then when you pass an object instance with the details like file location into the larger object all that swapping around is done in the interior of an appropriate context where someone is less likely to do something silly with it.

So in this case I don't think it's that object instance getting tossed around that might be bugging you. It's that Captain Picard is running down to the engine room to turn the warp core on, running back up to the bridge to plot the coordinates, and then hitting the "punch-it" button after turning the shields on rather than simply saying "Take us to planet X at Warp 9. Make it so." and letting his crew sort out the details. Because when he handles it that way, he can captain any ship in the fleet without knowing the layout of every ship and how everything works. And that's ultimately what good OOP's all about, IMO.

I'm primarily a web UI dev but it sounds to me like your intuitive discomfort might be less about the instance pass-through and more about the fact that you're going a bit procedural with that controller. Should your controller be sweating all these details? Why does it even reference more than one other object's name for getting audio played?

In OOP design, I tend to think in terms of what's evergreen and what's more likely to be subject to change. The subject to change stuff is what you're going to want to tend to put in your larger object boxes so you can maintain consistent interfaces even as players change or new options are added. Or you find yourself wanting to swap audio objects or components therein wholesale.

In this case, your controller needs to identify that there's a need to play an audio file and then have a consistent/evergreen way of getting it played. The audio player stuff on the other hand could easily change as technology and platforms get altered or new choices are added. All of those details should sit underneath an interface of a larger composite object, IMO, and you shouldn't have to rewrite your controller when the details of how audio gets played change. Then when you pass an object instance with the details like file location into the larger object all that swapping around is done in the interior of an appropriate context where someone is less likely to do something silly with it.

So in this case I don't think it's that object instance getting tossed around that might be bugging you. It's that Captain Picard is running down to the engine room to turn the warp core on, running back up to the bridge to plot the coordinates, and then hitting the "punch-it" button after turning the shields on rather than simply saying "Take us to planet X at Warp 9. Make it so." and letting his crew sort out the details. Because when he handles it that way, he can captain any ship in the fleet without knowing the layout of every ship and how everything works. And that's ultimately the biggest OOP design win to shoot for, IMO.

2 added 54 characters in body
source | link

I'm primarily a web UI dev but it sounds to me like you're going a bit procedural with that controller. Should your controller be sweating all these details? Why does it even reference more than one other object's name for getting audio played?

I tend to think in terms of what's evergreen and what's more likely to be subject to change. The subject to change stuff is what you're going to want to tend to put in your larger object boxes so you can maintain consistent interfaces even as players change or new options are added. Or you find yourself wanting to swap audio objects or components therein wholesale.

In this case, your controller needs to identify that there's a need to play an audio file and then have a consistent/evergreen way of getting it played. The audio player stuff on the other hand could easily change as technology and platforms get altered or new choices are added. All of those details should sit underneath an interface of a larger composite object, IMO, and you shouldn't have to rewrite your controller when the details of how audio gets played change. Then when you pass an object instance with the details like file location into the larger object all that swapping around is done in the interior of an appropriate context where someone is less likely to do something silly with it.

So in this case I don't think it's that object instance getting tossed around that might be bugging you. It's that Captain Picard is running down to the engine room to turn the warp core on, running back up to the bridge to plot the coordinates, and then hitting the "punch-it" button after turning the shields on rather than simply saying "Take us to planet X at Warp 9. Make it so." and letting his crew sort out the details. Because when he handles it that way, he can captain any ship in the fleet without knowing the layout of every ship and how everything works. And that's ultimately what good OOP's all about, IMO.

I'm primarily a web UI dev but it sounds to me like you're going a bit procedural with that controller. Should your controller be sweating all these details? Why does it even reference more than one other object's name for getting audio played?

I tend to think in terms of what's evergreen and what's more likely to be subject to change. The subject to change stuff is what you're going to want to tend to put in your larger object boxes so you can maintain consistent interfaces even as players change or new options are added. Or you find yourself wanting to swap audio objects or components therein wholesale.

In this case, your controller needs to identify that there's a need to play an audio file and then have a consistent/evergreen way of getting it played. The audio player stuff on the other hand could easily change as technology and platforms get altered or new choices are added. All of those details should sit underneath an interface of a larger composite object, IMO, and you shouldn't have to rewrite your controller when the details of how audio gets played change. Then when you pass an object instance with the details like file location into the larger object all that swapping around is done in the interior of an appropriate context where someone is less likely to do something silly with it.

So in this case I don't think it's that object instance getting tossed around that might be bugging you. It's that Captain Picard is running down to the engine room to turn the warp core on, running back up to the bridge to plot the coordinates, and then hitting the "punch-it" button after turning the shields on rather than simply saying "Take us to planet X at Warp 9. Make it so." and letting his crew sort out the details. Because when he handles it that way, he can captain any ship in the fleet without knowing the layout of every ship and how everything works.

I'm primarily a web UI dev but it sounds to me like you're going a bit procedural with that controller. Should your controller be sweating all these details? Why does it even reference more than one other object's name for getting audio played?

I tend to think in terms of what's evergreen and what's more likely to be subject to change. The subject to change stuff is what you're going to want to tend to put in your larger object boxes so you can maintain consistent interfaces even as players change or new options are added. Or you find yourself wanting to swap audio objects or components therein wholesale.

In this case, your controller needs to identify that there's a need to play an audio file and then have a consistent/evergreen way of getting it played. The audio player stuff on the other hand could easily change as technology and platforms get altered or new choices are added. All of those details should sit underneath an interface of a larger composite object, IMO, and you shouldn't have to rewrite your controller when the details of how audio gets played change. Then when you pass an object instance with the details like file location into the larger object all that swapping around is done in the interior of an appropriate context where someone is less likely to do something silly with it.

So in this case I don't think it's that object instance getting tossed around that might be bugging you. It's that Captain Picard is running down to the engine room to turn the warp core on, running back up to the bridge to plot the coordinates, and then hitting the "punch-it" button after turning the shields on rather than simply saying "Take us to planet X at Warp 9. Make it so." and letting his crew sort out the details. Because when he handles it that way, he can captain any ship in the fleet without knowing the layout of every ship and how everything works. And that's ultimately what good OOP's all about, IMO.

1
source | link

I'm primarily a web UI dev but it sounds to me like you're going a bit procedural with that controller. Should your controller be sweating all these details? Why does it even reference more than one other object's name for getting audio played?

I tend to think in terms of what's evergreen and what's more likely to be subject to change. The subject to change stuff is what you're going to want to tend to put in your larger object boxes so you can maintain consistent interfaces even as players change or new options are added. Or you find yourself wanting to swap audio objects or components therein wholesale.

In this case, your controller needs to identify that there's a need to play an audio file and then have a consistent/evergreen way of getting it played. The audio player stuff on the other hand could easily change as technology and platforms get altered or new choices are added. All of those details should sit underneath an interface of a larger composite object, IMO, and you shouldn't have to rewrite your controller when the details of how audio gets played change. Then when you pass an object instance with the details like file location into the larger object all that swapping around is done in the interior of an appropriate context where someone is less likely to do something silly with it.

So in this case I don't think it's that object instance getting tossed around that might be bugging you. It's that Captain Picard is running down to the engine room to turn the warp core on, running back up to the bridge to plot the coordinates, and then hitting the "punch-it" button after turning the shields on rather than simply saying "Take us to planet X at Warp 9. Make it so." and letting his crew sort out the details. Because when he handles it that way, he can captain any ship in the fleet without knowing the layout of every ship and how everything works.