I have the following two classes:
public class Prod
{
public void logon(){
System.out.println("'\u000CProd logon");
addUser();
}
public void addUser(){
System.out.println("Prod addUser");
}
}
public class Dev extends Prod
{
public void addUser(){
System.out.println("Dev addUser");
}
public static void main(String[] args){
Dev test = new Dev();
test.logon();
}
}
Is there a way to make all the methods static and then test whether the Dev.addUser() is working correctly?
Here's what I would like to be able to do:
public class Prod
{
public static void logon(){
System.out.println("'\u000CProd logon");
addUser();
}
public static void addUser(){
System.out.println("Prod addUser");
}
}
public class Dev extends Prod
{
public static void addUser(){
System.out.println("Dev addUser");
}
public static void main(String[] args){
logon();
}
}
When I run the main() in Dev we should get:
Prod logon
Dev addUser
Is there a way to make all the methods static and then test whether the Dev.addUser() is working correctly?
No, there isn't.
This is really fundamental Java: you want to use static methods in a polymorphic context. But static methods are not polymorphic. There is no true inheritance, there is no overwriting of static methods. See here for lengthy explanations why that is. Repeat: the desired output can't be achieved in a purely static way, built around class A extending class B. End of story.
And as already said: this is also wrong from a conceptual point. Because of such restrictions, static should only be used carefully in Java. Simply go with the non-static code you have right now.
Unfortunately your question isn't really clear what exactly you intend to test, therefore I can't help with that part.
Related
I want to create a set of classes that allows me to write records
What I want to achieve is this
Record.write.field1();
Record.write.field2();
My understanding is that I can create multiple static nested objects but I'm struggling with it
I created the following
public abstract class Record{
public Write write;
}
public abstract class Write{
public static void field1();
}
The approach above hasn't helped me achieve that.
The questions I have is
Can I write a set of classes in a way so I can achieve the following pattern
Record.write.field1();
Record.write.field2();
This is so that I can scale it up when needing to add additional field
If I can, is this a good approach?
If I can't, what's the best approach?
Thank you
UPDATE: I can do Record.write but can't do Record.write.field15();
public class Record {
public static Write write;
}
public class Write {
public static void field15(){
System.out.println("Hello");
}
}
This allows you to write the code the way you want:
class Record {
public static Write write = new Write();
}
class Write {
public void field15(){
System.out.println("Hello");
}
}
public class Main {
public static void main(String[] args) {
Record.write.field15(); // prints "Hello"
}
}
Note that static methods are invoked on the class name, and instance methods are invoked on a specific instance value.
I've been flustered over trying to figure out how to call a method from an instance of a class from a different class. For example:
public class Test1
{
public static void makeSomeInst()
{
Test1 inst = new Test1();
inst.fireTest();
}
public void fireTest()
{
System.out.println("fireTest");
}
public Test1()
{
}
}
no problem with understanding the above, but what If I want to do something to inst from a class called Test2, how would I do that? The below example doesn't work:
public class Test2
{
public static void main(String[] args)
{
Test1.makeSomeInst();
inst.fireTest();
}
}
And just to be extra clear, I get that I can call static references without instantiating, but I just want to know, in this specific case
What is the syntax to reference the test1 object called inst from the Test2 class?
what If I want to do something to inst from a class called Test2, how would I do that?
First of all you have to teach the Test2 class what Test1 is.
public class Test2
{
public doSomething()
{
inst.fireTest();
}
public Test2(Test1 inst)
{
this.inst = inst;
}
private Test1 inst;
}
Then teach the inst2 object what inst is.
public class Test1
{
public static void main(String[] args)
{
Test1 inst = new Test1();
Test2 inst2 = new Test2(inst); // <- new code
inst2.doSomething(); // <- new code
}
public void fireTest()
{
System.out.println("fireTest");
}
public Test1()
{
}
}
You only need one main to start the show. Flow of control can still pass through other objects. But at this point I wouldn't call these independent tests. I only used that name to match your code.
What you're looking at is something called reference passing. The fancy term for it is Pure Dependency Injection*. The basic pattern is to build an object graph in main. Once that's built call one method on one object to start the whole thing ticking.
In main you build every object that will live as long as your program does. What you wont find built here are objects that are born later, such as timestamps. A good rule of thumb is to build each of these long lived objects before doing any real work. Since they know about each other they can pass flow of control back and forth between them. There's a lot of power there and if not used well it can get confusing. Look into Architectural Patterns to help keep that simple.
The principle followed here is to separate use from construction. Following that allows you to easily change your mind about what talks to what in one place. It's nice when a design change doesn't force you to rewrite everything.
You have to save your instance somewhere.
If Test1 should be a singleton, you can do:
public class Test1
{
private static Test1 instance;
public static Test1 getInstance()
{
return instance == null ? instance = new Test1() : instance;
}
public static void main(String[] args)
{
Test1 inst = getInstance();
inst.fireTest();
}
public void fireTest()
{
System.out.println("fireTest");
}
}
and in Test2:
public class Test2
{
public static void main(String[] args)
{
Test1.getInstance().fireTest();
}
}
//Edit
As I just learned from #Thomas S. comment, singletons are not a good solution.
See #candied_orange's answer for a better implementation.
For two utility classes with the same names, which contain only static methods, I proceeded as follows:
Simply imported the first
Created an instance of the second class.
Example:
package util1;
public class Utility {
public static void method() {
System.out.println("First Utility. static method");
}
}
package util2;
public class Utility {
public static void method() {
System.out.println("Second Utility. static method");
}
}
import util1.Utility;
public class Component {
private static final util2.Utility anotherUtility = new util2.Utility();
public static void usedByReflection() {
Utility.method();
anotherUtility.method();
}
}
Now I don't need to write a full second util-class name for invoke its methods, but maybe I did not foresee something...?
P.S:
The methods of the class Component are called through a reflection by a certain BlackBox. All the multithread-safe features are in BlackBox.
UPD: I have found better trick:
import util1.Utility;
public class Component {
private static final util2.Utility anotherUtility = null; // There are some changes
public static void usedByReflection() {
Utility.method();
anotherUtility.method();
}
}
Now I dont create new object, but is it possible to use it without any bugs?
IMO, this is confusing and could much more clearly be handled by something like:
public class CombinedUtilityComponent {
public static void usedByReflection() {
util1.Utility.method();
util2.Utility.method();
}
}
Or, better yet, in your code you can just fully qualify the class names and they become unique names without any confusing tricks.
Yes, this works. I wouldn't do it, though.
You're calling a static method as if it were an instance method. anotherUtility.method() has a useless reference to anotherUtility.
You also have an unnecessary instantiation of util2.Utility. This technique wouldn't work if the default constructor were disabled.
This may be a bit of a silly question, but I'm newish to Lamda Expressions and programming in General.
After experimenting around with Lambda Expression like so :
interface Starter {
public void start();
}
class Machine {
public void run( Starter s ) {
System.out.println("Running code....");
s.start();
}
}
public static void main(String[] args){
Machine mac1 = new Machine();
mac1.run(() -> System.out.println("Hello World"));
}
It made me wonder, if the Interface, and the class (Machine in this case) can be moved into seperate files for this to still work? I tried doing it how I think it would work, but that didn't work, is this possible? and if so how do you do it?
As long as the Machine class and Starter interface are visible to your main class, then this is perfectly possible.
My guess is that you moved the Starter interface to another package than the main class, and as you have not included the "public" modifier, it is no longer visible to the main class and will refuse to compile.
If I understood your problem correct, than just add a separate class (say App.class), that contains public static void main method:
public interface Starter {
public void start();
}
public class Machine {
public void run( Starter s ) {
System.out.println("Running code....");
s.start();
}
}
public class App {
public static void main(String[] args){
Machine mac1 = new Machine();
mac1.run(() -> System.out.println("Hello World"));
}
}
Recently I've been restructuring a Java code of mines trying to eliminate, wherever possible, static stuff (variables and methods) and replace it with better coding practices.
I also started studying reflection and noticed that it allows me to do some things1 that, at first, I could only achieve (or, at least, that's how I see it) with static calls or references.
However, while I've been reading that the use of static is not much recommended, it doesn't seem to be the same with reflection.
So, I'm asking: instead of making a method static and calling it like ClassName.methodName(), is it a legitimate use of reflection making it an instance method and invoking it by java.lang.reflect.Method.invoke()?
1 like dynamically accessing a class' content
Here's a code sample:
Hypothetic situation that works (but I don't want to make the method static):
import static java.lang.System.out;
public class Foo
{
private static boolean light;
public Foo()
{
turnOn();
}
public static void turnOn()
{
light = true;
}
public static void turnOff()
{
light = false;
}
public static boolean isGreenLight()
{
return light;
}
}
public class Boo
{
public Boo()
{
if (Foo.isGreenLight()) // I need to access Foo.isGreenLight() from here, but cur-
{ // rently that method is not static (it should be to do so)
out.println("Ok!");
}
}
}
public final class Main
{
public static void main(String[] args)
{
final Boo boo = new Boo();
}
}
Hypothetic situation that also should work (how it'd be using reflection):
import static java.lang.System.out;
import java.lang.reflect.Method;
public class Foo
{
private boolean light;
public Foo()
{
turnOn();
}
public void turnOn()
{
this.light = true;
}
public void turnOff()
{
this.light = false;
}
public boolean isGreenLight()
{
return this.light;
}
}
public class Boo
{
public Boo()
{
if ((boolean) Class.forName("Foo").getMethod("isGreenLight", null).invoke(new Foo(), null))
{
out.println("Ok!");
}
}
}
public final class Main
{
public static void main(String[] args)
{
final Boo boo = new Boo();
}
}
Expected output (untested):
Ok!
Using reflection is a code smell, especially if the intent behind what you're writing does not warrant it.
It is difficult to say much more without seeing code as it's all just guesswork.
I would:
enumerate the reasons behind why you had those static members in the first place
determine if the static modifier was in fact the right decision in the first place: i.e. should these be instance or class members? How might they be used by "clients" of the classes in question? What paradigm am I using? Functional or Object Oriented code. Does it satisfy DRY, SOLID and KISS programming practices?
consider if I'm over-engineering in the first place
More importantly:
I would design my code through tests first, which drives the design of your API through the eye of the user, with the added benefit that you have test coverage before you've even implemented. Often times when writing code this way I eliminate such questions because the solution is more obvious when thought from the perspective of a user rather than a designer. It becomes a question of pragmatism rather than satisfying architectural design goals and philosophies.