Announcement Announcement Module
Collapse
No announcement yet.
Is Annotated POJO a POJO ? Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    Originally posted by debasishg View Post
    For (b), we do not actually solve the problem, since we still need Spring for unit testing (Spring needs to process the XML and build up the factory).
    As far as unit testing goes, that's a much "softer" need , as in we don't "have to" have Spring in order to make it work. On the other hand, see below.

    Originally posted by debasishg View Post
    And finally, isn't XML also part of my codebase ? True they are externalized, but still we need to process them using Spring.
    That's a good question. My answer is yes. I know the Spring folks have been trying to avoid "programming in XML", but as complex as Spring contexts can get today, any serious application would have a fair amount of logic in there.

    Comment


    • #17
      Originally posted by manifoldronin View Post
      As far as unit testing goes, that's a much "softer" need , as in we don't "have to" have Spring in order to make it work. On the other hand, see below.
      I truly agree. Spring was just an example, may not be the absolute right one. But for Guice u need to have the framework dependency for unit testing as well. I know discussions are there in the Guice mailing list about a minimalistic guice-minimal.jar (containing the bare essentials) that people can include with unit testing instead of the whole one.



      Originally posted by manifoldronin View Post
      That's a good question. My answer is yes. I know the Spring folks have been trying to avoid "programming in XML", but as complex as Spring contexts can get today, any serious application would have a fair amount of logic in there.
      +1 again ..

      Cheers.
      - Debasish

      Comment


      • #18
        I think there have been some really good points raised here! 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?

        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 .
        Last edited by karldmoore; Aug 29th, 2007, 12:37 PM.

        Comment


        • #19
          For me the ONLY real value of OOP is an opportunity for robustness of an application, i.e. no bugs. This opportunity is realized through automated testing using POJT (Plain Old Java Testing - jUnit). If annotation does not impede with POJT then this annotation is POJO friendly. Otherwise, it pollutes POJO environment and should be avoided.

          Comment


          • #20
            Originally posted by Arno Werr View Post
            For me the ONLY real value of OOP is an opportunity for robustness of an application, i.e. no bugs. This opportunity is realized through automated testing using POJT (Plain Old Java Testing - jUnit). If annotation does not impede with POJT then this annotation is POJO friendly. Otherwise, it pollutes POJO environment and should be avoided.

            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.

            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).

            Regards,
            Oleksandr

            Comment


            • #21
              Originally posted by al0 View Post
              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.

              Originally posted by al0 View Post
              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'.

              Originally posted by al0 View Post
              there are similar systems for completely procedural environments.
              And how it's called - 'a bunch of code-monkeys'?

              Cheers,
              Arno

              Comment


              • #22
                Originally posted by karldmoore View Post
                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

                Comment


                • #23
                  Originally posted by cepage View Post
                  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.

                  Originally posted by karldmoore View Post
                  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 .
                  Last edited by karldmoore; Aug 29th, 2007, 12:36 PM.

                  Comment


                  • #24
                    Originally posted by karldmoore View Post
                    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

                    Comment


                    • #25
                      Originally posted by debasishg View Post
                      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

                      Comment


                      • #26
                        Originally posted by Arno Werr View Post
                        :::
                        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

                        Comment


                        • #27
                          Originally posted by Andreas Senft View Post
                          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.
                          Last edited by karldmoore; Aug 29th, 2007, 12:36 PM.

                          Comment


                          • #28
                            Originally posted by al0 View Post
                            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.

                            Comment


                            • #29
                              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.

                              Comment


                              • #30
                                Originally posted by karldmoore View Post
                                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

                                Comment

                                Working...
                                X