Или обращение контроля.
Я против синглтонов. Поясню, почему. Вот предположим вы пишете модульный тест на Class1 или Class2 (вы же пишите модульные тесты?). И хотите протестировать поведение Class1 в контексте взаимодействия с сессией. Если сессия — синглтон, то протестировать можно будет лишь косвенно, наблюдая только результат работы объекта сессии, но не самого Class1. Таким образом, тест класса Class1 становится зависим от объекта сессии, а значит и его (сессии) кода, что противоречит модульности. Наоборот, если используется инверсия зависимостей, вы просто подсунете в object1.work(sessionMock) (что такое mock) и сможете тестировать ТОЛЬКО поведение Class1, проверяя какие именно методы мок-объекта вызываются, в каком порядке и с какими параметрами.
Я против синглтонов. Поясню, почему. Вот предположим вы пишете модульный тест на Class1 или Class2 (вы же пишите модульные тесты?). И хотите протестировать поведение Class1 в контексте взаимодействия с сессией. Если сессия — синглтон, то протестировать можно будет лишь косвенно, наблюдая только результат работы объекта сессии, но не самого Class1. Таким образом, тест класса Class1 становится зависим от объекта сессии, а значит и его (сессии) кода, что противоречит модульности. Наоборот, если используется инверсия зависимостей, вы просто подсунете в object1.work(sessionMock) (что такое mock) и сможете тестировать ТОЛЬКО поведение Class1, проверяя какие именно методы мок-объекта вызываются, в каком порядке и с какими параметрами.