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

  • #31
    Originally posted by benethridge
    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.
    Yup, I think this is the main reason spring is leading market. As far as interface21 and making money goes, I would say When Rod or Martin speaks, it becomes a word of god. I am sure Interface21 is going to be or may be it already is another Thoughtworks.

    Comment


    • #32
      Originally posted by benethridge
      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 think you are trying to use DI in a place where it isn't meant to be used. If the field value depend of the context, just give it a default value at first and let the code change it at will. DI doesn't mean you shouldn't create objects dynamically and it is a very bad idea to try to fit it in those cases. You'll end up with horrible long xml files. You should use DI to initialize an object in a coherent state and that's it. It doesn't mean you shouldn't use the new operator anymore to instantiate dynamic values (imagine getting string values from the app context, ouch).

      Comment


      • #33
        Originally posted by tatvamasi
        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.
        Creational patterns are solutions to creational problems which include assembly (just look at the builder pattern in the GoF book...) and structural are solution to a structural problem, ie compile time problems in a static typed language as Java.


        Originally posted by tatvamasi
        Originally posted by madtree
        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
        How an object not respecting its invariants is a missmatch of patterns? We are talking about the theory of contract which has nothing to do with patterns and is a basic of OOP. An object shouldn't be available until it is in a coherent state.

        Originally posted by tatvamasi
        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.
        Read GoF book section on factory and they clearly state a factory (or builder for that matter) should be used when creation logic is complex

        Originally posted by tatvamasi
        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.
        Could you be more precise? Anyway, a factory doesn't have to be a singleton, again read GoF book and you'll see there are many different ways of implementing it. Java SDK is full of factories not implemented as Singleton.


        Originally posted by tatvamasi
        No I have not ported an application in a clustered env. Never saw need for it.
        Not really, Factory solely looks up given class from a class loader and create an instance of it. Service Locator locates an existing instance.
        And what is a service locator doing in the end? Creating a java object so technically they can be implemented the same way but it's true, they are different pattern because they aren't meant to the same usage.

        Originally posted by tatvamasi
        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.
        Again this is an implementation choice.


        Originally posted by tatvamasi
        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"
        Is the object in a coherent state without the dependency injected? I mean is this object a true collaborator? Does your object invariant include some constraint on the presence of this object? If you are talking about a local or dynamic object meant to be used only by that method than you shouldn't be using DI for those case. The new operator is perfectly fine for creating those objects. For instance, do you retrieve String from Spring application context?
        Last edited by madtree; Sep 14th, 2006, 11:43 AM.

        Comment


        • #34
          Originally posted by madtree
          Creational patterns are solutions to creational problems which include assembly (just look at the builder pattern in the GoF book...) and structural are solution to a structural problem, ie compile time problems.
          No. assembly of structure is not part of creation. so let me get this straight, If I have a situation where I am using flyweight I don't have to use creational along with it? like a factory or something? No I must use factory or something to create 'em.

          Read GoF book section on factory and they clearly state a factory (or builder for that matter) should be used when creation logic is complex
          Yes and what that tells me is when you have to go through use of instaceof 15 times, do a factory instead. And when you need a state along with it implement flyweight along with it. And if you don't need state but do need a new instance each time you call it implement prototype with it. And if each of them walk but "walk" differently implement command with it.

          Could you be more precise? Anyway, a factory doesn't have to be a singleton, again read GoF book and you'll see there are many different ways of implementing it. Java SDK is full of factories not implemented as Singleton.
          sure it doesn't have to be singleton but whats the point doing a file IO and tons of reflaction calls on each call to that factory.

          And what is a service locator doing in the end? Creating a java object so technically they can be implemented the same way but it's true, they are different pattern because they aren't meant to be the same usage.
          Not really, Service locators are more helpful if used for your contextual objects (services, J2EE resources). which are already created and made available for you. They are there just retrive 'em. Yes if you are talking interms of EJB sure there are people who would lookup a bean from context and create a remote interface right there. and return remote interface. And yes in that case Service Locator is creating.

          Again this is an implementation choice.
          If no initialization required for a factory than why use factory in the first place? Or what is the point of initialization in construction of an object.

          Is the object in a coherent state without the dependency injected? I mean is this object a true collaborator? Does your object invariant include some constraint on the presence of this object? If you are talking about a local or dynamic object meant to be used only by that method than you shouldn't be using DI for those case. The new operator is perfectly fine for creating those objects. For instance, do you retrieve String from Spring application context?
          Hummmmm, so if Class A has 10 methods and 2 of them requires ADAO to do somework and other 2 require BDAO to do some work and so on, Do you think it seem feasible to have 5 DAOs(which is just a component BTW) injected when an object is being created? Now DAO does depend on a service "datasource" may be! in that case I do take argument to inject datasource into it. Although my preference would be to use service locator to locate datasource.

          Well enough of me being looney. I rest. ha ha

          Comment


          • #35
            Originally posted by madtree
            I think you are trying to use DI in a place where it isn't meant to be used. If the field value depend of the context, just give it a default value at first and let the code change it at will. DI doesn't mean you shouldn't create objects dynamically and it is a very bad idea to try to fit it in those cases. You'll end up with horrible long xml files. You should use DI to initialize an object in a coherent state and that's it. It doesn't mean you shouldn't use the new operator anymore to instantiate dynamic values (imagine getting string values from the app context, ouch).
            Ah! i missed this post of yours, so I said nothing wrong when I said people started using DI as instatiation framework.

            Comment


            • #36
              Originally posted by dejanp
              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?
              Not for this reason because every single method in your class has to be in your interface in order to create a proxy over them. imagine two different classes implementing same interface. Both class must implement methods for each other. so even though class B has nothing to do with calculate() method it must implemented in B because you want method implementation of A available for your proxy and your interface is forcing it.

              Comment


              • #37
                I'm done arguing on patterns because this debate wasn't about it at first anyway and well I totally disagree about what you say*.

                Originally posted by tatvamasi
                Hummmmm, so if Class A has 10 methods and 2 of them requires ADAO to do somework and other 2 require BDAO to do some work and so on, Do you think it seem feasible to have 5 DAOs(which is just a component BTW) injected when an object is being created? Now DAO does depend on a service "datasource" may be! in that case I do take argument to inject datasource into it. Although my preference would be to use service locator to locate datasource.
                I would say your design sucks and this object has way too many responsabilities and you should split it so it doesn't depend on so many DAO*s or think about regrouping some DAOs together.

                If the datasource can change, well this requirement should be handled in the DAO or another helper object. Simple as that, DI isn't the problem, your design is.

                I am going to say it again : an object must never allow to be in a incoherent state once it has been created. It must always respect its invariant. Otherwise, you're in for a lot of problems.

                Comment


                • #38
                  Originally posted by tatvamasi
                  Not for this reason because every single method in your class has to be in your interface in order to create a proxy over them. imagine two different classes implementing same interface. Both class must implement methods for each other. so even though class B has nothing to do with calculate() method it must implemented in B because you want method implementation of A available for your proxy and your interface is forcing it.
                  Just split the interface and make A and B implements whatever they need. Again simple OO design is the solution.

                  Comment


                  • #39
                    Originally posted by tatvamasi
                    Not really, Service locators are more helpful if used for your contextual objects (services, J2EE resources). which are already created and made available for you. They are there just retrive 'em. Yes if you are talking interms of EJB sure there are people who would lookup a bean from context and create a remote interface right there. and return remote interface. And yes in that case Service Locator is creating.
                    I almost forgot. I totally agree with you there. I shouldn't have compared a factory and a service locator. A factory is typically employed to create object while a service locator connects layers together. I do realize now I was wrong to talk about invariants when speaking about service locator (a service locator can represent an association). However I still think DI (the push model) is much better than a service locator (the pull model) and that singletons are evil.

                    By the way, here's one of the best explanation of DI in my opinion. I am sure many people have already red it but just in case here it is :
                    http://martinfowler.com/articles/injection.html
                    Last edited by madtree; Sep 14th, 2006, 09:04 PM.

                    Comment


                    • #40
                      Originally posted by madtree
                      I would say your design sucks and this object has way too many responsabilities and you should split it so it doesn't depend on so many DAO*s or think about regrouping some DAOs together.
                      May be I gave a wrong example. However the point I was trying to make here was People use DI to create object dynamically instead of locating services. Which was the point to begin with.
                      If the datasource can change, well this requirement should be handled in the DAO or another helper object. Simple as that, DI isn't the problem, your design is.
                      what I said was if you inject datasource into your DAO I really will buy into it because datasource infact is a service. However my prefered method would be a service locator

                      I am going to say it again : an object must never allow to be in a incoherent state once it has been created. It must always respect its invariant. Otherwise, you're in for a lot of problems.
                      Sure, otherwise procedural languages would do fine for solving problems anyways.

                      Comment


                      • #41
                        Originally posted by madtree
                        Just split the interface and make A and B implements whatever they need. Again simple OO design is the solution.
                        you are right simple OO design is the solution. I never claimed program to interface is bad. I said it is a good practice but not the best. and yes you split it but that was not the point. The point was if you don't need it don't use it. Even if you needed some kind of proxy at a later day over your classes you still have ways around creating proxy over them. This doesn't mean everything should be concrete but it only means don't use it if there is no need.

                        Comment


                        • #42
                          Originally posted by tatvamasi
                          you are right simple OO design is the solution. I never claimed program to interface is bad. I said it is a good practice but not the best. and yes you split it but that was not the point. The point was if you don't need it don't use it. Even if you needed some kind of proxy at a later day over your classes you still have ways around creating proxy over them. This doesn't mean everything should be concrete but it only means don't use it if there is no need.
                          I think you will have to define "there is no need". Is that "I don't think it's going to be needed in next 5 minutes" or "I don't think it's going to be needed in next 5 months" or "I don't think it's going to be needed ever"? If it's not the "next 5 minutes" then you need to spend a lot of time contemplating and planning stuff that are trivially solved using good old DI.

                          Yes, you can always change your mind and refactor, but the cost of refactoring projects that are of non-trivial size are nowhere near the cost of making the right decision in the first place. Creating an interface you will never ever use on the other hand costs basically nothing and you don't need to refactor later even if you notice you don't need it.

                          Comment


                          • #43
                            Originally posted by dejanp
                            I think you will have to define "there is no need". Is that "I don't think it's going to be needed in next 5 minutes" or "I don't think it's going to be needed in next 5 months" or "I don't think it's going to be needed ever"? If it's not the "next 5 minutes" then you need to spend a lot of time contemplating and planning stuff that are trivially solved using good old DI.
                            As I said, I really could use some classes in communication. Afterall I am an ESL user anyways. However, if you want to have one class per interface why bother having them? What do you think they would ensure if it is per class scenario? if you have multiple classes implementing same interface than you would not be able to create effective proxies I believe well ofcourse depending on what are you trying to do (keeping in mind that you need to create proxy for some lagit work and also keeping in mind that was your argument).
                            Yes, you can always change your mind and refactor, but the cost of refactoring projects that are of non-trivial size are nowhere near the cost of making the right decision in the first place. Creating an interface you will never ever use on the other hand costs basically nothing and you don't need to refactor later even if you notice you don't need it.
                            Yes you are right non-trivial size projects might need integration with other at some point and time and there will be a need to have two systems communicate properly, Adapters can sure make my life easier. But than instead of keep providing other side a library every time i make a change and every time make sure that both side must keep their deployment schedule in sync., I would much prefer to deploy somekind of stateless protocol between them to communicate and allow them to maintain their own schedule and i maintain mine. They can switch to new changes whenever they want. Now if you are talking about Multi threaded socket based systems or building anything in top of it I can see your point.
                            Last edited by tatvamasi; Sep 15th, 2006, 09:55 AM.

                            Comment


                            • #44
                              Originally posted by dejanp
                              Yes, you can always change your mind and refactor, but the cost of refactoring projects that are of non-trivial size are nowhere near the cost of making the right decision in the first place.
                              I totally disagree with that. I never code anything unless I need it. Some lessons I have learned from following TDD.

                              I really do think we should stop having this kind of attitude in IT. It gives us a really bad reputation. Why programming for phantom requirements? There a lot of chance I don't understand the domain correctly and I am going to program this for nothing. And what prove me this is going to cost more to change later? I might agree if you were using a procedural language but it's not the case of OO. Refactoring is the key to the sucess IMO. The only thing I plan is my architecture, that's it. Introducing a interface is quite easy using a good refactoring tool.
                              Last edited by madtree; Sep 15th, 2006, 06:23 PM.

                              Comment


                              • #45
                                Originally posted by madtree
                                However I still think DI (the push model) is much better than a service locator (the pull model) and that singletons are evil.

                                By the way, here's one of the best explanation of DI in my opinion. I am sure many people have already red it but just in case here it is :
                                http://martinfowler.com/articles/injection.html
                                This is a very good article, and a great explanation of DI. What is more, it seems to back up most every beef I have with Spring (and perhaps tatvamasi's as well?). Allow me to explain:

                                Originally posted by fowler
                                Now if I'm using this class for just myself, this is all fine and dandy. But what happens when my friends are overwhelmed by a desire for this wonderful functionality and would like a copy of my program?
                                Note here, that he's essentially saying not to use DI (or interfaces) if you can't reasonably predict a need. Later he talks about this need for DI as a need for "plug-in" behavior. Not every app will need that behavior for every "aspect", but Spring, as I see it, has it available should you discover a need.

                                Originally posted by fowler
                                I've often heard the complaint that these kinds of service locators are a bad thing because they aren't testable because you can't substitute implementations for them. Certainly you can design them badly to get into this kind of trouble, but you don't have to. In this case the service locator instance is just a simple data holder. I can easily create the locator with test implementations of my services.

                                For a more sophisticated locator I can subclass service locator and pass that subclass into the registry's class variable. I can change the static methods to call a method on the instance rather accessing instance variables directly. I can provide thread specific locators by using thread specific storage. All of this can be done without changing clients of service locator.

                                A way to think of this is that service locator is a registry not a singleton. A singleton provides a simple way of implementing a registry, but that implementation decision is easily changed.
                                Here, and later when he talks about the pros and cons of DI vs Service Locator, he doesn't say that service locators or singletons (or DI for that matter) are good or evil, but that they have their place in the your design if they happen to best fit your need.

                                Originally posted by fowler
                                On the whole I dislike this approach. Although it's certainly flexible, it's not very explicit. The only way I can find out how to reach a service is through textual keys. I prefer explicit methods because it's easier to find where they are by looking at the interface definitions.
                                Note here how he also prefers what I call the "protection of the compiler", unless he has some compelling reason to lose that protection.

                                Originally posted by fowler
                                Of course the testing problem is exacerbated by component environments that are very intrusive, such as Java's EJB framework. My view is that these kinds of frameworks should minimize their impact upon application code, and particularly should not do things that slow down the edit-execute cycle. Using plugins to substitute heavyweight components does a lot help this process, which is vital for practices such as Test Driven Development.
                                ...and that is what Spring buys you. That is the main reason, in my opinion, why is a major force in the java world today.

                                Originally posted by fowler
                                A separate but often conflated issue is whether to use configuration files or code on an API to wire up services. For most applications that are likely to be deployed in many places, a separate configuration file usually makes most sense. Almost all the time this will be an XML file, and this makes sense. However there are cases where it's easier to use program code to do the assembly. One case is where you have a simple application that's not got a lot of deployment variation. In this case a bit of code can be clearer than separate XML file.

                                A contrasting case is where the assembly is quite complex, involving conditional steps. Once you start getting close to programming language then XML starts breaking down and it's better to use a real language that has all the syntax to write a clear program. You then write a builder class that does the assembly. If you have distinct builder scenarios you can provide several builder classes and use a simple configuration file to select between them.

                                I often think that people are over-eager to define configuration files. Often a programming language makes a straightforward and powerful configuration mechanism. Modern languages can easily compile small assemblers that can be used to assemble plugins for larger systems. If compilation is a pain, then there are scripting languages that can work well also.

                                It's often said that configuration files shouldn't use a programing language because they need to be edited by non-programmers. But how often is this the case? Do people really expect non-programmers to alter the transaction isolation levels of complex server-side application? Non-language configuration files work well only to the extent they are simple. If they become complex then it's time to think about using a proper programming language.

                                One thing we're seeing in the Java world at the moment is a cacophony of configuration files, where every component has its own configuration files which are different to everyone else's. If you use a dozen of these components, you can easily end up with a dozen configuration files to keep in sync.

                                My advice here is to always provide a way to do all configuration easily with a programmatic interface, and then treat a separate configuration file as an optional feature. You can easily build configuration file handling to use the programmatic interface. If you are writing a component you then leave it up to your user whether to use the programmatic interface, your configuration file format, or to write their own custom configuration file format and tie it into the programmatic interface
                                And that is my biggest beef with Spring (and perhaps tatvamasi's, if I understood him correctly). Spring is not showing me how to implement with what I called "Full Programmatic Access":

                                http://forum.springframework.org/showthread.php?t=24569

                                There is WAY too much emphasis on the "file-based" DOI in the Spring community, and not enough on the programmatic DOI (which would gain you the protection of the compiler).

                                Originally posted by fowler
                                The important issue in all of this is to ensure that the configuration of services is separated from their use. Indeed this is a fundamental design principle that sits with the separation of interfaces from implementation. It's something we see within an object-oriented program when conditional logic decides which class to instantiate, and then future evaluations of that conditional are done through polymorphism rather than through duplicated conditional code.
                                Here I emphasis the word "duplicated", to my earlier point: "(2) Never write the same chunk of code in more than one place". There is nothing essentially wrong with conditional code, but it seems to have fallen out of "fashion" (perhaps because, as I said, it isn't "sexy"?) The true "evil" is in the duplication of code, which, unless generated by the machine (and not after-coded by hand!), must now be hand-maintained by human programmers. Nothing in my experience is more boring and inefficient as that...

                                ...except perhaps maintaining "duplicated" design documentation. Now THERES a true hell-on-earth.

                                Comment

                                Working...
                                X