I'm learning the java Spring framework. So far, I understood that Spring will make stuff transparent with its configurations so that IoC and Factory are not too complicated to implement...
Now I have coded A LOT but I have never thought of organizing my code based on design patterns...
My query is that for a basic CRUD, how (and for what goal) one would design classes based on IoC, then on Factory to that in the main the user can just calla simple MyObject.Insert(MyData) ?
->I'm learning the java Spring framework.
My congratulations, and condolences.
So far, I understood that Spring will make stuff transparent with its configurations so that IoC and Factory are not too complicated to implement
Well no. Spring encourages Dependency Injection, which can be a good thing. But you don't need Spring to do Dependency Injection.
With Spring what you get is either so many @autowired annotations spread in your code that you are now hopelessly coupled to the framework, or all your composition root (usually main) code moved into an xml file.
The annotations basically hide the fact that you're programming in a new language now. It's following a philosophy called convention over configuration, which works so long as everything goes as predicted. If you don't mind not being able to hire simple Java programmers but now must hire Java/Spring programmers, then fine. But these things hopelessly couple you to the framework. If that bothers you consider writing POJO's.
Moving the main code into an xml file gives you a clear separation of construction code and behavior code. The separation is a good thing and works fine with POJO's but you could have left that in main and done the separation by hand if you just trusted yourself not to mix construction and behavior when they are expressed in the same language. If you need this separation enforced fine but you could learn to just not make a mess by spreading new all over the place. new is most at home in a static context. POJO's are best off not even knowing that static methods exist.
Here is a design pattern for doing this:
static void main() {
//Construct many objects and "wire" them together using dependency injection
String greetee = "world"; // <- A dependency
Greeter greeter = new Greeter(greetee); // <- An injection
//Start the object graph ticking by calling only one method.
greeter.greet(); // All behavior for this program happens now
}
You can construct many objects this way and connect them in wonderful ways. It doesn't have to be flat. You could use any creational patterns you like to do your construction. What you shouldn't do is mix any business logic behavior in that part of your code. We should only see behavior start when we execute main's last line. At this point we're out of the static context.
Spring and most all DI frameworks use this pattern. It just lumps the wiring of the "many objects" into one factory call that reads an xml file. If you think that makes it easier than using java constructors or creational patterns fine.
IoC is an important principle to understand. Simply using Spring won't make you understand it and doesn't really do anything to help implement it.
Inversion of Control (IoC) is the art of not forcing high level code to depend directly on low level code. This allows low level details to change without impacting the high level code or each other. Being able to change is what keeps software soft.
IoC does this by having one object talk to another through polymorphism. Some call this Tell, don't ask. The point is that you shouldn't have to know what you're talking to.
Now I have coded A LOT but I have never thought of organizing my code based on design patterns...
Design patterns are not so much a way of organizing code as they are a recurring pattern for solving problems in languages that can't trivially solve those problems. They are not a best practice nor are they a design principle. They're just stuff that happens, a lot. So we gave them a name to make talking about them easier. Patterns are not always good things in the design sense; if you're trying to use them to design your programs instead of treating them as tools that solve certain, specific problems, then you're doing it wrong.
IoC is a design principle (not a pattern). It requires some form of polymorphism. Some patterns give you different kinds of polymorphism. For example the strategy pattern and the template pattern both give you polymorphism. The first though composition and delegation. The second through inheritance. I'm not a fan of the second.
Play with Spring and discover what it's really doing for you. Decide for yourself if you really need what it offers. I've seen it clean up code. I've seen clean code that doesn't need it. It's really a question of who you're coding with.
