1: Just because some ubiquitous libraries have dictated a practice doesn't make it a good idea or a good model. In fact, Hibernate's tracking of mutable objects in the current session is one of the most painful things about it. There's nothing inherent about client server communication that forces beans on you?
2: That's good, but work in the constructor is by no means gone.
3: That sounds like god objects. "FinancialInstrumentService" is way too much functionality (or poorly named). Getting a current quote, getting historical quotes, doing quant-stuff and placing a trade are all completely separate concerns. Opening a document, saving it, printing it - all separate concerns that are better kept in separate interface. Now, there's little harm in having an implementation implement several interfaces if the implementations has much in common. Extra bonus: Easier to write tests for.
4: Mostly agree, but:
> Believe me in a quarterly release- developers get around only 3 weeks – rest is divided into BA, QA, UAT, freeze, deployment time.
I won't believe you, because I've worked on a team that pushed out releases every two weeks, and got 8-9 days development in for each.
That's what I meant - should have said interface_s_, I see now :)
Actually, opening a document is probably not even a good abstraction. DocProvider is better: You can have FileSystemDocProvider and BlankDocProvider - the latter can't meaningfully be said to "open" a document, but it's interacted with in the same way.
2: That's good, but work in the constructor is by no means gone.
3: That sounds like god objects. "FinancialInstrumentService" is way too much functionality (or poorly named). Getting a current quote, getting historical quotes, doing quant-stuff and placing a trade are all completely separate concerns. Opening a document, saving it, printing it - all separate concerns that are better kept in separate interface. Now, there's little harm in having an implementation implement several interfaces if the implementations has much in common. Extra bonus: Easier to write tests for.
4: Mostly agree, but:
> Believe me in a quarterly release- developers get around only 3 weeks – rest is divided into BA, QA, UAT, freeze, deployment time.
I won't believe you, because I've worked on a team that pushed out releases every two weeks, and got 8-9 days development in for each.