We Keep Coding

Any reason to make private methods in a Spring singleton bean static? [closed]

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 4 years ago.
Improve this question
I did some research but didn't find an answer that I am looking for. In Spring, DAO and service classes are declared as interface. Classes implementing interfaces are usually singleton Java beans. Question: do you see any reason that I should make private methods that don’t rely on instance variables static? Why?
For example, I have several private methods in a DAO class converting database data to domain object and these private methods don’t use instance variables. I understand some people might suggest that I should extract them to a utility.

The word singleton is used in multiple ways, which can cause a bit of confusion. A "hard" (physical, class-based, JVM) singleton is a class that ensures that only one instance can exist in the entire JVM, usually through an enum or a constant. This pattern should be avoided if the object has any state or configuration at all, since that can cause unexpected coupling between parts of an application. (It's usually fine if the object represents either a pure function, such as CASE_INSENSITIVE_ORDER, or a value.)
In contrast, a singleton-scoped bean (logical, container-based) simply means that the container that is managing it will keep a single shared instance and supply it to all consumers that want one (instead of, for example, creating a separate private copy for each consumer). In most Spring applications, it's actually preferred for these to implement a Java interface that serves as the contract between the two sides, so the methods can't be static.
As to performance questions, static carries a meaning--specifically, that the method or field doesn't have a relationship to a specific instance of that class. Use it when the meaning is appropriate (such as most of the methods in Math), and don't change the meaning of your code in this way for any theoretical performance reason.

Can Dependency Injection be considered to be a replacement for factory method pattern? [closed]

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 4 years ago.
Improve this question
According to wikipedia
In class-based programming, the factory method pattern is a creational pattern that uses factory methods to deal with the problem of creating objects without having to specify the exact class of the object that will be created.
In dependency injection also(I have experience of spring so this may be in that context), we have Variables for each class defined using interfaces, and leave the concrete instantiation to the DI framework.
Am I missing something in this or can these be used interchangeably?

Can Dependency Injection be considered to be a replacement for factory
method pattern?
Yes but Dependency Injection goes even beyond.
So, you should consider it rather as an improvement in terms of design.
It is right that the two ways provide very close facilities.
But note also that the Dependency injection principle has something that differs really from a raw factory pattern : the dependency inversion principle.
I like very much the Hollywood metaphor to illustrate that : “don't call us, we'll call you".
It is essential as it relieves the client classes to lookup its dependencies : the framework does/("call" to take back the metaphor) it for you.
As a consequence, clients don't have any longer a coupling with factory structures (and the boiler plate code associated to) and just need to define their dependencies and these will be injected.

Naming issue: what name would you give to this interface? [closed]

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 7 years ago.
Improve this question
I'm struggling with a naming issue. What name would you give to an interface that have just one method with this signature:
public interface ?
{
boolean isAvailable();
}
Many classes in my application can implement this interface.

Not that it really matters, you can rename it any time afterwards, and with current IDEs, it is really easy to type any name using autocomplete...
That said, if you want it short, use Available, if you want it more self-explanatory, use CanBeAvailable.

Given that the word "available" already ends with "-able", I think it's okay to break with the Java interface naming convention and call it Availability. Another approach, suggested in Programmers, is to use the prefix "Can-", in which case you can call your interface CanBeAvailable.

The below are the standards defined for Naming conventions.
Class - Always be a Noun
Interface - Always be an Adjective
Method - should be a verb
So, think of some adjective which describes the purpose of your interface.

Factory pattern not following OPEN CLOSE Principle [closed]

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 9 years ago.
Improve this question
When we implement factory pattern in java
Suppose the factory of products needs to be implemented, A Product interface is required, All the concrete classes like AProduct, BProduct and CProduct will implement the Product Interface.
Public Static Product createProduct(String prdName);
The signature of the factory method will be as shown above.
Now if a new product say DProduct is introduced then we need to make changes to createProduct method, So this pattern does not follow OPEN CLOSE Principle.
(Open close principle is your code should be open for extension and closed for modification.)
Can I apply any other pattern over this, that will solve my problem.

if a new product say DProduct is introduced then we need to make changes to createProduct method
No, or at least not necessarily: consider java.sql.DriverManager class for a counterexample. Its getConnection(String url) is clearly a factory method, yet it handles addition of new drivers with ease, with no changes made to the method itself.
The trick is to make your factory configurable: rather than hardcoding a bunch of if-then-elses, you could build a "registry" of classes that maps the key passed into the factory to the name of the class, and use reflection APIs to instantiate the classes that your method needs to return.

Naming conventions pattern: Collection and Collections? [closed]

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 9 years ago.
Improve this question
not asking the functionality of Collection or the Collections classes in Java. i see this pattern everywhere where you have a class called e.g. "Animal" and another class called "Animals". is there a design pattern into play here or is it just general convention?

1.Collection is not class.
2.design pattern is for solving a certain type of problem. your question has nothing to do with design pattern. it could be a naming convention thing. e.g. guava has Lists, Maps..., however you could name your class as Animal and AnimalUtil, AnimalHelper, AnimalTools whatever You name it as AnimalFactory doesn't mean it applied Factory pattern. Just name.

No specific design pattern here. Collections contains utility methods applicable for collection related classes. Another example is Objects class from jdk 7 that contains utility operations you can perform on any object instance.