What does the Spring framework do? Should I use it? Why or why not? [closed]

What does the Spring framework do? Should I use it? Why or why not?

Spring is a framework that helps you to "wire" different components together. It is most useful in cases where you have a lot of components and you might decide to combine them in different ways, or wish to make it easy to swap out one component for another depending on different settings or environments.

This is what I've always understood "dependency injection" to be.

I would suggest a different definition:

"Dependency injection is where you design your classes so that they expect an outside actor to directly give them the sub-tools they need to do their jobs before anybody starts asking them to do something."

Most of the XML (or annotation-based) stuff is telling spring:

• When someone asks for a "HammerStore", I want you to create a example.HammerStore and return it result. Cache the result, since there is only one store.
• When someone asks for a "SomeHammer", I want you to find a "HammerStore" and return the result of its getHammer() method. Do not cache the result, but make a new hammer each time.
• When someone asks for a "SomeWrench", I want you to create a example.WrenchImpl and take the configuration setting guage and put it into the setWrenchSize() property. Do not cache the result, but create a new one each time.
• When someone asks for a "OurPlumber", I want to you create an instance of example.PlumberImpl. Put the string "Pedro" into its setName() method, put a "SomeHammer" into its setHammer()method, and put a "SomeHammer" into its setWrench() method. Return the result, but do cache it, since we only have one Pedro.

In this way, Spring lets your connect components, label them, control their lifecycle/caching, and alter behavior based on configuration.

To facilitate [testing] I typically make (at least) two versions of a method : one that uses instance variables, and one that only uses variables that are passed in to the method.

That sounds like a lot of overhead for not a lot of benefit for me. I would suggest that you make your instance variables protected or package-level, and then locate the unit tests inside the same package. That way you can alter or test the instance variables in-place.

http://programmers.stackexchange.com/questions/92393/what-does-the-spring-framework-do-should-i-use-it-why-or-why-not

What is an idempotent operation?

In computing, an idempotent operation is one that has no additional effect if it is called more than once with the same input parameters.

Pure functions (those whose return value only depends on the input parameters) are always idempotent (Python syntax examples):

def sq(x):
    return x * x

Functions that only set a value are idempotent:

g_x = 5

def set_x(x):
    global g_x
    g_x = x

However, functions that do something like append to a global list are not idempotent:

a = []

def add_x(x):
    a.append(x)

Idempotent operations are often used in the design of network protocols, where a request to perform an operation is guaranteed to happen at least once, but might also happen more than once. If the operation is idempotent, then there is no harm in performing the operation two or more times.

It is somewhat unfortunate that in mathematics, the use of idempotent is slightly different. See the Wikipedia article on idempotence for more information.

http://stackoverflow.com/questions/1077412/what-is-an-idempotent-operation

What does it mean to “program to an interface”?

There are some wonderful answers on here to this questions that get into all sorts of great detail about interfaces and loosely coupling code, inversion of control and so on. There are some fairly heady discussions, so I'd like to take the opportunity to break things down a bit for understanding why an interface is useful.

When I first started getting exposed to interfaces, I too was confused about their relevance. I didn't understand why you needed them. If we're using a language like Java or C#, we already have inheritance and I viewed interfaces as a weaker form of inheritance and thought, "why bother?" In a sense I was right, you can think of interfaces as sort of a weak form of inheritance, but beyond that I finally understood their use as a language construct by thinking of them as means of classifying common traits or behaviors that were exhibited by potentially many non-related classes of objects.

For example -- say you have a SIM game and have the following classes:

 class HouseFly inherits Insect {
   void FlyAroundYourHead();
   void LandOnThings();
 }

 class Telemarketer inherits Person {
   void CallDuringDinner();
   void ContinueTalkingWhenYouSayNo();
 }

Clearly, these two objects have nothing in common in terms of direct inheritance. But, you could say they are both annoying.

Let's say our game needs to have some sort of random thing that annoys the game player when they eat dinner. This could be a HouseFly or a Telemarketer or both -- but how do you allow for both with a single function? And how do you ask each different type of object to "do their annoying thing" in the same way?

The key to realize is that both a Telemarketer and HouseFly share a common loosely interpreted behavior even though they are nothing alike in terms of modeling them. So, let's make an interface that both can implement:

 interface IPest {
    void BeAnnoying();
 }


 class HouseFly inherits Insect implements IPest {
   void FlyAroundYourHead();
   void LandOnThings();

   void BeAnnoying() {
     FlyAroundYourHead();
     LandOnThings();
   }
 }

 class Telemarketer inherits Person implements IPest {
   void CallDuringDinner();
   void ContinueTalkingWhenYouSayNo();

   void BeAnnoying() {
      CallDuringDinner();
      ContinueTalkingWhenYouSayNo();
   }
 }

We now have two classes that can each be annoying in their own way. And they do not need to derive from the same base class and share common inherent characteristics -- they simply need to satisfy the contract of IPest -- that contract is simple. You just have to BeAnnoying. In this regard, we can model the following:

 class DiningRoom {


   DiningRoom(Person[] diningPeople, IPest[] pests) { ... }

   void ServeDinner() {
     when diningPeople are eating,

       foreach pest in pests
         pest.BeAnnoying();
   }
 }

Here we have a dining room that accepts a number of diners and a number of pests -- note the use of the interface. This means that in our little world, a memeber of the pests array could actually be a Telemarketer object or a HouseFly object.

The ServeDinner method is called when dinner is served and our people in the dining room are supposed to eat. In our little game, that's when our pests do their work -- each pest is instructed to be annoying by way of the IPest interface. In this way, we can easily have both Telemarketers and HouseFlys be annoying in each of their own ways -- we care only that we have something in the DiningRoom object that is a pest, we don't really care what it is and they could have nothing in common with other.

This very contrived pseudo-code example (that dragged on a lot longer than I anticipated) is simply meant to illustrate the kind of thing that finally turned the light on for me in terms of when we might use an interface. I apologize in advance for the silliness of the example, but hope that it helps in your understanding. And, to be sure, the other posted answers you've received here really cover the gamut of the use of interfaces today in design patterns and development methodologies.

http://stackoverflow.com/questions/383947/what-does-it-mean-to-program-to-an-interface

What is abstraction?

Abstraction is the technique of hiding implementation. At it's core there's not much more to that answer. The bulk of meaning to abstraction come from how and why it is used.

It is used for the following scenarios

• Reduce complexity. (Create a simple interface)
• Allow for implementation to be modified without impacting its users.
• Create a common interface to support polymorphism (treating all implementations of the abstracted layer the same.
• Force users to extend the implementation rather than modify.
• Support cross platform by changing the implementation per platform.

http://stackoverflow.com/questions/7028242/what-is-abstraction

What is the difference between a framework and a library?

Actually these terms can mean a lot of different things depending the context they are used.

For example, on Mac OS X frameworks are just libraries, packed into a bundle. Within the bundle you will find an actual dynamic library (libWhatever.dylib). The difference between a bare library and the framework on Mac is that a framework can contain multiple different versions of the library. It can contain extra resources (images, localized strings, XML data files, UI objects, etc.) and unless the framework is released to public, it usually contains the necessary .h files you need to use the library.

Thus you have everything within a single package you need to use the library in your application (a C/C++/Objective-C library without .h files is pretty useless, unless you write them yourself according to some library documentation), instead of a bunch of files to move around (a Mac bundle is just a directory on the Unix level, but the UI treats it like a single file, pretty much like you have JAR files in Java and when you click it, you usually don't see what's inside, unless you explicitly select to show the content).

Wikipedia calls framework a "buzzword". It defines a software framework as

A software framework is a re-usable design for a software system (or subsystem). A software framework may include support programs, code libraries, a scripting language, or other software to help develop and glue together the different components of a software project. Various parts of the framework may be exposed through an API..

So I'd say a library is just that, "a library". It is a collection of objects/functions/methods (depending on your language) and your application "links" against it and thus can use the objects/functions/methods. It is basically a file containing re-usable code that can usually be shared among multiple applications (you don't have to write the same code over and over again).

A framework can be everything you use in application development. It can be a library, a collection of many libraries, a collection of scripts, or any piece of software you need to create your application. Framework is just a very vague term.

Here's an article about some guy regarding the topic "Library vs. Framework". I personally think this article is highly arguable. It's not wrong what he's saying there, however, he's just picking out one of the multiple definitions of framework and compares that to the classic definition of library. E.g. he says you need a framework for sub-classing. Really? I can have an object defined in a library, I can link against it, and sub-class it in my code. I don't see how I need a "framework" for that. In some way he rather explains how the term framework is used nowadays. It's just a hyped word, as I said before. Some companies release just a normal library (in any sense of a classical library) and call it a "framework" because it sounds more fancy.

http://stackoverflow.com/questions/148747/what-is-the-difference-between-a-framework-and-a-library

What is Java EE?

J2EE is actually a collection of technologies and APIs for the Java platform designed to support "Enterprise" Applications which can generally be classed as large-scale, distributed, transactional and highly-available applications designed to support mission-critical business requirements.

In terms of what an employee is looking for in specific techs, it is quite hard to say, because the playing field has kept changing over he last 5 years. It really is about the class of problems that are being solved more than anything else. Transactions and distribution are key.

http://stackoverflow.com/questions/106820/what-is-java-ee

What does the Spring framework do? Should I use it? Why or why not? [closed]

What does the Spring framework do? Should I use it? Why or why not?

Spring is a framework that helps you to "wire" different components together. It is most useful in cases where you have a lot of components and you might decide to combine them in different ways, or wish to make it easy to swap out one component for another depending on different settings or environments.

This is what I've always understood "dependency injection" to be.

I would suggest a different definition:

"Dependency injection is where you design your classes so that they expect an outside actor to directly give them the sub-tools they need to do their jobs before anybody starts asking them to do something."

Most of the XML (or annotation-based) stuff is telling spring:

• When someone asks for a "HammerStore", I want you to create a example.HammerStore and return it result. Cache the result, since there is only one store.
• When someone asks for a "SomeHammer", I want you to find a "HammerStore" and return the result of its getHammer() method. Do not cache the result, but make a new hammer each time.
• When someone asks for a "SomeWrench", I want you to create a example.WrenchImpl and take the configuration setting guage and put it into the setWrenchSize() property. Do not cache the result, but create a new one each time.
• When someone asks for a "OurPlumber", I want to you create an instance of example.PlumberImpl. Put the string "Pedro" into its setName() method, put a "SomeHammer" into its setHammer()method, and put a "SomeHammer" into its setWrench() method. Return the result, but do cache it, since we only have one Pedro.

In this way, Spring lets your connect components, label them, control their lifecycle/caching, and alter behavior based on configuration.

To facilitate [testing] I typically make (at least) two versions of a method : one that uses instance variables, and one that only uses variables that are passed in to the method.

That sounds like a lot of overhead for not a lot of benefit for me. I would suggest that you make your instance variables protected or package-level, and then locate the unit tests inside the same package. That way you can alter or test the instance variables in-place.

http://programmers.stackexchange.com/questions/92393/what-does-the-spring-framework-do-should-i-use-it-why-or-why-not