I'm new to Java and I'm running into a compile error I cannot figure out.
Chapter5Debug is not abstract and does not override abstract method itemStateChanged(java.awt.event.ItemEvent) in java.awt.event.ItemListener
public class Chapter5Debug extends Frame implements ItemListener
^
Can anyone help me understand what I need to do to fix this?
Appreciate the help!
Sheila
You have to remember that if ItemListener is abstract, then you will need to implement all the methods inside ItemListener. If you want to keep your current structure, you can just add an empty itemStateChanged method to your Chapter5Debug class.
To elaborate on #kevolution's answer:
public class Chapter5Debug extends Frame implements ItemListener {
public void itemStateChanged(ItemEvent e) {
// Write your method here
}
}
An abstract class is one which is just like a regular class but can contain some 'stub' - or abstract - methods. These are methods which need to be implemented by the class extending the abstract class. In this case, itemStateChanged() is marked as abstract, meaning that you need to declare it.
Abstract classes are useful for when you're writing code which you need the caller to provide guts in some ways. In this case, Java cannot know what to do when the item's state changes, but it can do a whole lot of other stuff. The other stuff is in regular methods in the Frame class, and these call the itemStateChanged() method - which will then invoke your own handling code.
You need o implement itemStateChanged(ItemEvent) within Chapter5Debug
example code
public class Chapter5Debug extends Frame implements ItemListener{
//where initialization occurs
checkbox.addItemListener(this);
public void itemStateChanged(ItemEvent e) {
if (e.getStateChange() == ItemEvent.SELECTED) {
label.setVisible(true);
...
} else {
label.setVisible(false);
}
}
}
ItemListener is an interface and hence implementing ItemListener means you either you will have to provide the implementation in Chapter5Debug
or
You can make Chapter5Debug abstract and then provide the implementation in the class inheriting Chapter5Debug.
Crux is that if you implementing an interface, You can't get away by not providing the implementation. Either you have to provide it there itself or carry it to the child classes.
Related
I know its a weird question but I was asked this in an interview by the CEO of a software house,
First, he asked if a remote could be considered an Object, If yes then explain why?
If it is an object then can it be polymorphic in nature (in the context of OOP) ?
I said no because it can only switch on/off an AC, but he said what if I use it as a weapon and throw it at someone?
Does that make it polymorphic?
Can somebody please explain this?
Yes, it could. Think in a remote controller compatible with Air Coinditioners of the same brand. You can raise or lower the temperature of several models, but you can't for example enable ECO System for all models. You have a base behavior sharing an interface and you have concrete remotes specialized with a very concrete behavior.
And yes, throw a remote as a weapon could be polymorphic as you can think of it as an object. All objects in your house could be throwed against someone. All classes derive from object class (simple inheritance), so all objects could share the object base behavior.
if a remote could be considered an Object
yes, because you can design/model any real world item
https://www.educative.io/blog/object-oriented-programming
can it be polymorphic in nature (in the context of OOP)
yes, you can create abstract class to share behaviours among derived classes. After share behaviour is defined, then you can implement concrete remote controls like Electrolux, LG, Samsung
public abstract class RemoteControl
{
public abstract void TurnOnOff();
}
public class RemoteControl_Electrolux : RemoteControl
{
public override void TurnOnOff()
{
Console.WriteLine("Electrolux is turned on/off");
}
}
public class RemoteControl_Samsung : RemoteControl
{
public override void TurnOnOff()
{
Console.WriteLine("Samsung is turned on/off");
}
}
public class RemoteControl_LG : RemoteControl
{
public override void TurnOnOff()
{
Console.WriteLine("LG is turned on/off");
}
}
and use it:
List<RemoteControl> remoteControls = new List<RemoteControl>();
remoteControls.Add(new RemoteControl_Electrolux());
remoteControls.Add(new RemoteControl_Samsung());
remoteControls.Add(new RemoteControl_LG());
foreach (RemoteControl control in remoteControls)
{
control.TurnOnOff();
}
what if I use it as a weapon and throw it at someone? Does that make it polymorphic
no, it does not make it polymorphic as remote control does not have behaviour of a weapon. And this is a violation of Liskov substitution principle of SOLID principles.
I am trying to test my Service class below
#Service
#RequiredArgsConstructor(onConstructor = #__(#Autowired))
public class TaskTemplateService {
#NonNull
TaskTemplateRepository taskTemplateRepository;
public void doStuff() {
List<MyObject> list;
doOtherStuff(list)
}
private void doOtherStuff(List <MyObject>) {
//do stuff
}
}
When I am testing the real TaskTemplate, how can I capture what is passed to doOtherStuff?
You cannot and why would you?
Good testing means to specify the behaviour of a unit's public interface. Private methods ought to be covered via testing this way indirectly. If this is not possible then either you have dead, unreachable code or a design problem and should refactor.
BTW, the technical reason that you cannot mock/stub private methods is that most mocking tools, also the built-in feature of Spock, use dynamic proxies (DP) in order to implement mocking. DP technically are subclasses, but private methods can never be extended or even seen by subclasses or being called by them or from other classes, hence the term "private". Consequently, a mock subclass cannot check interactions with private methods.
How exactly you ought to redesign your class in order to make it testable really depends on why you want to "capture" the method argument, as you say. Do you need to replace it by a mock? Do you need to modify or verify the content of the original object?
If the object has a central meaning and you need to replace or verify it, why not make it injectable instead of creating it as a local variable, hermetically sealing it off from the outside world and making it untestable?
Or maybe in your case you could make the private method protected or package-scoped in order to make it testable. Then at least a mock could be created for it and you could capture the argument or stub the result.
I am mostly speculating here because the answer really depends on what is behind //do stuff, i.e. the very information you are hiding in your sample code.
How to dynamic modify a class's super classes to point to another class as its superclass by asm or javassist?
I know how to modify a class's methods and fields.
You should take a look at setSuperclass. Here is a small example:
CtClass c = pool.getCtClass("com.my.class.A");
c.setSuperclass(pool.getCtClass("com.my.class.B"));
Here is the documentation for this method:
public void setSuperclass​(CtClass clazz)
throws CannotCompileException
Changes a super class unless this object represents an interface. The new super class must
be compatible with the old one; for example, it should inherit from
the old super class.
If this object represents an interface, this
method is equivalent to addInterface(); it appends clazz to the list
of the super interfaces extended by that interface. Note that an
interface can extend multiple super interfaces.
A NinjectBootstrapper class has been created in a Service project(responsible for getting products).
This is my code
public static class NinjectBootstrapper
{
private static readonly object _thislock = new object();
//flag to prevent bootstrap for executing multiple times
private static bool _done;
public static void Bootstrap()
{
lock(_thislock)
{
if(_done)
{
return;
}
_done = true;
// services
NinjectContainer.Kernel.Bind<IProductService>().To<ProductService>();
// repositories
NinjectContainer.Kernel.Bind<IProductRepository>().To<ProductRepository>();
}
}
}
Now, while this works, I would really like to know if there are better ways to refactor my code. For instance I've read a lot of stuff about using a singleton instead of the static class.
I'd like to really set a good base here to make it easy and flexible for future developers to extend functionality. What are some good pointers and tips I can take into consideration?
I've read a lot of stuff about using a singleton instead of the static class.
When applying DI we typically prefer instance classes over static classes, because we can't practice Constructor Injection in static classes. This doesn't mean however, that static classes are a bad practice. When classes have no dependencies and no state, static is fine.
This holds as well for code in the startup path, such as your NinjectBootstrapper. You can make it an instance class, but since this class is started directly at startup, no dependencies need to be injected (obviously, because it is the thing that wires the DI container), it would typically be useless to make this an instance class.
I wanted to create an abstract base class for all of my view models, but I'm running into accessibility issues and can't seem to navigate through the errors. Here's an example of my code:
public ref class ViewModelBase {
...
}
public ref class OtherViewModel : ViewModelBase {
...
}
When I define my code as state above, I get the following error:
error C4585: 'MyNamespace::ViewModelBase' : A WinRT 'public ref class' must either be sealed or derive from an existing unsealed class
If, instead, I make ViewModelBase private, I get this error:
error C3213: base class 'MyNamespace::ViewModelBase' is less accessible than 'OtherViewModel'
This seems like it should be incredibly simple. What am I doing wrong?
What you are attempting is not strictly possible in C++/CX, as in VS 2012 C++/CX does not support public class inheritance for general-purpose scenarios. It is only supported enough to have the XAML scenarios work; the only possible public unsealed types are those found under the Windows::UI::Xaml namespace, and users are not able to author their own public unsealed types.
If you want to have a base class for all your view models, your only options to make all your classes private or to inherit from a base class from Windows::UI::Xaml (such as DependencyObject).
Each of these approaches has drawbacks:
using DependencyObject as your base makes all your viewmodels STA objects (so they can only be manipulated from the UI thread) in addition to having a lot of overhead that isn't really necessary.
Making your classes private means you cannot use the [Bindable] attribute to do databinding, so you would need to have a private databinding implementation. (Your private class would need to implement ICustomPropertyProvider and related interfaces.)
The "sealed" keyword means that the class cannot be inherited from. Your implementation should look something like this:
ref class ViewModelBase sealed
If you want to inherit from ViewModelBase then you need to have only the subclasses be ref classes like this:
class ViewModelBase
...
public ref class OtherViewModel sealed : ViewModelBase