People who just started to learn Spring framework is often confused by the term "Inversion of Control" (IoC) which can be achieved through "Dependency Injection" (DI).
DI is a way of providing the dependencies (e.g. creating objects and its dependencies), wiring components into application. In Spring, those objects defined and instantiated by Spring containers then inject into application are called Spring Beans.
IoC is a concept, it means to create instances of dependencies first, the concept is usually achieved by using metadata-driven approach to assemble instances at runtime. IoC is the end result of DI. However, DI is not the only way to achieve IoC. For example, Workday's XpressO is a great example of metadata-driven development to achieve IoC.
Here are some more good explanations:
Inversion of Control (IoC) means to create instances of dependencies first and latter instance of a class (optionally injecting them through constructor), instead of creating an instance of the class first and then the class instance creating instances of dependencies. Thus, inversion of control inverts the flow of control of the program. Instead of the callee controlling the flow of control (while creating dependencies), the caller controls the flow of control of the program.
IoC is a programming technique, expressed here in terms of object-oriented programming, in which object coupling is bound at run time by an assembler object and is typically not known at compile time using static analysis.
IoC is a common pattern in the Java community that helps wire lightweight containers or assemble components from different projects into a cohesive application.
Spring helps in the creation of loosely coupled applications because of Dependency Injection.
I come across a list of interview questions on the web for interviewing software engineers, or specifically, for coders.
What's the differences among a software engineer, a software developer, a programmer, and a coder?
It's arguable what constitutes a good developer. To me, it's the curiosity and the ability inside a developer to find and implement cost-effective software solutions that are easy to be extended by others. Knowing answers to the list below does not demonstrate the core ability of what I believe a good developer should have.
Coding ability is only partially relevant to become a good software developer. There are other factors like the ability to identify the problem, the ability to provide solution, and the ability to allow others to understand your thought process so that they can extend/maintain your code easiily.
Learn SCRUM in 3 Minutes
Scrum is a flexible agile development practice / method / framework built around some agile principles and on top of BDD. Scrum is one of many agile methods. Each SCRUM team is recommended to be not too big. In Scrum practice, features of products are written from the perspectives of end users. Features are known as user stories. The collection of user stories are called product backlog, which is a wish list to make end product great.
OOD / OOP Principles
Not every senior software developer understand good design principles. Good object-oriented design is not common. It's all about knowing the 'why' then devote to learning to design with good OOD concepts and OOP principles in programming. It takes disciplines and years of experiences.
In object-oriented design, classes are great to achieve Separation of Concerns that is modular, flexible, and reusable software. In addition, there are three good primary OOD concepts I'd like to fall back on, and 5 OOP principles that I initially forced myself practice coding Java, then I gradually became natural doing so.
Behavior-Driven Development (BDD)
BDD is basically TDD done properly. It is an agile methodology for building a shared understanding of what software to build by discussing using examples. It is a technique that uses a business language to define acceptance criteria. It is about figuring out what to build with an outside-in approach - having conversations, capturing conversations, automating conversations. In other words, first think about what you’re about to write, then think about how you would test the code, before writing it.
BDD is not an agile project framework (e.g. SCRUM) nor a project management approach.