Is Annotated POJO a POJO ?

[Arno Werr]

And even when you speak about non-POJO OO application they may be unit testable as well (probably, you have more complex setup and so on, but it does not mean untestability).

Oh, that's for sure.
It's virtual world anyway.
Given enough time and money one can create 'a crow fish that whistle'. The only interesting issue what if instead of 'a well of money' you have a budget and 'all the time you can get' - a project schedule, would you be willing to create 'more complex setup and so on' for testing your objects/use cases? It is definitely possible to test through POJT even EJB 2x, if it's OK with your team that your testing code paraphernalia would eventually and inevitably overgrow your application code. Is EJB 2x unit-testable? Yes, it is. Is it worth it? No.

I'm sorry, but ability to unit-testi the application in automated mode is completely orthogonal to object orientation. While first it became popular (not appeared, but exactly became popular and wide-spreaded) in the OO environment, there are similar systems for completely procedural environments.

Do not agree. It is through POJT one can immediately identify a good OOP design from a bad one. Because only through POJT one can practically appreciate why we need all those things called 'good' OOP practices - GOF patterns and design principles like 'code through interface not through implementation', 'loosely coupled - tightly cohesive', 'holliwood', 'talk only to immediate friends' etc. Why are they 'good' if on surface they add up to my code base, and hence complicate code management? Well, they are good OOP, because if I don't follow them, than I would weep on testing stage.
So to me (no matter what 'official' or semi-official 'gurus' would say ) testing requirements is a driving engine for creating a 'good' object. So much about being 'completely orthogonal to object orientation'.

there are similar systems for completely procedural environments.

And how it's called - 'a bunch of code-monkeys'?

Cheers,
Arno

[cepage]

I have to be somewhat pragmatic about the whole idea though. Is there a static analysis tool that can check for classes which are POJOs? Is the question just academic? Does it really matter?

It matters to me. The only reason I have been able to introduce Spring into certain consulting environments is because I do not introduce depedencies onto the Spring framework into my client's application code.

This means no annotations, not even my beloved @Configurable

[karldmoore]

It matters to me. The only reason I have been able to introduce Spring into certain consulting environments is because I do not introduce depedencies onto the Spring framework into my client's application code.

This means no annotations, not even my beloved @Configurable

I think I've already agreed with your point, I don't want external dependencies in my code either. We were specifically talking about what makes a POJO and my comments were in reference to that. As I said in the rest of the post, you have to apply common sense. You are going to have dependencies somewhere, I'd prefer them to be outside of the code. Just my opinion.

You are always going to have dependencies somewhere, I think it's just a question of where. Common sense says low coupling and I'll go with that. If you want to test your code you're going to follow that or alternatively #1 not bother testing because it's too hard or #2 fight with it to try and test it. As long as the code follows good principles, I'm not sure if this years buzzword is all that important. Although, I'm working hard to ensure my code is POJO compliant ® .

[debasishg]

I think I've already agreed with your point, I don't want external dependencies in my code either. We were specifically talking about what makes a POJO and my comments were in reference to that. As I said in the rest of the post, you have to apply common sense. You are going to have dependencies somewhere, I'd prefer them to be outside of the code. Just my opinion.

Regarding dependency on external code, I think we have multiple categories of dependency :

a) Most of our unit test codes can contain dependencies on mocking frameworks like EasyMock or JMock, which we do not mind
b) But we are reluctant to accept dependency on frameworks like Spring or Guice within our codebase

In what ways are mocking frameworks different from the DI frameworks ? Size ?

What do you all think ?

Cheers.
- Debasish

[Andreas Senft]

In what ways are mocking frameworks different from the DI frameworks ?

Usually you don't ship them. And usually you don't ship your test code, too (unless you developed a framework yourself). So dependencies do not hurt much there, IMHO.

Regards,
Andreas

[al0]

:::
Do not agree. It is through POJT one can immediately identify a good OOP design from a bad one. Because only through POJT one can practically appreciate why we need all those things called 'good' OOP practices - GOF patterns and design principles like 'code through interface not through implementation', 'loosely coupled - tightly cohesive', 'holliwood', 'talk only to immediate friends' etc.
...

There is only one small remark - most of these practices have existed long before OOP has emerged. They are just good design principles - regardless of object orientation. Yes, some of them are more usable and can be easier expressed in the OOP world - but they are anyway applicable to the procedural world. And, BTW, some of these practices were much more popular in pre-OOP era, then in the early OOP (e.g DI). Sometimes intoducing them in OOP (with new names) was just re-inventing the wheel.

Take a look on some old programming books, e.g. from 60s or 70s. You would be really surprised.

Regards,
Oleksandr

[karldmoore]

Usually you don't ship them. And usually you don't ship your test code, too (unless you developed a framework yourself). So dependencies do not hurt much there, IMHO.

I would agree with you on this one. I don't think it's a question of why are mocking frameworks and spring are different. I think it's simply a question of where the dependencies are. Dependencies in the code no, dependencies in the unit tests is a different matter.

[Arno Werr]

There is only one small remark - most of these practices have existed long before OOP has emerged. They are just good design principles - regardless of object orientation. Yes, some of them are more usable and can be easier expressed in the OOP world - but they are anyway applicable to the procedural world. And, BTW, some of these practices were much more popular in pre-OOP era, then in the early OOP (e.g DI). Sometimes intoducing them in OOP (with new names) was just re-inventing the wheel.

That might be. Unfortunately, my personal library does not extend beyond early 90s.
Yet according to one of the book in my repository

Although design patterns describe object-oriented designs, they are based on practical solutions that have been implemented in mainstream object-oriented programming languages like Smalltalk and C++
rather than procedural languages (Pascal, C, Ada) or more dynamic object-oriented languages (CLOS, Dylan, Self). We chose Smalltalk and C++ for pragmatic reasons: Our day-to-day experience has been in these languages, and they are increasingly popular.

This book is called
Elements of Reusable Object-Oriented Software
by Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides
Addison-Wesley Pub Co; 1st edition (January 15, 1995)
Introduction: What is Design Pattern

So, according to GOF claims their design pattern catalog is OOP rather than procedural languages phenomena.

[al0]

Yes, that's true. But good design practices are not limited to patterns. And I never have said that OOP has brought no progress - just many (but not all!) things that are now attributed to OOP has existed long before.

[debasishg]

I think it's simply a question of where the dependencies are. Dependencies in the code no, dependencies in the unit tests is a different matter.

Isn't one of the most important criteria of an object being a POJO is easy unit-testability of the class, without any dependence on external frameworks ?

Cheers.
- Debasish