Announcement Announcement Module
Collapse
No announcement yet.
Mindset, thought process of a Spring guru/expert in design? Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Mindset, thought process of a Spring guru/expert in design?

    I am still in the middle of struggling to developing a mindset
    of doing Spring consciously in both web and non-web applications.
    It is easy to copy or follow sample Spring applications from others,
    but making designing/implementing a Spring app
    in the best Spring way become a person's natural skills takes time
    (others have similar experience?).
    I like Spring and I am fascinated. I did many traditional J2EE
    projects in the past. I believe doing an app in a Spring way
    represents a change (at least in some degree) in thought
    process or mindset in design and implementation...

    I understand Spring promotes many best practices such as
    coding to interface, loose coupling, but they are general and we
    know about these things a long long time ago....

    I hope to hear from Spring experts in this forum what the
    components are in their thinking when designing an app in
    the best Spring way, general or Spring specific, things to
    consider or avoid, etc....I hope to see a list of points or things
    with or without explanation. I dont need through explanations
    that consume too much of your time...

    Thanks in advance!

    Regards,
    Pete

  • #2
    ...what the
    components are in their thinking when designing an app in
    the best Spring way, general or Spring specific, things to
    consider or avoid, etc....I hope to see a list of points or things
    with or without explanation. I dont need through explanations
    that consume too much of your time...
    I like to see the components as independent. The dependency injection just gives you a great view to abstract the environment the component has to rely on (interact with) in order to perform its task.

    Comment


    • #3
      Martin, thanks very much for your input.

      I may need to do some clarification. When I say "components" in

      ...what the
      components are in their thinking when designing an app in
      the best Spring way
      I mean principles/rules/patterns/knowledge points to follow. I think you touched
      a good point of making SOFTWARE components independent. Do you mean the same as loose coupling or something different?

      Regards,
      Pete

      Comment


      • #4
        Do you mean the same as loose coupling or something different?
        Just because you said you are in the fascinated mind set about Spring. Loose coupling is quite different for me. For me loose coupling does not necessarily referes to dependency injection but to limit overall dependencies.

        It is just one thing that I noticed first, while I was working with IOC containers (and finally Spring). There is a shift in thinking. Normally it is a main goal to limit dependencies between collaborating units. (applies to all levels of unit granularity) But never the less, without an IOC container there is usually a lot of code involved, where one component just assembles and sets up it own visible environment (for example doing a jndi lookup itself, creating an appropriate component it needs to collaborate with, using static/singleton implementations).

        With Dependency Injection a component isn't assembling anything of it's environment on it's own. Every main component it depends or relies on gets injected. So the environment of the component is quite clear and can be quite well analysed. The fun part is that such a set-up is flexible and easy to test but best of it all, it matches the Context and Forces part that are involved in the problem/solution pair the component represents.

        It just decreases the affords needed to think about the component. There is no hidden magic in the implementation due to the lack of such setup code. That is usually the most important difference.

        Never the less this is not loose coupling for me, since you can still impose lots of couplings and still use dependency injection in an appropriated way.


        Another thing you might want to get you feet wet with, is the possibility of factory beans. Check out what it can do for you. At first, I didn't utilized factories but they are so dead simple and yet very powerful, so you shouldn't avoid them.

        The rest is just looking into the code. All the beans Spring provide by its framework, is quite worth to take a look at. Check how the Proxy factories work, or the transaction managers. There is quite a lot of useful hints etc. The framework itself is a good teacher here.

        The book 'Pro Spring' also provides a very good read and lots of knowledge of the Spring folks. If you don't have it, check it out. Lots of those little helpers that can ease your every days Spring life.


        but they are general and we know about these things a long long time ago....
        Do you know how old the best practices in terms of formulating 'if'-statements are? Knowing things for a long time doesn't mean they get much attention.


        Also one good thing is taking a non-Spring application and porting it to Spring. Take a very close look on your test-suite and check for refactorings in names and structure. Most of the impact Spring has on your code base is straight forward but the flexibility and the provided possibilities might surprises you never the less (of cause if you didn't have done such porting stuff,yet).


        Cheers,

        Martin (Kersten)

        Comment


        • #5
          Originally posted by Martin Kersten
          ...what the
          components are in their thinking when designing an app in
          the best Spring way, general or Spring specific, things to
          consider or avoid, etc....I hope to see a list of points or things
          with or without explanation. I dont need through explanations
          that consume too much of your time...
          I like to see the components as independent. The dependency injection just gives you a great view to abstract the environment the component has to rely on (interact with) in order to perform its task.
          It is not only the environment the components interacts with, but also the detail behaviour the components requires. I use a lot of strategies/policies the finetune components.

          Comment


          • #6
            It is not only the environment the components interacts with, but also the detail behaviour the components requires. I use a lot of strategies/policies the finetune components.
            Well I was a bit tricky here with the environment speech. I actually ment that the lifecycle of every injected dependency is outside of the scope of the object. So the dependency comes from the outside (just existing before the component exists). From an architectual view, sure there is the architectural border surrounding those strategy objects and declaring them to be inside and not outside of the architectural border. So environment is tricky. But I ment everything that is not the component or something depending on the component. Sorry for causing confusion here.

            Comment

            Working...
            X