A repeating theme in my development work has been the use of or creation of an in-house plug-in architecture. I've seen it approached many ways - configuration files (XML, .conf, and so on), inheritance frameworks, database information, libraries, and others. In my experience:
A database isn't a great place to store your configuration information, especially co-mingled with data
Attempting this with an inheritance hierarchy requires knowledge about the plug-ins to be coded in, meaning the plug-in architecture isn't all that dynamic
Configuration files work well for providing simple information, but can't handle more complex behaviors
Libraries seem to work well, but the one-way dependencies have to be carefully created.
As I seek to learn from the various architectures I've worked with, I'm also looking to the community for suggestions. How have you implemented a SOLID plug-in architecture? What was your worst failure (or the worst failure you've seen)? What would you do if you were going to implement a new plug-in architecture? What SDK or open source project that you've worked with has the best example of a good architecture?
A few examples I've been finding on my own:
Perl's Module::Plugable and IOC for dependency injection in Perl
The various Spring frameworks (Java, .NET, Python) for dependency injection.
An SO question with a list for Java (including Service Provider Interfaces)
An SO question for C++ pointing to a Dr. Dobbs article
An SO question regarding a specific plugin idea for ASP.NET MVC
These examples seem to play to various language strengths. Is a good plugin architecture necessarily tied to the language? Is it best to use tools to create a plugin architecture, or to do it on one's own following models?
This is not an answer as much as a bunch of potentially useful remarks/examples.
One effective way to make your application extensible is to expose its internals as a scripting language and write all the top level stuff in that language. This makes it quite modifiable and practically future proof (if your primitives are well chosen and implemented). A success story of this kind of thing is Emacs. I prefer this to the eclipse style plugin system because if I want to extend functionality, I don't have to learn the API and write/compile a separate plugin. I can write a 3 line snippet in the current buffer itself, evaluate it and use it. Very smooth learning curve and very pleasing results.
One application which I've extended a little is Trac. It has a component architecture which in this situation means that tasks are delegated to modules that advertise extension points. You can then implement other components which would fit into these points and change the flow. It's a little like Kalkie's suggestion above.
Another one that's good is py.test. It follows the "best API is no API" philosophy and relies purely on hooks being called at every level. You can override these hooks in files/functions named according to a convention and alter the behaviour. You can see the list of plugins on the site to see how quickly/easily they can be implemented.
A few general points.
Try to keep your non-extensible/non-user-modifiable core as small as possible. Delegate everything you can to a higher layer so that the extensibility increases. Less stuff to correct in the core then in case of bad choices.
Related to the above point is that you shouldn't make too many decisions about the direction of your project at the outset. Implement the smallest needed subset and then start writing plugins.
If you are embedding a scripting language, make sure it's a full one in which you can write general programs and not a toy language just for your application.
Reduce boilerplate as much as you can. Don't bother with subclassing, complex APIs, plugin registration and stuff like that. Try to keep it simple so that it's easy and not just possible to extend. This will let your plugin API be used more and will encourage end users to write plugins. Not just plugin developers. py.test does this well. Eclipse as far as I know, does not.
In my experience I've found there are really two types of plug-in Architectures.
One follows the Eclipse model which is meant to allow for freedom and is open-ended.
The other usually requires plugins to follow a narrow API because the plugin will fill a specific function.
To state this in a different way, one allows plugins to access your application while the other allows your application to access plugins.
The distinction is subtle, and sometimes there is no distiction... you want both for your application.
I do not have a ton of experience with Eclipse/Opening up your App to plugins model (the article in Kalkie's post is great). I've read a bit on the way eclipse does things, but nothing more than that.
Yegge's properties blog talks a bit about how the use of the properties pattern allows for plugins and extensibility.
Most of the work I've done has used a plugin architecture to allow my app to access plugins, things like time/display/map data, etc.
Years ago I would create factories, plugin managers and config files to manage all of it and let me determine which plugin to use at runtime.
Now I usually just have a DI framework do most of that work.
I still have to write adapters to use third party libraries, but they usually aren't that bad.
One of the best plug-in architectures that I have seen is implemented in Eclipse. Instead of having an application with a plug-in model, everything is a plug-in. The base application itself is the plug-in framework.
http://www.eclipse.org/articles/Article-Plug-in-architecture/plugin_architecture.html
I'll describe a fairly simple technique that I have use in the past. This approach uses C# reflection to help in the plugin loading process. This technique can be modified so it is applicable to C++ but you lose the convenience of being able to use reflection.
An IPlugin interface is used to identify classes that implement plugins. Methods are added to the interface to allow the application to communicate with the plugin. For example the Init method that the application will use to instruct the plugin to initialize.
To find plugins the application scans a plugin folder for .Net assemblies. Each assembly is loaded. Reflection is used to scan for classes that implement IPlugin. An instance of each plugin class is created.
(Alternatively, an Xml file might list the assemblies and classes to load. This might help performance but I never found an issue with performance).
The Init method is called for each plugin object. It is passed a reference to an object that implements the application interface: IApplication (or something else named specific to your app, eg ITextEditorApplication).
IApplication contains methods that allows the plugin to communicate with the application. For instance if you are writing a text editor this interface would have an OpenDocuments property that allows plugins to enumerate the collection of currently open documents.
This plugin system can be extended to scripting languages, eg Lua, by creating a derived plugin class, eg LuaPlugin that forwards IPlugin functions and the application interface to a Lua script.
This technique allows you to iteratively implement your IPlugin, IApplication and other application-specific interfaces during development. When the application is complete and nicely refactored you can document your exposed interfaces and you should have a nice system for which users can write their own plugins.
I once worked on a project that had to be so flexible in the way each customer could setup the system, which the only good design we found was to ship the customer a C# compiler!
If the spec is filled with words like:
Flexible
Plug-In
Customisable
Ask lots of questions about how you will support the system (and how support will be charged for, as each customer will think their case is the normal case and should not need any plug-ins.), as in my experience
The support of customers (or
fount-line support people) writing
Plug-Ins is a lot harder than the
Architecture
Usualy I use MEF. The Managed Extensibility Framework (or MEF for short) simplifies the creation of extensible applications. MEF offers discovery and composition capabilities that you can leverage to load application extensions.
If you are interested read more...
In my experience, the two best ways to create a flexible plugin architecture are scripting languages and libraries. These two concepts are in my mind orthogonal; the two can be mixed in any proportion, rather like functional and object-oriented programming, but find their greatest strengths when balanced. A library is typically responsible for fulfilling a specific interface with dynamic functionality, whereas scripts tend to emphasise functionality with a dynamic interface.
I have found that an architecture based on scripts managing libraries seems to work the best. The scripting language allows high-level manipulation of lower-level libraries, and the libraries are thus freed from any specific interface, leaving all of the application-level interaction in the more flexible hands of the scripting system.
For this to work, the scripting system must have a fairly robust API, with hooks to the application data, logic, and GUI, as well as the base functionality of importing and executing code from libraries. Further, scripts are usually required to be safe in the sense that the application can gracefully recover from a poorly-written script. Using a scripting system as a layer of indirection means that the application can more easily detach itself in case of Something Bad™.
The means of packaging plugins depends largely on personal preference, but you can never go wrong with a compressed archive with a simple interface, say PluginName.ext in the root directory.
I think you need to first answer the question: "What components are expected to be plugins?"
You want to keep this number to an absolute minimum or the number of combinations which you must test explodes. Try to separate your core product (which should not have too much flexibility) from plugin functionality.
I've found that the IOC (Inversion of Control) principal (read springframework) works well for providing a flexible base, which you can add specialization to to make plugin development simpler.
You can scan the container for the "interface as a plugin type advertisement" mechanism.
You can use the container to inject common dependencies which plugins may require (i.e. ResourceLoaderAware or MessageSourceAware).
The Plug-in Pattern is a software pattern for extending the behaviour of a class with a clean interface. Often behaviour of classes is extended by class inheritance, where the derived class overwrites some of the virtual methods of the class. A problem with this solution is that it conflicts with implementation hiding. It also leads to situations where derived class become a gathering places of unrelated behaviour extensions. Also, scripting is used to implement this pattern as mentioned above "Make internals as a scripting language and write all the top level stuff in that language. This makes it quite modifiable and practically future proof". Libraries use script managing libraries. The scripting language allows high-level manipulation of lower level libraries. (Also as mentioned above)
Related
I have seen this question What is the difference between a class library and a framework
and throughout all the provided answers, the framework is always referenced as a framework. I am looking to get more technical. What exactly is a framework? A class of classes that control all functionality and provide ultimate abstraction and the ability to customize it? I am just looking to understand what exactly a framework is, as far as initializing it, not just what it accomplishes, but how exactly it is implemented. How I believe it's used/implemented is listed below.
variable = Framework() -> Reference the variable
Framework is an infrastructure, ready-made and predefined, with some particular rules of the game on the "development field", according to which, you can build your application, on top of it, by "playing with framework rules" (you can, at some extent, customize those rules).
Spring MVC is a good example of Framework. You don't control how the View Resolving, Dispatching or Template Rendering happen and achieve a goal together.
Think of this as a big machine, where you can plug in and integrate your components which are applicable to that machine.
Library, on the other hand, is just a set of classes, which provide already implemented functionality out of the box, in order to not start inventing the bicycle again and again.
Apache Commons is a good example of the Library. It has a lot of ready tools and functionality to facilitate your work with String objects.
Think of this as a set of instruments and tools, using which, you can build your own machine.
With respect to how it is implemented question. This is like asking how the Boeing A220 is built?. I'm not sure anyone can describe here how the Framework is implemented in the details. But if I understood uour point about whether the Framework is used via classes, then:
Framework might provide some classes as an abstraction, yes, but it's not about them, it's more about mechanics of the entire system. The main thing it provides is the mechanism and mechanics of how the system is designed to work.
Looking at Microsoft's Managed Extensibility Framework (MEF) and various IoC containers (such as Unity), I am failing to see when to use one type of solution over the other. More specifically, it seems like MEF handles most IoC type patterns and that an IoC container like Unity would not be as necessary.
Ideally, I would like to see a good use case where an IoC container would be used instead of, or in addition to, MEF.
When boiled down, the main difference is that IoC containers are generally most useful with static dependencies (known at compile-time), and MEF is generally most useful with dynamic dependencies (known only at run-time).
As such, they are both composition engines, but the emphasis is very different for each pattern. Design decisions thus vary wildly, as MEF is optimized around discovery of unknown parts, rather than registrations of known parts.
Think about it this way: if you are developing your entire application, an IoC container is probably best. If you are writing for extensibility, such that 3rd-party developers will be extending your system, MEF is probably best.
Also, the article in #Pavel Nikolov's answer provides some great direction (it is written by Glenn Block, MEF's program manager).
I've been using MEF for a while and the key factor for when we use it instead of IOC products is that we regularly have 3-5 implementations of a given interface sitting in our plugins directory at a given time. Which one of those implementations should be used is actually something that can only be decided at runtime.
MEF is good at letting you do just that. Typically, IOC is geared toward making sure you could swap out, for a cononical example, an IUserRepository based on ORM Product 1 for ORM Product 2 at some point in the future. However, most IOC solutions assume that there will only be one IUserRepository in effect at a given time.
If, however, you need to choose one based on the input data for a given page request, IOC containers are typically at a loss.
As an example, we do our permission checking and our validation via MEF plugins for a big web app I've been working on for a while. Using MEF, we can look at when the record's CreatedOn date and go digging for the validation plugin that was actually in effect when the record was created and run the record BOTH through that plugin AND the validator that's currently in effect and compare the record's validity over time.
This kind of power also lets us define fallthrough overrides for plugins. The apps I'm working on are actually the same codebase deployed for 30+ implementations. So, we've typically go looking for plugins by asking for:
An interface implementation that is specific to the current site and the specific record type in question.
An interface implementation that is specific to the current site, but works with any kind of record.
An interface that works for any site and any record.
That lets us bundle a set of default plugins that will kick in, but only if that specific implementation doesn't override it with customer specific rules.
IOC is a great technology, but really seems to be more about making it easy to code to interfaces instead of concrete implementations. However, swapping those implementations out is more of a project shift kind of event in IOC. In MEF, you take the flexibility of interfaces and concrete implementations and make it a runtime decision between many available options.
I am apologizing for being off-topic. I simply wanted to say that there are 2 flaws that render MEF an unnecessary complication:
it is attribute based which doesn't do any good to helping you figuring out why things work as they do. There's no way to get to the details burred in the internals of the framework to see what exactly is going on there. There is no way to get a tracing log or hook up to the resolving mechanisms and handle unresolved situations manually
it doesn't have any troubleshooting mechanism to figure out the reasons for why some parts get rejected. Despite pointing at a failing part it doesn't tell you why that part has failed.
So I am very disappointed with it. I spent too much time fighting windmills trying to bootstrap a few classes instead of working on the real problems. I convinced there is nothing better than the old-school dependency injection technique when you have full control over what is created, when, and can trace anything in the VS debugger. I wish somebody who advocates MEF presented a bunch of good reasons as to why would I choose it over plain DI.
I agree that MEF can be a fully capable IoC framework. In fact I'm writing an application right now based on using MEF for both extensibility and IoC. I took the generic parts of it and made it into a "framework" and open sourced it as its own framework called SoapBox Core in case people want to see how it works.
In particular, take a look at how the Host works if you want to see MEF in action.
Scaffolding, what is it? Is it a Rails-only thing?
Scaffolding generally refers to a quickly set up skeleton for an app. It's not rails-only since other platforms have it as well. It's also not generally meant to be a "final" system; merely the first, smallest way to do it.
From Wikipedia:
Scaffolding is a meta-programming
method of building database-backed
software applications. It is a
technique supported by some
model-view-controller frameworks, in
which the programmer may write a
specification that describes how the
application database may be used. The
compiler uses this specification to
generate code that the application can
use to create, read, update and delete
database entries, effectively treating
the template as a "scaffold" on which
to build a more powerful application.
Just like a real scaffolding in a building construction site, scaffolding gives you some kind of a (fast, simplified, temporary) structure for your project, on which you can rely to build the real project.
It can be (and is today) used to describe many things - from abstracting DB layers, to web apps folder structures, and to generating and managing project dependencies .
It is not something that is specific to any language / technology, just like the term skeleton or boilerplate is platform agnostic.
It is just a term borrowed from real scaffolding (like mentioned above).
You build some fast, simplified, (sometimes external, sometimes temporary) structure that will help you to build the real, more complex, finalized structure under, above, inside or outside of that temporary structure .
.. And just like the real scaffolding, the scaffolding structure is meant to support the building process of the project, rather than the project itself (with some exceptions).
Scafolding is usually some type of code generation where you point it at a database, and the technology creates basic CRUD (create, read, update, delete) screens.
I believe that Wikipedia and some answers here provides a narrow and restricted view. Scaffolding is not just for CRUD operations on top of a database. Scaffolding has a broader objective to give you a skeleton app for any kind of technology.
Yeoman is a modern and useful tool for scaffolding. Using their own words:
The web's scaffolding tool for modern webapps
What's Yeoman?
Yeoman helps you to kickstart new projects, prescribing best practices
and tools to help you stay productive.
To do so, we provide a generator ecosystem. A generator is basically a
plugin that can be run with the yo command to scaffold complete
projects or useful parts.
Through our official Generators, we promote the "Yeoman workflow".
This workflow is a robust and opinionated client-side stack,
comprising tools and frameworks that can help developers quickly build
beautiful web applications. We take care of providing everything
needed to get started without any of the normal headaches associated
with a manual setup.
With a modular architecture that can scale out of the box, we leverage
the success and lessons learned from several open-source communities
to ensure the stack developers use is as intelligent as possible.
As firm believers in good documentation and well thought out build
processes, Yeoman includes support for linting, testing, minification
and much more, so developers can focus on solutions rather than
worrying about the little things.
That's it. Use scaffolding to create a quick-start application to work as an example or the foundation of your solution. It makes you productive faster them building things from scratch.
It is not a rails only term although I think it originated there (at least that is where I first heard it.)
Scaffolding is a framework that allows you to do basic CRUD operations against your database with little or no code. Generally, you then go through and add the code to manage the data the way you want replacing the scaffolding. It is generally only intended to get you up and running quickly.
No it is used in other technologies also such as ASP.NET MVC
it creates a basic layout from some predefined code which programmers uses in almost every project , Eg: for database data access it can make a crud method for create, read, update, delete operations
OR you might use it to create layout for your View/Html Code
Scaffolding is writing any piece of code that would not be part of the business logic but would help in unit testing and integration testing.
This is a software engineering term and not bound to any framework or programming language.
No, scaffolding is not the term for the specific platform, however many know this term in the context of Ruby on Rails or .NET
There are also plenty of tools that perform javascript scaffolding:
divjoy.com
flatlogic.com
scaffoldhub.com
yeoman.io
Those tools are also known as code-generators
Scaffolding is the term used when you don't want to create all parts of the structure such as models, views, etc. and want to generate them all in one go. A lot of frameworks use this technique, I studied about it while doing odoo but most of the references given were to ruby on rails :)
Is there a general procedure for programming extensibility capability into your code?
I am wondering what the general procedure is for adding extension-type capability to a system you are writing so that functionality can be extended through some kind of plugin API rather than having to modify the core code of a system.
Do such things tend to be dependent on the language the system was written in, or is there a general method for allowing for this?
I've used event-based APIs for plugins in the past. You can insert hooks for plugins by dispatching events and providing access to the application state.
For example, if you were writing a blogging application, you might want to raise an event just before a new post is saved to the database, and provide the post HTML to the plugin to alter as needed.
This is generally something that you'll have to expose yourself, so yes, it will be dependent on the language your system is written in (though often it's possible to write wrappers for other languages as well).
If, for example, you had a program written in C, for Windows, plugins would be written for your program as DLLs. At runtime, you would manually load these DLLs, and expose some interface to them. For example, the DLLs might expose a gimme_the_interface() function which could accept a structure filled with function pointers. These function pointers would allow the DLL to make calls, register callbacks, etc.
If you were in C++, you would use the DLL system, except you would probably pass an object pointer instead of a struct, and the object would implement an interface which provided functionality (accomplishing the same thing as the struct, but less ugly). For Java, you would load class files on-demand instead of DLLs, but the basic idea would be the same.
In all cases, you'll need to define a standard interface between your code and the plugins, so that you can initialize the plugins, and so the plugins can interact with you.
P.S. If you'd like to see a good example of a C++ plugin system, check out the foobar2000 SDK. I haven't used it in quite a while, but it used to be really well done. I assume it still is.
I'm tempted to point you to the Design Patterns book for this generic question :p
Seriously, I think the answer is no. You can't write extensible code by default, it will be both hard to write/extend and awfully inefficient (Mozilla started with the idea of being very extensible, used XPCOM everywhere, and now they realized it was a mistake and started to remove it where it doesn't make sense).
what makes sense to do is to identify the pieces of your system that can be meaningfully extended and support a proper API for these cases (e.g. language support plug-ins in an editor). You'd use the relevant patterns, but the specific implementation depends on your platform/language choice.
IMO, it also helps to use a dynamic language - makes it possible to tweak the core code at run time (when absolutely necessary). I appreciated that Mozilla's extensibility works that way when writing Firefox extensions.
I think there are two aspects to your question:
The design of the system to be extendable (the design patterns, inversion of control and other architectural aspects) (http://www.martinfowler.com/articles/injection.html). And, at least to me, yes these patterns/techniques are platform/language independent and can be seen as a "general procedure".
Now, their implementation is language and platform dependend (for example in C/C++ you have the dynamic library stuff, etc.)
Several 'frameworks' have been developed to give you a programming environment that provides you pluggability/extensibility but as some other people mention, don't get too crazy making everything pluggable.
In the Java world a good specification to look is OSGi (http://en.wikipedia.org/wiki/OSGi) with several implementations the best one IMHO being Equinox (http://www.eclipse.org/equinox/)
Find out what minimum requrements you want to put on a plugin writer. Then make one or more Interfaces that the writer must implement for your code to know when and where to execute the code.
Make an API the writer can use to access some of the functionality in your code.
You could also make a base class the writer must inherit. This will make wiring up the API easier. Then use some kind of reflection to scan a directory, and load the classes you find that matches your requirements.
Some people also make a scripting language for their system, or implements an interpreter for a subset of an existing language. This is also a possible route to go.
Bottom line is: When you get the code to load, only your imagination should be able to stop you.
Good luck.
If you are using a compiled language such as C or C++, it may be a good idea to look at plugin support via scripting languages. Both Python and Lua are excellent languages that are used to script a large number of applications (Civ4 and blender use Python, Supreme Commander uses Lua, etc).
If you are using C++, check out the boost python library. Otherwise, python ships with headers that can be used in C, and does a fairly good job documenting the C/python API. The documentation seemed less complete for Lua, but I may not have been looking hard enough. Either way, you can offer a fairly solid scripting platform without a terrible amount of work. It still isn't trivial, but it provides you with a very good base to work from.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 months ago.
Improve this question
What is the difference between a framework and a library?
I always thought of a library as a set of objects and functions that focuses on solving a particular problem or a specific area of application development (i.e. database access); and a framework on the other hand as a collection of libraries centered on a particular methodology (i.e. MVC) and which covers all areas of application development.
A library performs specific, well-defined operations.
A framework is a skeleton where the application defines the "meat" of the operation by filling out the skeleton. The skeleton still has code to link up the parts but the most important work is done by the application.
Examples of libraries: Network protocols, compression, image manipulation, string utilities, regular expression evaluation, math. Operations are self-contained.
Examples of frameworks: Web application system, Plug-in manager, GUI system. The framework defines the concept but the application defines the fundamental functionality that end-users care about.
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.
I think that the main difference is that frameworks follow the "Hollywood principle", i.e. "don't call us, we'll call you."
According to Martin Fowler:
A library is essentially a set of
functions that you can call, these
days usually organized into classes.
Each call does some work and returns
control to the client.
A framework embodies some abstract
design, with more behavior built in.
In order to use it you need to insert
your behavior into various places in
the framework either by subclassing or
by plugging in your own classes. The
framework's code then calls your code
at these points.
Library:
It is just a collection of routines (functional programming) or class definitions(object oriented programming). The reason behind is simply code reuse, i.e. get the code that has already been written by other developers. The classes or routines normally define specific operations in a domain specific area. For example, there are some libraries of mathematics which can let developer just call the function without redo the implementation of how an algorithm works.
Framework:
In framework, all the control flow is already there, and there are a bunch of predefined white spots that we should fill out with our code. A framework is normally more complex. It defines a skeleton where the application defines its own features to fill out the skeleton. In this way, your code will be called by the framework when appropriately. The benefit is that developers do not need to worry about if a design is good or not, but just about implementing domain specific functions.
Library,Framework and your Code image representation:
KeyDifference:
The key difference between a library and a framework is “Inversion of Control”. When you call a method from a library, you are in control. But with a framework, the control is inverted: the framework calls you. Source.
Relation:
Both of them defined API, which is used for programmers to use. To put those together, we can think of a library as a certain function of an application, a framework as the skeleton of the application, and an API is connector to put those together. A typical development process normally starts with a framework, and fill out functions defined in libraries through API.
As I've always described it:
A Library is a tool.
A Framework is a way of life.
A library you can use whatever tiny part helps you. A Framework you must commit your entire project to.
From Web developer perspective:
Library can be easily replaceable by another library. But framework cannot.
If you don't like jquery date picker library, you can replace with other date picker such as bootstrap date picker or pickadate.
If you don't like AngularJS on which you built your product, you cannot just replace with any other frameworks. You have to rewrite your entire code base.
Mostly library takes very less learning curve compared to Frameworks. Eg: underscore.js is a library, Ember.js is a framework.
I like Cohens answer, but a more technical definition is: Your code calls a library. A framework calls your code. For example a GUI framework calls your code through event-handlers. A web framework calls your code through some request-response model.
This is also called inversion of control - suddenly the framework decides when and how to execute you code rather than the other way around as with libraries. This means that a framework also have a much larger impact on how you have to structure your code.
I forget where I saw this definition, but I think it's pretty nice.
A library is a module that you call from your code, and a framework is a module which calls your code.
A framework can be made out of different libraries. Let's take an example.
Let's say you want to cook a fish curry. Then you need ingredients like oil, spices and other utilities. You also need fish which is your base to prepare your dish on (This is data of your application). all ingredients together called a framework. Now you gonna use them one by one or in combination to make your fish curry which is your final product. Compare that with a web framework which is made out of underscore.js, bootstrap.css, bootstrap.js, fontawesome, AngularJS etc. For an example, Twitter Bootstrap v.35.
Now, if you consider only one ingredient, like say oil. You can't use any oil you want because then it will ruin your fish (data). You can only use Olive Oil. Compare that with underscore.js. Now what brand of oil you want to use is up to you. Some dish was made with American Olive Oil (underscore.js) or Indian Olive Oil (lodash.js). This will only change the taste of your application. Since they serve almost the same purpose, their use depends on the developer's preference and they are easily replaceable.
Framework: A collection of libraries that provide unique properties and behavior to your application. (All ingredients)
Library: A well-defined set of instructions that provide unique properties and behavior to your data. (Oil on Fish)
Plugin : A utility build for a library (ui-router -> AngularJS) or many libraries in combination (date-picker -> bootstrap.css + jQuery) without which your plugin might now work as expected.
P.S. AngularJS is an MVC framework but a JavaScript library. Because I believe Library extends default behavior of native technology (JavaScript in this case).
This is how I think of it (and have seen rationalized by others):
A library is something contained within your code. And a framework is a container for your application.
I will try to explain like you're five. ( No programming term was being used. )
Let's imagine that you had opened a burger restaurant in your city a while ago. But you feel it's so hard to make a burger as a beginner. You were thinking about an easy way to make burgers for customers.
Someone told you that If you use framework, you can make bugger easily. and you got to know that there are McDonald Burger Framework and BurgerKing Burger Framework.
If you use McDonald Burger Framework, It's so easy to make Big Mac burger. (but you cannot make Whopper.)
If you use BurgerKing Burger Framework, It's so easy to make Whopper Burger. (however, you cannot make Big Mac)
Anyway, In the end, they are all burgers. An important thing here is, you have to follow their framework's rule to make burgers. otherwise, you feel even harder to make it or won't be able to make it.
And you also heard that there is something called Simple Burger-Patty Library.
If you use this Library, you can make whatever burger patty so easily (X2 speed).
It doesn't really matter if you use McDonald Burger Framework or BurgerKing Burger Framework.
Either way, you can still use this Simple Burger-Patty Library. (Even you can use this Library without frameworks.)
Do you see the difference between Framework vs Library now?
Once you started using McDonald Burger Framework. It would not be easy to switch to BurgerKing Burger Framework. Since you have to change the whole kitchen.
If you start to build Web Application using Java Spring Framework, It would be hard(maybe impossible) to change to Ruby on Rails Framework later.
But Library, It would be much easier to switch others. or you can just not to use it.
A library implements functionality for a narrowly-scoped purpose whereas a framework tends to be a collection of libraries providing support for a wider range of features. For example, the library System.Drawing.dll handles drawing functionality, but is only one part of the overall .NET framework.
Libraries are for ease of use and efficiency.You can say for example that Zend library helps us accomplish different tasks with its well defined classes and functions.While a framework is something that usually forces a certain way of implementing a solution, like MVC(Model-view-controller)(reference). It is a well-defined system for the distribution of tasks like in MVC.Model contains database side,Views are for UI Interface, and controllers are for Business logic.
I think library is a set of utilities to reach a goal (for example, sockets, cryptography, etc).
Framework is library + RUNTIME ENVIRONMENT. For example, ASP.NET is a framework: it accepts HTTP requests, create page object, invoke life cycle events, etc. Framework does all this, you write a bit of code which will be run at a specific time of the life cycle of current request!
Your interpretation sounds pretty good to me... A library could be anything that's compiled and self-contained for re-use in other code, there's literally no restriction on its content.
A framework on the other hand is expected to have a range of facilities for use in some specific arena of application development, just like your example, MVC.
I think you pinned down quite well the difference: the framework provides a frame in which we do our work... Somehow, it is more "constraining" than a simple library.
The framework is also supposed to add consistency to a set of libraries.
Library - Any set of classes or components that can be used as the client deems fit to accomplish a certain task.
Framework - mandates certain guidelines for you to "plug-in" into something bigger than you. You merely provide the pieces specific to your application/requirements in a published-required manner, so that 'the framwework can make your life easy'
I don´t remember the source of this answer (I guess I found it in a .ppt in the internet), but the answer is quite simple.
A Library and a Framework are a set of classes, modules and/or code (depending of the programing language) that can be used in your applications and helps you to solve an especific "problem".
That problem can be log or debuging info in an application, draw charts, create an specific file format (html, pdf, xls), connect to a data base, create a part of an application or a complete application or a code applied to a Design Pattern.
You can have a Framework or a Library to solve all these problems and many more, normaly the frameworks helps you to solve more complex or bigger problems, but that a consecuence of their main difference, not a main definition for both.
The main difference betwen a Library and a Framework is the dependency betwen their own code, in oder words to use a Framework you
need to use almost all the classes, modules or code in the FW, but to
use a Library you can use one or few classes, modules or code in the
lib in your own application
This means that if a Framework has, for example has 50 classes in order to use the framework in an app you need to use, let said, 10-15 or more classes in your code, because that is how is designed a Framework, some classes (objects of that classes) are inputs/parameters for methods in other classes in the framework. See the .NET framework, Spring, or any MVC framework.
But for example a log library, you can just use a Log class in your code, and helps you to solve the "logging problem", that doesn´t mean that the log library doesn't have more classes in his code, like classes to handle files, handle screen outputs, or even data bases, but you never touch/use that classes in your code, and that is the reason of why is a library and not a framework.
And also there are more categories than Frameworks and Libraries, but that is off topic.
What is a Library?
A library is a collection of code blocks (could be in the form of variables, functions, classes, interfaces etc.) that are built by developers to ease the process of software development for other developers that find its relevance.
What is a Framework?
With reference to the definition of a library, we could define a framework as a tool that helps a developer solve a large range of domain-specific problems by providing the developer with necessary libraries in a controlled development environment.
Based on the definitions given in the book Design Patterns by Erich Gamma et al.:
library: a set of related procedures and classes making up a reusable implementation;
framework: a set of cooperating classes with template methods making up a reusable specification. It sets the control flow and allows to hook into that flow for tailoring the framework to a specific problem by overriding in a subclass the hook methods called by the template methods in the framework classes.
Problem-specific code can use libraries and implement frameworks.
Library vs Framework
Martin Fowler - InversionOfControl
Library and Framework are external code towards yours code. It can be file(e.g. .jar), system code(part of OS) etc.
Library is a set of helpful code. Main focus is on your code. Library solves a narrow range of tasks. For example - utilities, sort, modularisation
your code ->(has) Library API
Framework or Inversion of Control(IoC) container[About] is something more. Framework solves a wide range of tasks(domain specific), you delegates this task to framework. IoC - your code depends on framework logic, events... As a result framework calls your code. It forces your code to stick to it's rules(implement/extend protocol/interface/contract), pass lambdas... For example - Tests, GUI, DI frameworks...
your code ->(has) and ->(implements) Framework API
[iOS Library vs Framework]
[DIP vs DI vs IoC]
Really it depends on what definition you give to the terminology. There's probably a lot of different definitions out there.
I think the following are nice explanations based on what I believe this terminology refers to:
Deterministic Library
A deterministic library holds functions that are deterministic based on either a) function input or b) state that is somehow maintained across function calls.
Should logic be dependency-injected into a deterministic library, such logic must conform to a concrete specification such that the output of the library is not affected.
Example: A collision-detection library which for some reason depends on a sorting function to aid in these calculations. This sorting function can be configured for optimization purposes (e.g. through dependency-injection, compile-time linkage, etc), but must always conform to the same input/output mapping, so that the library itself remains deterministic.
Indeterministic Library
An indeterministic library can hold indeterministic functions by communicating with other external indeterministic libraries that it somehow gained access to.
I generally refer to indeterministic libraries as services.
Example: A poker library which depends on a random-number generator service for shuffling the deck. This is probably a bad example, because, for architectural purposes, we should push the indeterministic aspect of this library to the outside. The poker library could instead become deterministic and unit-testable by taking in a pre-shuffled deck of cards, and it's now the responsibility of the user of this library to shuffle the deck randomly if they so wish.
Framework
A framework is in-between a deterministic and indeterministic library.
Any logic that is dependency-injected into a framework must be deterministic for the lifetime of that function instance, but different function instances of varying logic can be injected on separate executions of framework functions.
Example: Functions that operate on lists such as map, filter, sort, reduce, that expect to take in functions that are deterministic but can have varying logic for different executions. Note that this requirement only exists if these list operations advertise themselves as deterministic. In most languages, list operations wouldn't have this constraint. The core logic of such frameworks are deterministic, but are allowed to accept indeterministic logic at the risk of the user. This is generally a messy scenario to deal with, because output can vary widely due to implementation details of the framework.