I have been facing so many problem using the anonymous class like I can't perform the instanceOf test neither can I implements multiple interface, so could someone please explain what I can or can not do with the anonymous class in java ?
The purpose of an anonymous inner class is to extend and instantiate an existing class or implement a single interface in one step.
Its limitations can be derived from the above:
Only one non-final class can be extended or one interface implemented.
Only final local variables of the enclosing method can be accessed. (This is due to the fact that normal local variables will be out of scope by the time any methods of the inner class will be invoked.)
You can't define a constructor. (The class has no name.)
If you need multiple interfaces, you can use a local inner class, which is like a normal inner class, with its own name, but defined within a method. I have to admit I've never seen it used in practice and I see very little reason for anyone to do so, hopefully someone will come up with an example.
Anonymous classes work whenever
you never need to refer to the class itself
you only need to extend a single class or implement a single interface
...but other than that there aren't really any significant constraints. This works fine in a lot of cases: for example, many cases when you're defining callbacks, listeners, or the like.
Related
I have the main abstract class that is a base for bunch of classes. Some of them does not need all the fields and methods from the main abstract class, so I have created second abstract class and splitted main abstract class into two parts. The main abstract class contains, for example, a, x fields and their getters/setters, the second abstract class inherits from the main and contains additional b, c fields and their getter/setters. There are simple classes that are inheriting from the main class,and more complicated are inheriting from the second class. I want to create objects of each class as instances of the main class. Is it right way to do that? I have to type check and cast when I want to use methods from the second abstract class. It makes my code complicated. How can I solve this problem?
MainAbstractClass ---> SecondAbstractClass ---> MyComplicatedClasses
|
|
V
MySimpleClasses
One of the OO principles is Favor composition over inheritance.
This means that common behavior is not provided through base classes but via Component classes which are passed in via dependency injection (preferably as constructor parameters.
The answer depends on your actual needs.
You can instead choose to store the extended abstract class specific fields in a class that does not implement your base class and make it a member of more complicated classes.
You can choose to keep everything in a single base class and nothing forces you to use all the fields of an interface in every class that implemented your interface.
You can also keep using your approach but since you store the classes as an instance of the base class, it will be hard to read.
I believe that if you think code does not look very good, it is probably not good. However, there is usually no single answer to this kind of design questions and the best solution is relative to your preferences.
I think this need of type cast is a smell of fragile design. Here when we assume MyComplicatedClass ISA KIND OF MainAbstractClass as shown by TJ Crowder then object must behave as MainAbstractClass (meaning it can honor only API of MainAbstractClass). If it expects special treatment as MyComplicatedClass its false commitment and will need Casting. Such casting (by identifying type) goes against OO principles and kills polymorphism. Later this will end up in Ladder of InstanceOf and type casts as in the scenarios rightly pointed out by T.J. Crowder.
I would suggest readdress the design. e.g. though our all user defined type instances ARE KIND OF Object, but we use Object API only for methods defined in Object class. We do not use Object o = new MyClass(). There are occasions in frameworks or like Object.equals() method where type cast is needed as API is defined before even concrete extension is written. But it is not a good idea for such simple complete (without open hooks for extensions) Hierarchies.
What is the reason that I can't create a concrete class with abstract methods in it?
Is it enforced just to make sure that no object is created without abstract method definition? or is there another plausible reason for this restriction?
An abstract class is, by definition, incomplete. Therefore, you should not be able to instantiate abstract classes. An interesting side effect of this definition is that you can create abstract classes that have all concrete methods. It's just that you think that your class is incomplete and shouldn't be able to be instantiated.
abstract class in the java constext is defined as the class has at least one
abstract method. And an abstract method is just a not implemented method. This is a design decision that was just copied from c++ where it is exactly the same. The only difference is, that in c++ you do not need to tell the compiler that a class is abstract, the compiler knows it even without you telling it. Why this design decision was made in c++ I can't tell you, but having it eleminates a complete class of errors. The error that a method of a class get's called, when the method is not implemented in that sub class.
You are right, the reason is to prevent creating an object with no implementation for a method or more.
Because when you create an Abstract class you are in the middle of your abstractions level. i Mean you have some questions about class responsibilities or this class must to do something but they dont care how, partially. If you dont wanna have an implemented method, you must to create an interface.
In my opinion the answer is in the class responsibilities and abstraction and not in the technology scope.
I needed to do a java program for my class.
I did it and worked well.
In my code, I have some private methods. Do I need to build an Interface Class hide those private methods or they can be at the same class as the public methods?
At the moment all methods (public and private) are in the same class, but my coworker insists that I need to create an Interface to hide the private methods
No, you don't need to create an interface. An interface would hide them even more (from people's eyes, not from code) if you were to use the class only through the interface, but even without one, the private methods won't be available to other classes.
If you want to implement the "code to an interface" guideline fully, you can declare an interface for your public methods to implement.
What you can definitely not do is declare methods in an interface, then "implement" them as private in your class - that would reduce the visibility and not even compile.
Ultimately private methods are scoped to your class only.
It might help to repeat "what is the purpose of an Interface?"
It is: "a formal declaration of what, as far as anyone else should be concerned, this thing 'gives,' 'takes,' and 'does.'"
So ... if a client class wants to deal with "something that implements this Interface," and five other classes (none of which, say, are siblings or ancestors of one another ...), each in their own way, do so, then: any of the five would be compatible. Why? Because they supply all of the properties and/or methods that the interface requires. (That's what "implementing" actually means.)
None of this exposes any of the client's "private things." In fact, an Interface says absolutely nothing about how the class actually does what it has to do, nor what else it does. "Meet the requirements of the Interface, and you can get the job."
In object oriented programming, I have read that you should program to an interface not an implementation but do they mean literal interfaces (no shared code at all)?
Is it okay to program to an abstract base class that would have been an interface except that there were variables in this "interface" that all sub-classes were expected to have? Replicating a variable across sub-classes would have been an inconvenience because if I changed the name of one of the variables in one of the sub-classes I would have to change the name of that variable in all of the sub-classes.
In following the principle of "program to an interface not an implementation", is this okay or would you create another interface on top of the abstract base class and program to that interface?
You want to program to interfaces because it means lower coupling. Note that interfaces in Java are more flexible since they can be implemented by a class anywhere in the class hierarchy unlike abstract classes (as a result of single inheritance). Such flexibility means that your code is reusable to a higher degree.
The important point of "programming to an interface not an implementation" is that of the general principles mentioned above, even if they might cause some minor inconveniences.
Also, even if you program to an interface, you can always implement said interface (or parts of it) by means of abstract classes if you'd like, achieving both low coupling and code reusability at the same time.
It's always okay to program to abstract or even concrete classes, however it's better if you can avoid it.
This discussion might be helpful or this one and of course this one.
Note: C++ doesn't have interfaces. You might argue it doesn't need them.
you should program to an interface not an implementation but do they mean literal interfaces (no shared code at all)?
Possibly. Where it makes sense to do this, it can work very well. Note: in Java interfaces can have code as well.
Is it okay to program to an abstract base class that would have been an interface except that there were variables in this "interface" that all sub-classes were expected to have?
If you need fields in the implementation an abstract class can make sense. You can still use an interface as well.
Replicating a variable across sub-classes would have been an inconvenience because if I changed the name of one of the variables in one of the sub-classes I would have to change the name of that variable in all of the sub-classes.
This is where using an IDE helps. You can change a field, class, method name in all your code with one action.
is this okay or would you create another interface on top of the abstract base class and program to that interface?
You can code your implementation to an abstract class, but the users of that class should be using an interface if possible.
e.g. HashMap extends AbstractMap but implements Map. Most people would use Map not AbstractMap
How is it helpful to use anonymous class if every time we have to define a class while invoking a constructor of an interface.Wouldn't it be more better to simple use a generic type instead?
Anonymous classes is frequently used in GUI applications. When you only need to declare and create object of a class at the same time, it can make the code more precise.
Here is an example:
btn.setOnAction(new EventHandler<ActionEvent>() {
#Override
public void handle(ActionEvent event) {
System.out.println("Hello World!");
}
});
Anonymous classes are not defined every time they are instantiated. They get compiled into bytecode just like other classes, with a name e.g. MyEnclosingClass$1. See this post for more information: How are anonymous classes compiled in Java?
Tangentially, reflection can be used to identify them at runtime using Class.isAnonymousClass().
It depends on the situation; in some cases it will be better to use an anonymous class, and in others, it will be better to use a concrete class that implements the required interface.
If you believe that you'll need to provide the same anonymous class definition repeatedly, it will likely save you time to pass an instance of a concrete class that implements the required interface.
The Java language provides anonymous class syntax as a convenience.
To give you just a taste, here's a quick example from my own experience: Having lists backed by functions.
In general, anonymous classes have (among others) the following uses:
Suppose you want to have an object (an instance, not a class) whose behavior depends on some value available at runtime. Without anonymous classes, you can do this by setting fields (or calling state-changing methods) - but you can't have different code executing. Now, true, you could have bunch of switch() statements in your class' method code - but that completely decouples the definition of the behavior from its context. Another way you could go is to use a named subclass, but that's a lot of code, and it creates a noun you don't really want to exist.
Functional Programming! Until Java 8 comes along, anonymous functions are just about the only way you can pass around functions, which are not first-class citizens in Java. With those, you can perform many neat and elegant tricks like my example above.