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 7 years ago.
Improve this question
I know that in Java dependency injection makes life better. There are a lot of annotation processor frameworks that map beans to objects and conveniently inject them into a right place.
But I never heard about dependency injection in Python or Ruby, for example. Do this languages have build-in support for it? Or they don't need it? Why?
In short, In Python, dependency injection is less important than it is in Java because of the stateful nature of modules and the role of metaprogramming.
In languages like Java, classes typically define blueprints for objects, which must be instantiated at runtime by whatever imports them. When you import a class, you only get the recipe for the class.
Conversely, in Python importing a module can do a lot more. During an import, you are essentially running a module's code within a namespace - meaning that the module can not only construct singletons referenced by the module itself, but can even perform complex tasks like connecting to databases during execution of the import. When two modules import the same referenced module, the second module inherits Python's evaluated concept of the module from when it was first imported, preserving and changes the first importer may have made. Furthermore, its much less painful to scan for submodules in Python and Ruby than it is in Java, which more frameworks use module placement to indicate function (such as models.py in Django) than you see in Java (which generally favors annotations).
TLDR: modules and classes in Python (and Ruby) are stateful in ways that are painful or impossible to replicate in Java, and the mechanics of the import statement provide most of the interesting parts of dependency injection (although not IoC). It doesn't not-exist, its just not as necessary.
See also: Why is IoC / DI not common in Python?
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed last year.
Improve this question
I've been trying to learn Kotlin but I find it to be a lot easier to learn when I can slowly apply it to things I'm working on in Java. Is it a bad idea to mix Java and Kotlin in production?
I know the overall goal is to use one or the other but is there anything wrong with the latter?
Objectively, we can say that compatibility with Java was one of Kotlin's main objectives, according to the official docs:
Kotlin is 100% interoperable with the Java programming language and major emphasis has been placed on making sure that your existing codebase can interact properly with Kotlin. You can easily call Kotlin code from Java and Java code from Kotlin. This makes adoption much easier and lower-risk. There’s also an automated Java-to-Kotlin converter built into the IDE that simplifies migration of existing code.
Many features are designed specifically to ease calling Java from Kotlin or vice versa: for example, the fact that property accessors are implemented in the same way as normal Java accessor methods, and the ability to implement SAM interfaces; and where Kotlin implements things differently, there are often annotations or other ways to use a Java-style implementation.
And in my own experience, there are no issues with mixing Java and Kotlin classes. Many of our projects have both (new classes written in Kotlin, a few old ones converted but many still in Java), and I'm not aware of any significant problems. I also converted a major project from Java to Kotlin, one class at a time — and after each one, everything still compiled and tested and ran perfectly.
Of course, new projects can be written in Kotlin from the start; but if you already know Java, mixing in some Kotlin is absolutely an option, and may be the easiest approach. You can convert parts to Kotlin piecemeal, when convenient, or leave them in Java long-term; pretty much everything just works, and you benefit from the parts that are in Kotlin. (You might even find that the way you write Java code benefits from knowing Kotlin!)
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 2 years ago.
Improve this question
It seems to me that there are many instances where implementation of a specific class is the same for different projects.
In Java this is true for classes like ArrayList. So there is obviously reason to reusing generic classes across different projects.
Another generic class that would be usefull would then be ArrayMatrix, but since there is no default implementation in Java I made one myself. It's generic, safe and documented.
Is it common practice to create your own implementation in a situation like this?
If not, what's the preffered way?
If it is, what's the best practice way to share the class/code between projects and organize your "library"?
This is the entire point of having libraries. The best way to share them is to put them in an artifact repository; if possible, Central and JCenter, or some company-internal repository if the libraries can't be open-sourced for some reason. Here's the intro to publishing to Central; it's a minor hassle, but I've done it myself, and it's not too difficult.
I would encourage you to make sure that an equivalent to your class isn't already available in something like Guava or Apache Commons.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
What are the options to define the public interface to a library in Java.
For example I often find that things are public because another package in the library needs them (although still with a common base package, e.g. com.stackoverflow.mylib.), so they can't have the package access level, and generally people don't want massive packages (it also seems that people using Spring insist on having the separate controller/service/model/impl/etc. packages, resulting in a single "feature" being forced to span many packages, when say a given service might be a completely internal implementation detail not for external use...).
So the ideal goal is to make the Jar I provided to 3rd parties to make it clear that these things are not to be used, ideally by not having them available at all (not present in the API jar), so that it is not possible for them to use and compile with those internal objects/methods.
Even more ideally for objects there only supposed to obtain from some kind of factory (e.g. a provided Spring Bean), a way to prevent direct instantiation from their code or custom bean (which may leave some future, not yet present property uninitialised after upgrade).
The two formal ways I know of currently are:
In some projects I have worked on, there is an api package (e.g. com.stackoverflow.mylib.api), and the rule is only the contents of this package may be directly accessed by outside users.
In some other projects I have worked on, there have been some custom attributes, e.g. #PublicSDK to mark objects and methods for use by the public (and I think some extra stuff to ensure only things marked as such are in the publicly distributed javadoc and api jar).
The first thing to ask yourself is - do you really need to hide the implementation details?
The reason I say this is that there's going to be an expense involved in doing so, which depending on your circumstances may or may not be worth paying.
For example, if your API is being used by developers outside of your immediate team then it's probably worth the expense; however if it's just to hide the implementation details within you team I think it's overkill.
If the API is for use within your project then a standard where by you try to depend only on abstract types or interfaces is, imho, sufficient (and already the standard).
However, assuming you do need to hide the implementation and expose only the public API, the best way I know to do it is to produce two jars - one containing the public API and another that is the implementation of that API.
If you're using Maven or Gradle to build the project that is using your API you simply declare a compile time dependency on the API jar (artifact) and a runtime dependency on the implementation jar (artifact).
This pattern can be seen throughout the common Java APIs, the latest example being the JSON API that is implemented separately as part of Glassfish.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
How do you decide what a package name should be and what class should go into what package ?
I'm working on a project where I am constantly adding/removing classes and not really sure if I need a new package, or should add it to an existing one that im not currently aware of.
Do you follow a set of rules when creating a new package ?
How do you know if you are not duplicating package functionality ? Is this just down to familiarity with the project.
Any pointers appreciated.
I strongly discourage from organizing packages from an implementational point of view, like controllers, data, etc. I prefer grouping them by functionality, that is, feature1, feature2, etc. If a feature is reasonably complex and requires a large number of classes, then (and only then) I create subpackages like above, that is, feature1.controllers, feature1.data, etc.
Classes should do one thing (Single Responsibility Principle).
Classes that do related things should go in the same package. If you find you can more closely relate some of the classes in a package, make them a subpackage!
For example, if I had a project with these classes:
GreetingInputWindow
GreetingDatabaseObject
GreetingDatabaseConnector
I might just put them all in the greeting package. If I wanted to, I might put GreetingInputWindow in the greeting.ui package, and the other 2 into the greeting.db package.
I don't believe there are any hard and fast rules on packaging convention (though I could be wrong). Normally I break it up into
com.mycompanyname and then:
api
controllers
data (for models)
jobs (for cron jobs)
reporting
servlet
utils
If I find I have a class which does not fit into any of those, then I create a new package.
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 8 years ago.
Improve this question
We're trying to determine how to implement a simple plugin framework for a service we are implementing that allows different types of calculators to be "plugged-in".
After reading a number of posts about Java plugin frameworks, it seems like the most common options are:
OSGI
"Rolling your own" plugin framework
The Java Plugin Framework (JPF)
The Java Simple Plugin Framework (JSPF)
OSGI seems to be more than we need.
"Rolling your own" is ok but it would be nice to reuse a common library.
So we're down to the JPF and JSPF. JPF doesn't seem to be in active development anymore.
JSPF seems very simple and really all we need. However I haven't heard much about it. I've only seen one post on StackOverflow about it. Does anyone else have any experience with JSPF? Or any other comments on this design choice?
Update: There isn't necessarily a correct answer to this.. however we're going to go with Pavol's idea as we need just a really, really simple solution. Thanks EoH for the nice guide.
(Disclaimer: I am the author of JSPF, so better take my comment with a grain of salt ;-)
The main reason I started with the JSPF was because I had the same problem as you have now: I was looking for a simple solution to make my thesis-project 1) extensible and 2) give it a more or less clear code structure.
The reason why I haven't decided to use an existing framework was because most of them were so heavyweight to start with, that I got lost in reading documentation and was almost forgetting my original task. So, according to your statement
We're trying to determine how to
implement a simple plugin framework
for a service we are implementing that
allows different types of calculators
to be "plugged-in".
I'd think that you could give JSPF a shot and see how far you come within one or two hours.
However, the final decision also depends a bit on what exactly you want to achieve, and the specific circumstances.
I have heard positive results from a number of individuals who have been using it to structure their projects or load plugins in their projects. On the other hand, I also know of one person in our department who discarded it again because he didn't feel it was mixing well with his programming style.
So, to answer your question briefly (and surely in a biased way), I would use
OSGi for projects and teams
which are large and have many people working on it
that justify the overhead of setting up the infrastructure
in need of the specific services offered
JPF for projects and teams
of medium size (?, honestly I am not sure about the project / team size they are targeting)
which are in need of more structured facilities to organize their code, like XML configurations, detailed plugin lifecycle management, extensible plugins ...
JSPF for projects and teams
of small size, following an agile paradigm
that just need something that works out of the box, without the need of configurations or setup
willing to sacrifice some features for simplicity
I hope you find the plugin framework most suitable for your scenario. And, no matter what you try, I would be happy to hear about your results.
If you are planning to have just one (or only a few) not very complex 'extension points' than perhaps a well-defined SPI and a piece of configuration might be sufficient. No need to use a plugin framework.
By piece of configuration I mean some mechanism to find your plugins. For example something like META-INF/services/ or simply listing your plugins in a configuration file.
More details (upon request):
SPI = Service Provider Interface, an "implementer-side equivalent of an API". To learn more try searching for a difference between API and SPI. However in this context it is just a fancy term for an interface to be implemented by your plugins (i.e. defines the contract for your plugins).
A nice, short article "Creating a Service Provider Interface" by Ethan Nicholas describes how to create your own SPI in similar way as it is done in several part of the Java Platform itself.
META-INF/services/ can be seen as a more generalized approach to creating SPIs. More information can be found in the respective section of the JAR File Specification.
If you need a really simple solution, try jin-plugin. It is a minimalistic plugin framework for Java and PHP.