I'm doing a project that has a couple of packages. All my classes are implemented according to Dependency Injection ideias.
Now, there will be some place, in my application, that'll have the responsability of instantiating all the objects (actually I'm using an IoC Container for that, but that shouldn't matter) -- the so called Composition Root.
Now, the problem lies in the fact that, at least to my understanding, the composition root will have to know all the classes that'll be used of the system. That is, all the classes will have to be marked as public.
I could define for each package a Package Composition Root and then call each one of them from the system's composition Root but that doesn't seem that great of an idea.
In C#, for example, the situation is not so grave as there is not the package-protected access modifier -- there's internal (accessible for all the elements of the current assembly), instead.
How do you guys generally handle this?
Most containers get around access restrictions by using reflection. However this is just a hack to make you feel like you have some protection when actually relfection allows you to ignore the access modifiers.
IMHO, if you are accessing a class in another package you should be clear about this and give it an appropriate access modifier.
It sounds to me like the situation is the same in C#. If the bean factory is outside of a package, and the developer makes a class internal, does that not deny access to the bean factory?
I make the classes public and don't worry so much about it.
The interfaces that clients should be using are public by definition. Since they don't instantiate or use the implementations directly, there's little fear of giving them public access.
An alternative might be to create a factory method and make it available to the bean factory. Let it choose which implementation to provide for a given implementation using the public factory.
Now, the problem lies in the fact that, at least to my understanding, the composition root will have to know all the classes that'll be used of the system. That is, all the classes will have to be marked as public.
...
How do you guys generally handle this?
By marking all of the classes as public. This isn't really seen as a problem in the Java world.
This is an old question but I think is very important to still talk about that. While other guys try to say there is no problem with making classes of packages public to be accessible for composition, I disagree completely. The most import feature of a package is to hide details from the others using access modifiers. You can argue about the details word and say the main class of a package that provides its main features is not details of the package. I will answer when you use polymorphic interfaces to isolate your package from outside world, that main class is also part of details. Restricting access to that main class is useful when you want to protect your software architecture from being violated by the other developers in you team by the aid of language features at compile time. If you do not have such a feature in Python, I feel sorry for you but it doesn't mean there is no need to use such a great feature in Java, C#, etc.
Suppose you have a package that communicate with the outside world using a polymorphic interface and all of its internal types are access-restricted. So how the main class that implements that interface can be initialized in the composition phase while composition operation is happening out of all packages? This is the main question.
As Devoured also mentioned himself, there is no way except defining a public composer in each package that instantiates and composes all internal types and finally returns an object of the type of the polymorphic interface that isolates this module from the outside world.
Related
I'm trying to do something clever. I am creating a weather application in which we can replace the weather API with another weather API without affecting the code base. So I started with a Maven project with multiple modules.
I have a Base module that contains the Interface class and the Base class. The Interface class contains the calls to the APIs (all calls are similar, if not exact) and the Base class contains the properties to the APIs (again, all properties are similar, if not exact).
I have a module for each of the two weather APIs we are testing with plans to create more modules for new weather APIs as we grow the application.
Finally, I have created a Core module (includes main) to implement the specific module class for the weather API I want to test.
Now, I know the simplest way to do this would be to use a switch statement and enumeration. But I want to know if there is a more clever way to do this. Maybe using a Pattern? Any suggestions?
Here is a picture of the structure I have just described:
Here is the UML representation:
This is a learning process for me. I want to discover how a real Java Guru would implement the appropriate module and class based on a specified configuration.
Thank you for your suggestions.
I'm trying to do something clever. I am creating a weather application
in which we can replace the weather API with another weather API
without affecting the code base.
Without reading further down, this first statement makes me think about a plugin architecture design, but in the process of software design, decisions must not be rushed, the more you delay, the more information you have and a better informed decision can be made, for now is just an idea to keep in mind.
I have a Base module that contains the Interface class and the Base
class. The Interface class contains the calls to the APIs (all calls
are similar, if not exact) and the Base class contains the properties
to the APIs (again, all properties are similar, if not exact).
When different modules share behaviour/state, it is a good idea to refactor them and produce base abstract classes and interfaces, so you are on the right track, but, if there are differences, those shouldn't be refactored into the base module. The reason behind that is simple, maintainability. If you start adding if clauses or switches to deal with these differences, you just introduced coupling between modules, and you'll be always having to make changes in the base module, whenever you add/modify other modules, and this is not desirable at all.
This is reflected by the Open/Closed principle form the SOLID principles, which states that a class should be open for extension but closed for modifications.
So after you've refactored the common behaviour into the base modules, then each new API should extend the base module, as you did.
Finally, I have created a Core module (includes main) to implement the
specific module class for the weather API I want to test.
Now, I know the simplest way to do this would be to use a switch
statement and enumeration. But I want to know if there is a more
clever way to do this. Maybe using a Pattern? Any suggestions?
Indeed, making use of a switch, makes it work, but its not a clean design at all, for the same reason as before, when adding, modifying or removing modules, would require to modify this module aswell, and also this code can potentially break.
One possible solution, would be to delegate this responsability on a new component and make use of a creational design pattern like the Abstract Factory, which will provide a interface to instantiate components without specifying its classes.
As for the architecture, so far, the plugin architecture still makes sense, but what if the different modules extend the base contract adding more features? One option is to use the Facade pattern to adapt the module calls and provide an output that implements an interface that clients expect.
But then again, with the provided details, this is the solution I'd suggest, but the scenario should be studied carefully and in greater detail, in order to be able to assure that these are the right tools for the job, and commit to them.
In addition to Salvador Juan Martinez's answer...
To implement a plugin architecture Java's Jar File Specification provides support for service provider interfaces (SPI) and how they are looked up.
As of Java 1.6. you can use the ServiceLoader to lookup service providers. For Java 1.5. and less you must do it on your own or use a library. E.g. commons-discovery.
The usage is quiet simple. In your case put a META-INF/services/com.a2i.weatherbase.IWeather file in each plugin module.
In the Weather Forecast IO module the file should contain only one line
com.a2i.weatherforecastio.ForecastIO
The line must be the full quallified name of an IWeather implementation class.
Do the same for the other module and you can load the implementations via ServiceLoader.
ServiceLoader<IWeather> weatherServicesLoader = ServiceLoader.load(IWeather.class);
Iterator<IWeather> weatherServices = weatherServicesLoader.iterator();
Now it depends on your runtime classpath how many services will be found. Try to add and remove module jar archives from the classpath and run your application.
EDIT
I wrote a blog about a pluggable architecture with standard java. See http://www.link-intersystems.com/blog/2016/01/02/a-plug-in-architecture-implemented-with-java/
Source code is also available at https://github.com/link-intersystems/blog/tree/master/java-plugin-architecture
One solution is you have to define the common interface with all the identified common operations. The extensions/plugins need to implement that interface and have to provide the implementation to common operations.
You can use an abstract factory design pattern to hook up the exact implementation at runtime based on the input parameters.
Interfaces and abstract classes are always good in such scenarios, Thanks.
I am working on an API for a software so my users can extend it without modifying the source code. But, I want only certain functions to be accessed by certain classes for security reasons. Is there anyway to do this? Also, I have no code because I have no idea on how to do this.
Thanks! -Trent
I have two thoughts on this, one is that you can look at how Minecraft Forge created their plugin API.
Another way is to have a limited API between your core code and the actual plugins, but, you need to be careful of the platform. For example, if you write the core application in Java or C#, then I can use Aspect Oriented Programming (AOP) to bypass your security and have my code change the behavior of yours.
If you use functional programming (FP) languages, then you can protect more from this type of approach, if you also are not using languages on these platforms, but they are not perfect.
So, there is a trade-off between power and convenience, so how useful do you want your application to be, and how secure?
One possible solution that may work is if you go with something similar to Minecraft, though I doubt they do this, but, give a stub application to the user. They can extend it with plugins, and the interface functions they can modify are in the stub. When the program starts, the plugins are loaded, and the interface may be modified or extended, but, then the core program is pulled down and put into the stub, and then the actual program runs. The core program can be recompiled and manipulated so method names are changed, so reflection is harder to use, but taking this approach, and doing it well, would be hard.
BTW, I like Alex T's response, I just gave different terms to some of his, such as AOP instead of reflection and immutability is part of FP.
You mention jar, which means you are using something that runs on a JVM, so you may want to read up on AspectJ, as it can significantly alter the behavior of applications. You can have private methods, but I can put code that runs instead of yours, or change the parameters or the return value before or after the method is called.
To protect variables inside of classes, you can make them private, and accessible via getter and setter methods with varying levels of protection. This also applies to classes themselves; if you wanted to prevent the user from being able to instantiate a class, you could mark the class' constructor as protected to allow instantiation only within it's package.
If you wanted to hide the implementation details of a class altogether, you could declare the class as class X instead of public class X, which would hide methods from the API for standard development.
This will quickly get you the behaviour you're after, but there's an aspect of Java called reflection, which allows an executable Java program to analyze and manipulate it's own implementation; in this regard, no field or method is ever completely safe.
You can also safeguard variables by providing access to them via 'immutable' Objects; these are objects designed to forbid the caller from modifying the original source contents.
I'm making an SDK and I'm trying to separate classes to different packages, those classes use some other shared classes. The issue is if I made the shared classes public everyone will be able to see them, not only my classes. What's the right way to make them only accessible by my application?
Example :
Package a
MyClass1
Package b
MyClass2
Package c
public MySharedClass
Because c is public MySharedClass will be able to access it, but the issue is that it will also will be visible to the world, how could I prevent that?
Create a package that is documented as an internal package, not to be used by clients.
There is no way in Java to make a class public only for certain packages: It either is public for everyone or package-private (public only in the declared package).
I think there's a proposal for modules to allow better control in the visibility of classes, but we'll have to wait, at least, for Java 8.
The packages are all "public" in Java, what you can protect is the classes within a package. For limiting the visibility of a class to only a given package, declare it like this (without the public visibility modifier):
class MyClass {
// ...
}
In that way, only the classes in the same package as MyClass will be able to see it.
Non trivial:
The shared classes could be defined by a generally accessible set of interfaces. The actual implementation should be loaded explicitly via a Classloader. After that, simply apply Java Security Management mechanisms to control access to the implementation classes. Anyone can see the interfaces and access to actual implementation will be restricted to your SDK.
(A varient of above is what every web/app server needs to do. How do you think Tomcat prevents you from accessing some other app's "public" classes?)
edit: note above is a runtime mechanism. There are static (post) compile approaches as well. APT for example, could be effective here. Naturally I am not addressing a restructuring of your package (in OP) and only addressing how to secure access to a general approach. But these are a bit 'hacky' -- the runtime mechanism of class loading is canonical and imo strictly more correct.
If the class is shared by classes from two different packages, it could be a good indication that these two classes should be in the same package, along with the shared class, which wouldn't be public and would thus only be usable by classes of the same package.
If it's really not an option, just document the shared class appropriately, to indicate that it's not supposed to be used outside of the SDK internal code, that it's subject to changes in future versions, and make it even clearer by naming the package "internal" or somthing like this.
protected modifier can use,in case of your class will access only in same package. otherwise there is no possibility.
I wonder if Java provides 'friend' (as in C++) access modifier? Someone said we can tread 'friend' as default modifier in Java. Is it true?
The default access modifier in Java allows members to be accessed by any code in the same package.
There is no such keyword (in Java) named as -
“Friendly”
The default access modifier has no keyword, but it is commonly referred to as “friendly.” It means that all the other classes in the current package have access to the friendly member, but to all the classes outside of this package the member appears to be private. Since a compilation unit – a file – can belong only to a single package, all the classes within a single compilation unit are automatically friendly with each other. Thus, friendly elements are also said to have package access .
Friendly access allows you to group related classes together in a package so that they can easily interact with each other. When you put classes together in a package (thus granting mutual access to their friendly members; e.g. making them “friends”) you “own” the code in that package. It makes sense that only code that you own should have friendly access to other code that you own. You could say that friendly access gives a meaning or a reason for grouping classes together in a package. In many languages the way you organize your definitions in files can be willy-nilly, but in Java you’re compelled to organize them in a sensible fashion. In addition, you’ll probably want to exclude classes that shouldn’t have access to the classes being defined in the current package.
There isn't a friendly modifier in Java. In Java it is called package private. And it is the default modifier. It allows members of the same package to access it.
As others have said, there is no friend access, but package based access is available.
However OSGI, and the (hopefully) forthcoming Super Packages attempt to extends this concept to classes in a some higher lever grouping of classes.
I just found something that I never heard of before and I do not agree with (by now). In an (upvoted and not further commented) answer I read "why to mix class and interfaces in the same package"
So I wonder, if there are reasons to separate Interfaces and implementations in Java.
I know that we are not obliged to have all implementations in the package of the interface, but is it (sometimes) wise to have none there?
Regards
Mike
[;-)
I agree with org.life.java - I will have service and underlying service.impl packages, but always in that kind of an arrangement.
I disagree with the wording "bad practice". That's too strong.
The java.util Collections API conflicts with this advice. I would not want to be the one to tell Joshua Bloch that he had done a "bad job".
Reasons for keeping interfaces and implementation in separate packages:
clear code base - It 'looks' better, tidier if we have one package with interfaces and another one with implementations (usually a something.impl namespace). And the code structure shows/reflects that you code against interfaces.
access modifiers - We can use package private access modifiers for some package private API for related interface implementations.
library structure - Maybe one day you decide to create different libraries for API (interfaces) and implementation(s). Then it's pretty good to have interfaces and implementations in different packages. So you can change the build without refactoring your code base.
For OSGi it's almost required to use separate packages AFAIK so you can export/import the API without exporting/importing the implementation.
For interfaces that are only internally however it's not a problem to keep everything in one package.
Its not bad thing but It is certainly good practice to separate interface and implementation in different packages.
for example
com.mycompany.domain.service
com.mycompany.domain.service.impl
Advantages:
Uniform package structure
Some time when you want to process some classes only, you can differentiate it by package