Announcement Announcement Module
Collapse
No announcement yet.
Decision to use the Spring Framework Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    Well said, madtree.

    In fact, Spring IoC is a big factory. It does more than instantiation, it also provides configuration, decoration and assembly, as described by Interface21.

    Comment


    • #17
      Originally posted by madtree
      First of all, programming to interfaces is really important because it is how you can achieve polymorphism in a statically typed language, which is one of the main tenet of OO. If you don't use polymorphism, you might consider using a procedural language instead of Java.
      Isn't that exactly what I said in my previous post? If I am not writing decoupled code, java or other OO technologies would not be my choice to solve the problem.
      The problem when you program to interfaces, is how do you get the correct interface implementation without getting your code coupled to it. Not to mention the complexity involved in creating objects (initialization of his dependencies, state management, cache, ...).
      Thank you, exactly my point, you don't code to interface if you don't need the power of it. specially if you are coding to interfaces just because you can mock the classes for your JUnit test.
      This is usually where factories come in. In fact, factories are so important that acccording to the very popular "Domain Driven Design" book, they are an integral part of any domain model and any applications will have several of them (I know it used to be my case). The problem is that writting factories is most of the time a time consuming redudant and somehow complex task. This is where DI comes to help you.
      I am not sure why you would say writing factory is somewhat a complex task. And I would not call it redundant though. May be how you store/create objects for a factory to return sure can be subjective.
      DI allows you to code to interfaces at basically no cost. You just need to add a little snippet of xml and tada you get the implementation injected for you. No need to code anymore lot of ad hoc factories (or evil singletons) using proprietary config files. Plus you don't need to think about how to store the objects instances, to manage their states, ...
      I can and have see/n people misuse singleton. but give me one good reason to call it evil.

      The creation code which can be quite complex ends up totally separated from your core business logic. The DI container take care of those details for you. DI is in fact a very nice creational design pattern removing most of the need for custom factories and promoting a very neat separation of concerns (separating objet creation logic from business logic).
      Are you saying people do implement their business logic into their factories? Humm, I sure am missing something. Well lets see, If I use a ServiceLocator that basically looks up a service for me and returns "interface" to calling object(not to mention classes that creates appropriate object). I have few extra classes in my codebase. If I use DI i have a configuration file(not to mention third party lib that operates on config and classes). pretty close, both have atleast few extra files. java code V/S configuration and third party lib. now when DI container loads object configuration I would assume it drops hooks on classes to make sure when they are instentiated the setter injection must be called for one or more services. and if you use service locator when object is instentiated don't do anything untill you need service. Now how service locator creates object is a different story altogether. Well I think I'll allow my JVM to have more free heap space regardless of whether all of my methods would need one or more services or not.

      One thing I like to make clear, I am not out to bash spring framework so don't give me how spring is the best on the block, I already know that. I also know how clean my code looks with spring. I also know how it makes my code more unit testable. Not to mention other benefits of it.

      Comment


      • #18
        Thank you, exactly my point, you don't code to interface if you don't need the power of it. specially if you are coding to interfaces just because you can mock the classes for your JUnit test.
        The power of interface is not only in the modeling/design decoupling it allows, but in proxies you can create over them (yes, I know, you can create class proxies with cglib, but my experiences with that are not really that great). When you can have proxies you can do anything you want. You can use AOP stuff transparently - for example decide you want to cache a certain method, or turn on performance monitoring, or make it transactional, etc...

        Anyway... My experience says that it's very hard to say "I will never ever need to proxy this class for anything", so I prefer to be on a safe side and create an interface.

        Comment


        • #19
          Originally posted by dejanp
          The power of interface is not only in the modeling/design decoupling it allows, but in proxies you can create over them (yes, I know, you can create class proxies with cglib, but my experiences with that are not really that great). When you can have proxies you can do anything you want. You can use AOP stuff transparently - for example decide you want to cache a certain method, or turn on performance monitoring, or make it transactional, etc...
          Don't you think "power of interface" is a very significant term that covers broad useages of interfaces? Also I strongly feel that proxies are very useful for making RPC based calls. And no way in the hell I will be exposing my core business components as RPC based services. I wouldn't mind wrapping it in to a facade and deploy that as a service and return a proxy for it.

          Anyway... My experience says that it's very hard to say "I will never ever need to proxy this class for anything", so I prefer to be on a safe side and create an interface.
          Reflact on your experience and see how many times throughout your career have you created proxies over your business logic? Like XP says DO not design too much upfront. Even if need arise I have no problem putting a big facade over my existing system.
          Last edited by tatvamasi; Sep 13th, 2006, 11:44 AM.

          Comment


          • #20
            Originally posted by tatvamasi
            Isn't that exactly what I said in my previous post? If I am not writing decoupled code, java or other OO technologies would not be my choice to solve the problem.

            Thank you, exactly my point, you don't code to interface if you don't need the power of it. specially if you are coding to interfaces just because you can mock the classes for your JUnit test.
            I am not sure why you would say writing factory is somewhat a complex task. And I would not call it redundant though. May be how you store/create objects for a factory to return sure can be subjective.
            Writting a factory can be complex when you have to :
            1) create objects necessiting complex creation logic.
            2) needs to somehow cache the created objects.
            3) manage objects states (although if we are speaking conceptually and not technically those are not factories but repositories)

            Originally posted by tatvamasi
            I can and have see/n people misuse singleton. but give me one good reason to call it evil.
            They are a disguised global variable, an anti OO concept. They promote tight coupling between classes and your dependencies end up hidden all over your code. A small change in the singleton can have a tremendous impact and they are quite hard to test.

            Having to create a global variable instead of passing around the object as a parameter is a big smell in your design. There are always better way to achieve the same result (parameters, introducing a factory, ...).



            Are you saying people do implement their business logic into their factories? Humm, I sure am missing something. Well lets see, If I use a ServiceLocator that basically looks up a service for me and returns "interface" to calling object(not to mention classes that creates appropriate object).
            No I'm saying people often put creation logic into their business objects, especially when they are using service locators. I don't like the name "service locator", it infers that a factory is just a way of retrieving some objects. But in reality a factory has a lot more responsabilities and can be quite a complex beast. Saying they are only retrieving a service is an oversimplification in my opinion.

            It's true you can use custom factories instead of DI and still be able to achieve the same results. But it requires you to write a lot of infrastructural code while you can get it for free when using DI. Not to mention that a mature DI container is specialized in this kind of task and has been thoroughly tested and optimized.

            Another advantage is that DI is a push model so you don't need to scatter your code with calls to a factory. The code become much more clearer.

            Comment


            • #21
              I think the original intent of Ben's post was that Spring has some awesome features that warrant the hype. I think it was the swapping of strategy interface implementations in a production application that he was referring to when he said he didn't see the value (simply because he doesn't believe this happens or does not happen often enough to warrant the hype this side-effect of using Spring's DI support provides).

              And yes, I realize that there are other advantages to using DI, such as ease in unit testing, cleaner code, etc.

              Sorry to put words in your mouth Ben.

              -Arthur Loder

              Comment


              • #22
                Originally posted by madtree
                Writting a factory can be complex when you have to :
                1) create objects necessiting complex creation logic.
                2) needs to somehow cache the created objects.
                3) manage objects states (although if we are speaking conceptually and not technically those are not factories but repositories)
                Misuse of Factory would get you to #1. Creating V/S Assembling.... big difference...
                They are a disguised global variable, an anti OO concept. They promote tight coupling between classes and your dependencies end up hidden all over your code. A small change in the singleton can have a tremendous impact and they are quite hard to test.

                Having to create a global variable instead of passing around the object as a parameter is a big smell in your design. There are always better way to achieve the same result (parameters, introducing a factory, ...).
                They are not a disguised global variable as long as you use it for right purpose Singletons aren't designed for change. It is a creational pattern and not behavioral one. how you create your objects doesn't change often if not at all. If you use singletons for behavior............. Singletons are anti patterns because people use it as a place holder to save a trip to database.
                No I'm saying people often put creation logic into their business objects, especially when they are using service locators. I don't like the name "service locator", it infers that a factory is just a way of retrieving some objects. But in reality a factory has a lot more responsabilities and can be quite a complex beast. Saying they are only retrieving a service is an oversimplification in my opinion.

                It's true you can use custom factories instead of DI and still be able to achieve the same results. But it requires you to write a lot of infrastructural code while you can get it for free when using DI. Not to mention that a mature DI container is specialized in this kind of task and has been thoroughly tested and optimized.
                I will say Factory is not a service locator. One is implemented as singleton another is a static class. one retrieves services another creates instances. FACTORIES ARE NOT SERVICE LOCATORS. Locating a service V/S creating an instance are two different things. Factories do not have lot more responsibilities. It has only one responsibility to create a proper instance of a class for given scenario. even underlying structural pattern wouldn't have complex logic given right structural pattern was used.
                Another advantage is that DI is a push model so you don't need to scatter your code with calls to a factory. The code become much more clearer.
                Interestingly, Why would I push something in my object assembly which I may or may not require for the task being executed?

                Comment


                • #23
                  Originally posted by tatvamasi
                  Misuse of Factory would get you to #1. Creating V/S Assembling.... big difference...
                  Really? According to the dictionnary, assembly is "the act of constructing something (as a piece of machinery)". And what you do in a constructor usually? Assigning values right? Sound like assembling to me.

                  Also an object must enforce some invariants on its relationships at any moment or it'll end up in a incoherent state. So an object can't be considered constructed until it gets assembled correctly unless you don't care about invariants which is against OOP.

                  I'm not saying a factory is mandatory for each object. A simple constructor may be enough in a lot of cases but in some other cases where the creation logic is complex, it's better to delegate the work to a factory method or to a complete individual factory. If you program following the TDD approach, those cases are quite easy to spot and introducing a factory through refactoring is kind of easy.

                  Originally posted by tatvamasi
                  They are not a disguised global variable as long as you use it for right purpose Singletons aren't designed for change.
                  I believe OOP true strength are clarity and allowing you to introduce changes easily through refactoring. Now have you ever tried to refactor and test some code using singletons? It is very hard to achieve because any code can get access to a singleton and you can't override a static method. In fact, a simple change can have a disatrous impact on your code base.

                  Originally posted by tatvamasi
                  It is a creational pattern and not behavioral one. how you create your objects doesn't change often if not at all. If you use singletons for behavior............. Singletons are anti patterns because people use it as a place holder to save a trip to database.
                  If an object doesn't have behavior then it isn't a real object but a mere data holder. Hence, you are using a disguised procedural construct in a OO programming languague (with all disadvantages coming with it, see my comment above).

                  Creation behavior doesn't change often? I don't agree with that. Have you ever ported an existing application in a clustered environment? Face multi-threading problems? Good luck with those singletons. Of course, you won't face those problems if your objects are stateless but than again if a lot of your objects are stateless, you might use a procedural language as well.

                  Originally posted by tatvamasi
                  I will say Factory is not a service locator. One is implemented as singleton another is a static class. one retrieves services another creates instances. FACTORIES ARE NOT SERVICE LOCATORS. Locating a service V/S creating an instance are two different things. Factories do not have lot more responsibilities. It has only one responsibility to create a proper instance of a class for given scenario. even underlying structural pattern wouldn't have complex logic given right structural pattern was used.
                  First, a factory or a service locator can be implemented technically the same way if you want so they aren't different in this point of view. A pattern can't be translated directly in code and can be implemented using a variety of different strategy.

                  However, I agree with you they are different conceptually. But you should usually wrap your service locator in a factory (or whatever creational pattern you choose to use) because a service locator is a technical mean to locate a service. When you use it directly, you expose infrastructure details to your domain model whereas a factory is an abstraction defined in terms of the domain model. Hence this is why I was saying service locators were a poor version of a factory.

                  Originally posted by tatvamasi
                  Interestingly, Why would I push something in my object assembly which I may or may not require for the task being executed?
                  You can inject as many different instances of a class as you want so I don't see your point. You select what you want to be injected. If your code is higly conditionnal than a good old factory might be a better idea than using DI in this case.

                  Comment


                  • #24
                    Originally posted by tatvamasi
                    One thing I like to make clear, I am not out to bash spring framework so don't give me how spring is the best on the block, I already know that. I also know how clean my code looks with spring. I also know how it makes my code more unit testable. Not to mention other benefits of it.
                    Someone just wants to argue, and does not allow others to mention any benefits of Spring?

                    Following this thread seems a waste of time now...

                    Comment


                    • #25
                      Originally posted by tatvamasi
                      Reflact on your experience and see how many times throughout your career have you created proxies over your business logic? Like XP says DO not design too much upfront. Even if need arise I have no problem putting a big facade over my existing system.
                      I don't think I can count how many times I used proxies over my business interfaces. It's the business interface proxies that I use to define transactions, monitor performance, that need additional security aspects, transparent caching, jmx control/monitoring etc.

                      Spring makes the whole interface/implementation decoupling so easy that I'm not even considering it to be some kind of a overhead. It's a couple of minutes more work per class that will, sooner or later, allow me so much flexibility, in development, testing and production, that it's bound to pay off.

                      Comment


                      • #26
                        Originally posted by madtree
                        Really? According to the dictionnary, assembly is "the act of constructing something (as a piece of machinery)". And what you do in a constructor usually? Assigning values right? Sound like assembling to me.
                        Creating different objects are creation of them where putting them together and make "something" out of them is assembling. In terms of patterns creational V/S Structural.
                        Also an object must enforce some invariants on its relationships at any moment or it'll end up in a incoherent state. So an object can't be considered constructed until it gets assembled correctly unless you don't care about invariants which is against OOP.
                        Again mix of Creational V/S Structural
                        I'm not saying a factory is mandatory for each object. A simple constructor may be enough in a lot of cases but in some other cases where the creation logic is complex, it's better to delegate the work to a factory method or to a complete individual factory. If you program following the TDD approach, those cases are quite easy to spot and introducing a factory through refactoring is kind of easy.
                        No, where you have one or more variants of a class thats where you will use factory effectively and not where creation logic gets complex.

                        I believe OOP true strength are clarity and allowing you to introduce changes easily through refactoring. Now have you ever tried to refactor and test some code using singletons? It is very hard to achieve because any code can get access to a singleton and you can't override a static method. In fact, a simple change can have a disatrous impact on your code base.



                        If an object doesn't have behavior then it isn't a real object but a mere data holder. Hence, you are using a disguised procedural construct in a OO programming languague (with all disadvantages coming with it, see my comment above).
                        I would have said business behavior. anyways what said is said. However I would again say if you use it for wrong purpose Shit happens. Factories are created singletons but not any structural or behavioral why? There is a reason for that.
                        Creation behavior doesn't change often? I don't agree with that. Have you ever ported an existing application in a clustered environment? Face multi-threading problems? Good luck with those singletons. Of course, you won't face those problems if your objects are stateless but than again if a lot of your objects are stateless, you might use a procedural language as well.
                        No I have not ported an application in a clustered env. Never saw need for it.
                        First, a factory or a service locator can be implemented technically the same way if you want so they aren't different in this point of view. A pattern can't be translated directly in code and can be implemented using a variety of different strategy.
                        Not really, Factory solely looks up given class from a class loader and create an instance of it. Service Locator locates an existing instance.
                        However, I agree with you they are different conceptually. But you should usually wrap your service locator in a factory (or whatever creational pattern you choose to use) because a service locator is a technical mean to locate a service. When you use it directly, you expose infrastructure details to your domain model whereas a factory is an abstraction defined in terms of the domain model. Hence this is why I was saying service locators were a poor version of a factory.
                        Not sure if i would wrap my locator in a factory, its more of a utility and should be a static class. Factories are created singletons as they require somekind of initialization before hand.
                        You can inject as many different instances of a class as you want so I don't see your point. You select what you want to be injected. If your code is higly conditionnal than a good old factory might be a better idea than using DI in this case.
                        Thats not what i meant what meant was if I am executing a method on an object which may or may not require defined injection (defined because some of the methods requires it) to complete the task. Don't you think I should think "go get it when I need it" and not "have it available so when needed its there"

                        Comment


                        • #27
                          Originally posted by seabludude
                          Someone just wants to argue, and does not allow others to mention any benefits of Spring?

                          Following this thread seems a waste of time now...
                          your choice.
                          Last edited by tatvamasi; Sep 14th, 2006, 08:20 AM.

                          Comment


                          • #28
                            Originally posted by dejanp
                            I don't think I can count how many times I used proxies over my business interfaces. It's the business interface proxies that I use to define transactions, monitor performance, that need additional security aspects, transparent caching, jmx control/monitoring etc.

                            Spring makes the whole interface/implementation decoupling so easy that I'm not even considering it to be some kind of a overhead. It's a couple of minutes more work per class that will, sooner or later, allow me so much flexibility, in development, testing and production, that it's bound to pay off.
                            Good for you. So you did have a need for coding to interface. you needed the power of interface. You did not code to interface just because........ Where is the disagreement.

                            Comment


                            • #29
                              Originally posted by tatvamasi
                              Why would I push something in my object assembly which I may or may not require for the task being executed?
                              This is the essential beef I have with file-base DI/IoC. It's the "may or may not" i.e. the conditional logic that I can write in java that I cannot write in the file. I had the same problem with Struts:

                              The "flexibility" gained for aspects which have a low probability of changing over the life of the app, bearing in mind that companies usually "throw out the baby (Spring) with the bathwater (the so-called "legacy" app)" ...this flexibility is not worth the price paid in (a) loss of protection of the compiler, and (b) the "flexibility" (spelled conditional logic) that I can write into the code. I'm thinking people are buying into the file-based DOI because it's "sexy" and "fun", whereas writing conditional logic POJOs is relatively boring? "Been there; done that; got that t-shirt" as Jimmy Buffett says.

                              Again, I'm keeping an open mind on the file-based DI. If someone can point me to a clear, solid payoff, from a Spring novice point of view, i.e. without further confusing the issue with deep, unexplained Spring techno-babble...I'm all ears.


                              Originally posted by Arthur Loder
                              I think the original intent of Ben's post was that Spring has some awesome features that warrant the hype. I think it was the swapping of strategy interface implementations in a production application that he was referring to when he said he didn't see the value (simply because he doesn't believe this happens or does not happen often enough to warrant the hype this side-effect of using Spring's DI support provides).

                              And yes, I realize that there are other advantages to using DI, such as ease in unit testing, cleaner code, etc.

                              Sorry to put words in your mouth Ben.

                              -Arthur Loder
                              Not a problem. That is essentially what I meant.

                              I hope this thread does not start to "go negative". Reading over your various posts, you all seem like smart, experienced designer/developers, whose design and coding philosophies, like mine, have been shaped by long years in this industry, which can be rather ruthless and unforgiving. Your philosophies seem vastly different from one another at times. One of the nice features of Spring is that it is not an "all-or-nothing" framework. You can usually take on just the parts that happen to fit with your philosophy, i.e. the parts that make sense to YOU.

                              In addition, one of the great values I see in Spring is in the support I get from the Spring team. Over the years, I remember working with support teams at DEC, HP, IBM, Sun, Microsoft and Oracle. Even though we were PAYING for support, and I mean big bucks sometimes, on the more difficult problems, it often took me 2-3 iterations of support calls, just to get to a person who actually knew what the f* they were talking about. Maybe it won't last forever, but with Spring, I'm working DIRECTLY with the people who designed and wrote the stuff! This is amazing! Argueably, the hottest technology in the java world today, and the CEO of the company backing the software is answering my questions!

                              I truly hope Interface21 is making money with this somehow, and that they can continue making money with this business model, and that other framework and API vendors can make money off this same business model. It gives me hope for the future of software development.

                              After all, the "bottom line" is the bottom line on the financial statement of the company for whom you work. Whatever your design/coding philosophy, if the software you design and write does not, at some point, make more money than it costs to produce, then you should be out the door. That is only fair in the world of business.

                              Ben

                              Comment


                              • #30
                                Originally posted by tatvamasi
                                Good for you. So you did have a need for coding to interface. you needed the power of interface. You did not code to interface just because........ Where is the disagreement.
                                Actually what I tried to say is exactly the opposite. I don't always know if I will need the interface or not, but the cost of it is practically zero, so the question is why not?

                                Comment

                                Working...
                                X