I know this would seem to be something blasphemic and it (may) break the singleton nature so, please, don't hurt me! I'm just asking.
Assuming that the example below is just a random situation (and actually MY SITUATION, coincidence? I don't think so...) my question is generic.
I've got a singleton class like this:
public class SingleSessionFactory {
private SingleSessionFactory() {
}
private static class SingleSessionHelper {
private static final SessionFactory SESSION_FACTORY = getSingleSession();
private static SessionFactory getSingleSession() {
if (SESSION_FACTORY == null) {
Configuration hConf = new Configuration();
//hibernate configuration I wish to set by an object or sth dynamic not hard-coded!
try {
return hConf.buildSessionFactory();
} catch (ExceptionInInitializerError ex) {
System.out.println(ex.getMessage());
}
}
return SESSION_FACTORY;
}
}
public static SessionFactory getInstance() {
return SingleSessionHelper.SESSION_FACTORY;
}
}
which instead of the line //hibernate config...bla bla bla & bla... i used to call the setProperty(..) and addAnnotatedClass(..) hard-coded.
I wish to know if it's good to use a custom property object (by instance: MyHibernateConfiguration class) to use inside my getSingleSession(), which inside some attribute to store Hibernate properties (as "hibernate.dialect", "org.hibernate.dialect.PostgreSQLDialect") and annotated class. Injecting or passing or...whatever... in this way "all that things" could be passed dynamically and that would be veeeeeryveryvery cool, isn't it right?
Anyway:
Q: Is it possible?
A1: Yeah of course! And the bestt way to do that is...
A2: NO! This is madness! I'm gonna underrate this question and send you to hell! Muha-ha-ha-haaaa... (yeah, evil laugh...)
That's all folk!
Related
Using static-method makes code more clean.
So I wanna use static-method even used with #Service, #Repository class in it.
You can more easily understand by code. Very short one and It works!!
But I want to know it is okay to use in any situation.
I didn't see like that code before, so I am afraid it is the effective code to use. If you have any idea about that, could you advise me, please?
#Repository
public class TruckRepository {
public Integer selectWheelCount() {
//which is searching truck database to get some data about trucks.
//Such as how many wheels does the truck have, something like that.
}
}
#Component
public class CarFactory {
private static TruckRepository truckRepository;
//#Autowired << can be omitted after spring 4.3 as I know
NewsSourceFactory(TruckRepository truckRepository) {
this.truckRepository = truckRepository;
}
public static Integer getWheelCount(String carType) {
swtich(carType) {
case TRUCK:
return truckRepository.selectWheelCount();
}
}
}
#Component
public class SomeCode {
public void something() {
Integer count = CarFactory.getWheelCount("TRUCK");
}
}
Add Comments
I very empressive the code of "Duration.class", "Stream.class" in java.
They are also using static-method, Of course they have no dynamic injection in there.
Just in case of thinking about the concise of code or clearness, isn't it the merit of static-method, dont you think? is it really harmless?
You are using static method which uses static field which is initialized in constructor. In this code it's not even clear when Spring will create a new instance of CarFactory (maybe it won't at all, if none is referencing it). And if no instance of CarFactory created, your static method is broken too, because static field is not initialized.
I don't see any benefits of using static methods in your case, after all you can always inject instance of CarFactory into SomeCode.
Simple as:
#Autowired
private CarFactory cartFactory;
Or better:
private CarFactory cartFactory;
public SomeCode(#Autowired CarFactory pCartFactory) {
cartFactory = pCartFactory;
}
I want to return multiple spring beans based on the condition in the factory class.
Is this a good practice?
Any better ways to write the following piece of code?.
Any other design patterns suitable here?
Below is the code snippet:
package com.test;
import org.springframework.stereotype.Component;
import javax.annotation.Resource;
#Component
public class InstanceFactory {
#Resource(name = "instance1")
private Instance instance1;
#Resource(name = "instance2")
private Instance instance2;
public Instance getService(Condition condition) {
if (condition.one() && condition.two()) {
return instance2;
} else {
return instance1;
}
}
}
It depends on what you want to achieve. Factory Pattern is meant to create objects but what you are returning are objects already create somewhere else (Spring in this case). If you want to create beans that will be managed by Spring there are several ways:
#Conditional(YourConditionImplementation.class): This annotation added on a method of a #Configuration annotated class will allow you to create a bean when the given condition is fullfilled. Example here: https://javapapers.com/spring/spring-conditional-annotation/
You can uses as well BeanFactory to inject the definition of your bean (DefinitionBean) into the container. Example here: https://www.logicbig.com/tutorials/spring-framework/spring-core/bean-definition.html
Now, if you want an object that determine what object of type Instance fits better for some need then your approach is ok, but it is not technically a factory :)
When designing something like that I would face that solution considering two design patterns:
Strategy pattern: In order to replace repetitive if else every time you need to evaluate more instances.
Decorator pattern: Trying to make every condition as configurable as possible. They can be composed (decorated) for one or more predicates.
Considering these two pattens you might achieve something like this:
First, define which conditions will identify a given instance:
public enum InstanceType {
INSTANCE_TYPE_1(Condition::isOne, Condition::isTwo),
INSTANCE_TYPE_2(Condition::isOne, Condition::isThree),
...;
private List<Predicate<Condition>> evaluators;
#SafeVarargs
InstanceType(final Predicate<Condition>... evaluators) {
this.evaluators = Arrays.asList(evaluators);
}
public boolean evaluate(final Condition condition) {
return evaluators.stream().allMatch(it -> it.test(condition));
}
}
Then, you should link every instance implementation to an specific instance type:
#Component
public class InstanceOne implements Instance {
#Override
public InstanceType getType() {
return InstanceType.INSTANCE_TYPE_1;
}
}
Finally, a class to config where defining the relation between types and instances as EnumMap
#Configuration
public class InstanceFactoryConfig {
#Autowired
private List<Instance> instances;
#Bean
public EnumMap<InstanceType, Instance> instancesMap() {
EnumMap<InstanceType, Instance> instanceEnumMap = new EnumMap<>(InstanceType.class);
instances.forEach(i -> instanceEnumMap.put(i.getType(), i));
return instanceEnumMap;
}
}
Thus, you InstanceFactory can be replaced to something like this:
public class InstanceFactory {
#Autowire
private final EnumMap<InstanceType, Instance> instancesMap;
public void getInstance(Condition condition) {
instancesMap.get(getInstanceType(condition)).doSomething();
}
private InstanceType getInstanceType(Condition condition) {
return Arrays.stream(InstancesType.values())
.filter(evaluator -> evaluator.evaluate(condition))
.findFirst().orElseThrow(() -> new RuntimeException("Instance type not found"));
}
}
As you can see, you InstanceFactory is less prone to be modified. This means, every time you need you add a new instance implementation you only need to modify the InstanceType enum. Hope this is helps.
You can use spring existing FactoryBean interface and implement your own logic
It’s one of the best approaches to create beans in spring framework
Here is the link with example :
https://www.baeldung.com/spring-factorybean
See:
Spring Profile
The active profile is set by properties and based on the value you assign to the profile, Spring will load different beans for the same interface.
So it might be exactly what you need.
I use hibernate to handle the connection to the DB. I have several Session Factories that connect to different schemas.
Building all SessionFactory on startup takes at least 60 seconds. So I only have them be built when necessary:
public class HibernateUtil {
private static SessionFactory factory_db1;
private static SessionFactory factory_db2;
//...
public enum DbSchema {
db1, db2 //...
}
private createSessionFactory(Configuration conf){
//...
}
public static SessionFactory getFactory(DbSchema dbSchema) {
try {
switch (dbSchema) {
case db1:
if (factory_db1== null){
Configuration conf = new Configuration().configure(HIBERNATE_CFG_DB1);
factory_db1= createSessionFactory(conf);
}
return factory_db1;
case db2:
if (factory_db2 == null){
Configuration conf = new Configuration().configure(HIBERNATE_CFGXML_DB2);
factory_ooarchive = createSessionFactory(conf);
}
return factory_ooarchive;
//... more factories created
default:
assert false : "Switch default should not be reachable.";
return null;
}
} catch (Throwable ex) {
log.error("Failed to initialize SessionFactory." + ex);
throw new ExceptionInInitializerError(ex);
}
}
Now when I access this factory:
Session session = HibernateUtil.getFactory(db1).openSession();
// **Compiler warning: method invocation may produce java.lang.nullpointerexception**
Getting the factory is only possible through the getFactory() method therefore I would think a NPE is never possible. I understand that the problem is the static keyword for the factory instance variable and that there is no initilization in the contructor. I do not want this "always-on" initilization! It should only be initialized when needed at least once.
I read a few design pattern and code quality books but I struggle to implement what I learned. I think I created a code smell. How do I fix this design? Please explain my mistakes and why my choices are questionable.
I am not sure that the compiler warning (probably issued by an IDE and not javac) be related to the static modifier of getFactory().
Actually getFactory() implementation declares a switch statement that has a default case that returns null :
default:
assert false : "Switch default should not be reachable.";
return null;
So getFactory() may indeed return null if the passed parameter doesn't allow to enter in one of the previous cases.
But I think that the main issue of getFactory() is its lack of thread safety. Indeed, if multiple threads access it concurrently, you could create multiple sessions and maybe generate an inconsistent state.
As alternative, to create the sessions on demand, you could use a specific flavor of the singleton pattern : the initialization-on-demand holder idiom :
In software engineering, the initialization-on-demand holder (design
pattern) idiom is a lazy-loaded singleton. In all versions of Java,
the idiom enables a safe, highly concurrent lazy initialization with
good performance.
I got a class Config wich looks like that:
public Class Config {
public static int someIntValue = 0;
public static String someText = "some text";
}
What i want to do now is saving and loading that config and there is also that inital config if there is no need to load another. So the config can change at any point in the programm.
What i came up with was a Singelton like pattern
public Class Config {
public static Config instance;
private int someIntValue = 0;
private int String someText = "some text";
public static Config getInstance(){
if(instance == null)
instance = new Config();
return instance;
}
public void setInstance(Config config){
this.instance = config;
}
//getter/setter
...
}
But in the end it doesnt look like the best approach and im not quite happy with it :/
Maybe you guys can help me out with a usual / "best practice" way to do that.
Best Regards
Made
I would just use java.util.Properties, or some wrapper around it. Another good approach is java bean and something like xstream to save/load stuff.
Usually in Java for configuration use properties files. And then use ResuorseBundle for reading properties.
Your "singleton" is not a Singleton in the conventional sense.
1) Field instance must be private
2) Remove SetInstance method
3) And you should make your singleton thread safe.
If you'd consider avoiding writing the boilerplate code around java.util.Properties, you can have a look at something that does it for you: OWNER API.
It's configurable to tailor your needs and it offers some additional neat features if compared to java.util.Properties (read the docs).
Example. You define an interface with your configuration parameters:
public interface ServerConfig extends Config {
int port();
String hostname();
#DefaultValue("42")
int maxThreads();
#DefaultValue("1.0")
String version();
}
Then you use it like this:
public class MyApp {
private static ServerConfig cfg = ConfigFactory.create(ServerConfig.class);
private MainWindow window;
public MyApp() {
// you can pass the cfg object as dependency, example:
window = new MainWindow(cfg);
}
public void start() {
window.show();
}
public static void main(String[] args) {
// you can use it directly, example:
System.out.println("MyApp version " + cfg.version() + " copyright (c) ACME corp.");
MyApp app = new MyApp();
app.start();
}
}
You can define the cfg object as member instance on the classes where you need, or you can pass the instance to constructors and methods where you need it.
Version 1.0.4 will be released soon and it will include also "hot reload" and many improvements.
I chose to take properties file for customization of some settings.
I use the following code to make a Properties Object available in a class
Properties defaultProps = new Properties();
try {
FileInputStream in = new FileInputStream("custom.properties");
defaultProps.load(in);
in.close();
} catch (Exception e) {
e.printStackTrace();
}
Do I have to add this to every class? Probably not because then every class would open a stream to this file.
But I'm not sure how to handle this properly.
Should I make a class MyProperties and instantiate it in whatever class needs properties?
Thanks in advance!
Once you initialized defaultProps, you can make its contents available to other objects in your app e.g. via a public static accessor method, e.g.:
public class Config {
private static Properties defaultProps = new Properties();
static {
try {
FileInputStream in = new FileInputStream("custom.properties");
defaultProps.load(in);
in.close();
} catch (Exception e) {
e.printStackTrace();
}
}
public static String getProperty(String key) {
return defaultProps.getProperty(key);
}
}
This is the simplest approach, however it creates an extra dependency which makes unit testing harder (unless you provide a method in Config to set a mock property object for unit testing).
An alternative is to inject defaultProps (or individual configuration values from it) into each object which needs it. However, this may mean you need to add extra parameter(s) to lots of methods if your call hierarchies are deep.
If you only need one instance of your properties class you can use the singleton (anti?)-pattern.
It would look like a class like this:
public class MyProperties extends Properties {
private static MyProperties instance = null;
private MyProperties() {
}
public static MyProperties getInstance() {
if (instance == null) {
try {
instance = new MyProperties();
FileInputStream in = new FileInputStream("custom.properties");
instance.load(in);
in.close();
} catch (Exception e) {
e.printStackTrace();
return null;
}
}
return instance;
}
}
Why not use a static ResourceBundle ?
static final ResourceBundle myResources =
ResourceBundle.getBundle("MyResources", currentLocale);
There's too little information to determine what the best way to handle this would be. You may want to expose it using an accessor, or pass it into each class that requires it. Alternatively, you may pull out the properties that each class needs and pass their values into the class's constructor.
Load the properties once using and store the Properties somewheres that others classes can pull from. If that is a MyProperties class that references a static variable somewhere that is fine.
This is a special case of making anything available globally. Using static methods is quite bad. A better but bad solution is using the sigleton pattern. Testing is the greatest problem here. IMHO, the best way is using Dependency injection, although it may be an overkill for small applications.
Since this information is static across all instances, I recommend implementing the Properties class as a singleton. By using the static initialization block method, you can have it load the file automatically when the program starts up.
public class Properties {
static {
try {
FileInputStream in = new FileInputStream("custom.properties");
load(in);
in.close();
} catch (Exception e) {
e.printStackTrace();
}
}
protected static void load(FileInputStream in) {
// existing load functionality here
}
}
You are still going to need an internal storage mechanism and accessor mechanism. These should also be marked static.
Rather than loading properties in every class. Load it somewhere around main() and pass it to other classes via their constructors.
Don't share them globally.
- Difficult to test
- Against the abstraction (Global access, DAO can access user settings. it should be prevented by passing only what it needs.. not everything)
- Classes lie what they need