Jestem przede wszystkim twórcą interfejsu WWW, ale wydaje mi się, że twój intuicyjny dyskomfort może być mniej związany z przekazywaniem instancji, a bardziej z faktem, że masz trochę proceduralne z tym kontrolerem. Czy kontroler powinien pocić wszystkie te szczegóły? Dlaczego odwołuje się nawet do nazwy więcej niż jednego innego obiektu do odtwarzania dźwięku?
W projektowaniu OOP mam tendencję do myślenia w kategoriach tego, co jest wiecznie zielone i co może ulec zmianie. Przedmiotem zmian jest to, co będziesz chciał umieścić w swoich większych obiektach, aby zachować spójne interfejsy, nawet gdy gracze się zmieniają lub dodaje się nowe opcje. Lub też chcesz hurtowo zamienić obiekty audio lub komponenty.
W takim przypadku kontroler musi stwierdzić, że istnieje potrzeba odtworzenia pliku audio, a następnie mieć spójny / wiecznie zielony sposób na jego odtworzenie. Z drugiej strony elementy odtwarzacza audio mogą łatwo ulec zmianie wraz ze zmianą technologii i platform lub dodaniem nowych opcji. Wszystkie te szczegóły powinny znajdować się pod interfejsem większego obiektu złożonego, IMO, i nie powinno być konieczne przepisywanie kontrolera, gdy zmieniają się szczegóły dotyczące odtwarzania dźwięku. Następnie, gdy przekazujesz instancję obiektu ze szczegółami, takimi jak lokalizacja pliku, do większego obiektu, wszystko to zamiana odbywa się we wnętrzu odpowiedniego kontekstu, w którym ktoś jest mniej skłonny zrobić z nim coś głupiego.
Więc w tym przypadku nie sądzę, że to rzucanie instancją obiektu może być dla ciebie problemem. Chodzi o to, że kapitan Picard biegnie do maszynowni, aby włączyć rdzeń osnowy, biegnie z powrotem do mostu, aby wyznaczyć współrzędne, a następnie naciska przycisk „uderz go” po włączeniu osłon, zamiast po prostu powiedzieć „Weź nas na planetę X w Warp 9. Zrób to. ” i pozwalając swojej załodze uporządkować szczegóły. Ponieważ, gdy sobie z tym poradzi, może kapitanem każdego statku we flocie, nie znając układu każdego statku i tego, jak wszystko działa. I to ostatecznie największa wygrana w projektowaniu OOP, do której strzelać, IMO.