Announcement Announcement Module
Collapse
No announcement yet.
Spring != OO support ... Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Spring != OO support ...

    I don't think anyone will question the brilliance of Spring and how useful it is, however, a lot of what it does promotes a non-Object Oriented approach to software development, which can't be good.

    My question is, doesnt this worry you or have I missed something and have the wrong opinion about Spring?

    How can you support Object Oriented principles and still use Spring ?

    Rgs, James.

  • #2
    Inversion of Control/Dependency Injection is a key OO design concept and pretty much the core of Spring. So I'm not sure where the "non-OO'ness" approache came from.

    You would probably get more relevant and concrete reponses by listing the things that Spring does and you think "promotes a non-Object Oriented approach."

    Comment


    • #3
      manifoldronin, thanks for the reply.

      Id be interested in any links you could provide that detail the Principles of Object Orientation and include a mention of dependency inject or inversion of control. There is dependency inversion but im not sure its the same thing especially when you have to break other principles to do it.

      http://ootips.org/ood-principles.html

      I do agree that having a few examples of how Spring breaks OO would be helpful in this discussion so here you go:

      1. A principle of OO is encapsulation / data hiding and not exposing the implementation details of a Class. However, Spring needs public access to this information in order to do its 'thing'.

      2. The Dependency Inversion Principle: "Depemd Upon abstractions. Do not depend upon concretions. Which is also broken by Spring as again it requires concrete implementations and doesnt work through abstractfactories.

      3. Not an OO principle but a Joshua Block one:- How do you use spring and ensure a class is immutable ?

      Maybe there are ways around these and the other principles broken by Spring but im not aware of them.

      Again, I think Spring is great but Im wondering where it fits amidst the other things I need from my software like maintainability in the face of change.

      Rgs, James.
      Last edited by jladd; Apr 8th, 2006, 01:54 AM.

      Comment


      • #4
        Originally posted by jladd
        Id be interested in any links you could provide that detail the Principles of Object Orientation and include a mention of dependency inject or inversion of control. There is dependency inversion but im not sure its the same thing especially when you have to break other principles to do it.
        Dependency injection, IoC and Depenency inversion are all variations of the same concept; classes are *given* their dependencies, they don't find them themselves.

        Originally posted by jladd
        1. A principle of OO is encapsulation / data hiding and not exposing the implementation details of a Class. However, Spring needs public access to this information in order to do its 'thing'.
        Not true Classes can be wired up using constructor arguments just as easily as parameters:

        Code:
        <bean id="myBean" class="...."
          <constructor-arg>
            <bean class="some.collaborator.impl"/>
          </constructor-arg>
          <constructor-arg ref="someOtherCollaborator"/>
        </bean>
        Originally posted by jladd
        2. The Dependency Inversion Principle: "Depemd Upon abstractions. Do not depend upon concretions. Which is also broken by Spring as again it requires concrete implementations and doesnt work through abstractfactories.
        Not true again If I have a class which requires a collaborator to work then the class would expect the interface. Of course at run time it must be provided with an implementation, but it only expects the interface:

        Code:
        public interface MyDAO {
          void doSomething();
        }
        
        public class MyDAOImpl implements MyDAO {
          public final void doSomething() {
            ...
          }
        }
        
        public class MyClass {
          private final MyDAO dao;
          public MyClass(final MyDAO myDAO) {
            this.dao = myDAO;
          }
        
          void doMyMethod() {
            myDAO.doSomething();
          }
        }
        and

        Code:
          <bean id="myDAO" class="MyDAOImpl"/>
          <bean id=myClass" class="myClass">
            <constructor-arg ref="myDAO"/>
          </bean>
        Note; no setters

        Originally posted by jladd
        3. Not an OO principle but a Joshua Block one:- How do you use spring and ensure a class is immutable ?
        See the above.

        Originally posted by jladd
        Maybe there are ways around these and the other principles broken by Spring but im not aware of them.
        I still don't see which principles Spring breaks. To my mind, Spring actively encourages good practices

        It is true that most of Spring utility classes prefer setters, but that is an old convention, and isn't enforced. I simply workaround it by passing all required collaborators via constructor and calling setters on the utility class.

        HTH.

        Comment


        • #5
          Thanks ...

          yatesco,

          Thanks for the detailed reply.

          "It is true that most of Spring utility classes prefer setters, but that is an old convention, and isn't enforced. I simply workaround it by passing all required collaborators via constructor and calling setters on the utility class."

          I had intended to come back and edit my post to be more specific about Spring in that whilst it doesnt madate non-oo principles be used it also doesnt ensure they are not used. ie: You work around them.

          Im a lot happier now that your post clears a lot up.

          Thanks.

          Rgs, James.

          Comment


          • #6
            There are a lot of other forum posts to do with benefits of Spring, but I cannot remember where they are

            One than I can find of the top of my head:

            http://forum.springframework.org/sho...pring+benefits

            Try searching for "spring benefits" and have a perusal of the results

            Comment


            • #7
              visibility ...

              yatesco,

              Thanks again for the reply.

              Another thing I am curious about is the required visibility of classes.
              If my concrete implementation classes are package scope,
              can Spring see them or do they all have to be public ?

              Personally I like to have all classes and methods with as little scopy/visibility
              as possible.

              Rgs, James

              Comment


              • #8
                Originally posted by jladd
                Another thing I am curious about is the required visibility of classes.
                If my concrete implementation classes are package scope,
                can Spring see them or do they all have to be public ?
                If your classes implement an interface (which they should) then by definition the implemented methods must be public

                Comment


                • #9
                  I think you are making some strong statements in this thread without backing them up. I have been coding in object oriented languages for a decade now and have been working with java for many years. I just recently started working with spring and I can only say that it has helped my programming style become more object oriented and structured. The whole idea of Ioc really enforces the idea of writing loosely coupled code and encourages design by interface first. In my mind this is the basis of good OO programming.
                  Last edited by wexwarez; Apr 8th, 2006, 05:23 PM.

                  Comment


                  • #10
                    strong statements ...

                    All,

                    Yes I did make some strong statements and that was intentional.
                    Mostly so that I could get strong answers and I have.

                    My first venture into spring wasnt by choice and the examples that were used and approach that was promoted required get/set for everything which made me cringe. yatesco - Pointed out that you could use constructors and I knew this and I was hoping that in the later versions of spring or somewhere in the doco there was something that said the constructor approach was preferred over get/set. I dont like get/set because it exposes the implementation of an object and doesnt help in keeping objects immutable.

                    yatesco whose replies I appreciate says that I should be using interfaces and I do and that the methods of the interface will be public and yes they are, as they can't be any other way.

                    My question is, does the class that implements the interface have to be public as well ? Id prefer to have its scope package only so they can not be created outside the package except by a 'factory'. Otherwise people might construct them themselves directly.

                    Please dont get me wrong, I think Spring is a great framework and its come a long way and has a lot of takeup. Maybe my question should be "is there a set of best practice guidelines for using spring ?" ie: spring 'can' be used in a very OO way, but what does it do to 'enforce' this ?

                    Thanks again for the replies.

                    Rgs, James.
                    Last edited by jladd; Apr 8th, 2006, 06:40 PM.

                    Comment


                    • #11
                      Originally posted by jladd
                      My first venture into spring wasnt by choice and the examples that were used and approach that was promoted required get/set for everything which made me cringe.
                      I actually agree with you there. I think it's mostly because it's a lot easier and less error-prone with the get/set approach than with constructors, in which case you have to worry about matching the parameters either to the exact types or the exact indices. And most of the time people working on those examples just want to get to the fun "look at this cool thing Spring can do" part, and don't usually give serious thoughts to whether a particular getter/setter makes sense were the object being designed to be a serious domain object.

                      Originally posted by jladd
                      yatesco - Pointed out that you could use constructors and I knew this and I was hoping that in the later versions of spring or somewhere in the doco there was something that said the constructor approach was preferred over get/set. I dont like get/set because it exposes the implementation of an object and doesnt help in keeping objects immutable.
                      Agreed again. I too think excessive use of getters/setters is a prevailing problem. On the other hand, though, I don't think it's Spring's responsibility to tell people which approach is the "best" practice. As matter of fact, if I were to pick one single thing I like the most about Spring, it would be that it always tries to be as non-prescriptive as possible. Comparing to the all-your-base-are-belong-to-us EJB paradigm, Spring promotes best practices, but does not dictate your design in particular.

                      Originally posted by jladd
                      My question is, does the class that implements the interface have to be public as well ? Id prefer to have its scope package only so they can not be created outside the package except by a 'factory'. Otherwise people might construct them themselves directly.
                      AFAIK, no, an implementation class does not have to be public.
                      Last edited by manifoldronin; Apr 8th, 2006, 10:42 PM.

                      Comment


                      • #12
                        Thanks ...

                        Jing Xue,

                        Thanks for you reply and not just because we have agreement on some items.
                        Im keen to work with spring again and some of the Spring-MVC stuff is going to help a lot.

                        Personally I would like some "best-practice" doco but this doesnt have to make it into the product itself.

                        Now Ill put the advice to the test and see how Spring fits in with a strick OO approach and report back. Im sure the report will be glowing.

                        Rgs, James.

                        Comment


                        • #13
                          When I first starting playing with Spring MVC in 2004, I started with the sample applications and found them to be horrible designs filled with accessors. However, I believe the point of the sample applications aren’t to show proper design but to show the simplicity of mapping from Hibernate to the web.

                          In terms of using Spring to wire my service layer, I only use constructor-based initialisation. I believe the InitializingBean interface is a kluge to the setter-based initialisation as it can have the same problems as using the setters in the first place… did I call that method to set XXX? did I add that validation for XXX to the afterPropertiesSet method? I don't believe that you need to ask an object if its valid.

                          I use Holub’s Builder pattern by adding exporter and importer methods to my domain objects which read/write to an interface the domain layer knows about. The advantages are outlined in Holub’s articles and his book (look for ‘Getters are Evil’) so I won’t reiterate them here. The only difference that I make is that my importer is public instead of protected as shown in Holub’s examples. The advantage of the importer is that it’s a single point of entry to update the domain object. This allows me to validate and ensure that private attributes are set in a specific order without having to use an external Validator or call a validate method on the domain object (see my reasons above regarding the InitializingBean interface).

                          Since the importer uses an interface for publishing data, the service layer also uses the interface. This frees the client layer to implement this in any fashion (DTOs, Swing Documents, etc).

                          Finally for the Spring MVC presentation layer, I use DTOs which implement the domain object’s exporter/importer interfaces. The Spring controllers map to these DTOs and commands are sent to the service layer. Since the DTOs are in their own package (as is the rest of the webapp part of the application) they are free to have whatever presentation attributes that are necessary to fulfill the usecase.

                          Micheal

                          Comment


                          • #14
                            Wow ...

                            Micheal,

                            Wow, thanks for the great response.
                            Would it be possible to see an example either privately or publicly ?

                            I am a big fan of Holub and I use the builder pattern too.

                            I look forward to your response.

                            Rgs, James.

                            Comment


                            • #15
                              There are a lot of smart people who get concerned about the mutators, and I'd love to have a better understanding why.

                              With good OO design, you should be accessing classes through their interfaces, and not through their concrete implementations, and Spring does a great job of helping you to implement your applications this way.

                              For injected dependencies, I don't put mutators in the public interface. Period. Yes, there is a public setter method, but if your code is accessing the bean through its interface, then for all practical purposes it is private.

                              Sure, Spring doesn't 'enforce' private access to the mutator, but the only way you could get to it is by directly invoking the class's concrete constructor (or casting to a concrete class), and that's a no-no.

                              If you can't get your team to reference classes through injected interfaces, rather than invoking concrete constructors, then you aren't going to be able to 'enforce' OO principles anyway, and Spring can't do anything about that.

                              Comment

                              Working...
                              X