> > > > Mocking > > > > This isn't a terribly compelling argument. Readonly classes are typically > value objects; it's rare that you will mock them as they will be used as > messages or results, and you'll end up doing assertions against them — not > mocking them. > > Anything else it would enable?
If like me you have a lot of service-style classes with recursive autowired DI, making them all readonly is a no-brainer and mocking some of them sometimes make sense. I have no opinion in favor or against, but wanted to point out that to me value objects are less likely to be readonly than service classes, where mocking are common.
