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
What I have been taught, and therefor restricted to, is to pass an object as a handler. I have used this approach in both my Java and Objective-C programming projects, and it works.
However, I stumbled upon a framework that registers a class as the handler, not an object. I wish that framework was open-source so I can see how that works, but it isn't :/.
Beware! After I register the class, I implement non-static methods to handle the events. If they were static, it would be obvious how this works, and I would really hate this approach.
So, these are my questions:
How does a class handler work and differ from normal object handlers?
When would you recommend one over the other?
Does this pattern have a name?
What I mean by object handlers:
Java:
button.addActionListener(handlerObject);
What I mean by class handlers:
Java:
object.addCrazyHandler(MyHandler.class);
Java (not sure about Objective-C) allows you through the Reflection API to do introspection on objects and their classes, hence the Object.getClass() method and all the methods on Class. Not only can you find all the constructors, methods, fields, implemented interfaces and superclass of a class, you can also call them (though it's slower than a direct call): newInstance() on constructors, invoke() on methods, get() or set() on fields. For example (exception handlers omitted), to call a no-argument constructor through Reflection:
Object o = SomeClass.class.getConstructor().newInstance();
Lots of frameworks use this: test frameworks such as TestNG or JUnit use it to instanciate the test classes, for example. So does Spring when you use XML configuration.
In your case, I suppose the framework wants to control the lifecycle of the handler, which it can't if you provide it with an instance. Another option would have been for it to take an instance of a factory, but that may be too restrictive. That can also mean more boiler-plate code to write, when it can easily create the object itself.
Related
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
After reading Interface vs Base class I understand that Inheritance should be used where there exists a "is-a" relationship and interfaces should be used in "can-do" kind of places.
If that means, base class can only have business objects and interfaces will have only the contracts?
For e.g Dog class will have a base class Animal with properties like Eye,Nose,Leg etc and interface IAnimal will have "Run", "Jump" etc.
Will design applicable for all the scenarios?
The answers on that question you linked actually say it all. Especially the accepted answer and its first comment. You use an interface to declare the contract and a base class for shared implementation.
I'd consider it a common practice to define interfaces for (almost) everything. An interface can also contain getters and setters and therefore define its subtypes properties. If two or more classes that implement that interface share some implementation, you can moved that to a base class. That base class would then also implement the interface.
Your understanding is correct, but I think it relies more on good practices than actual language rules. Please consider the following:
In languages that support multiple inheritance (C++) interfaces are just classes with all methods virtual and abstract. See this question
Languages that don't allow multiple inheritance (Java), the most important difference is that a class can have no more than 1 superclass, but can implement an arbitrary number of interfaces. There are also differences in declaring variables (variables are implicitly static and final in Java interfaces) but it's still not a big leap to think of interfaces as of 100% abstract classes.
Java 8 introduced default methods (see this question), which can kind of blur the obvious distinction between those two.
So while technically it's not true neither that interfaces must only define the contract (default methods can implement a fallback behavior in a Java 8 interface) nor that abstract classes must define behavior (because a pure abstract class with no implementations can exist), the approach that you described is kind of reasonable and common in real world.
It depends.....
That's a good starting point but it is not right to say that it will be applicable in all scenarios. Systems keep changing and as part of refactoring (http://refactoring.com/catalog/) sometimes interfaces become subclasses and the other way round. Interfaces are good for Mix-ins which you mention as "can-do" kind of behavior and Inheritance where a group of classes share certain properties and possibly some behavior enabling reuse and avoiding code duplication (which is essentially what a IS-A relationship is). You can read more about it in Effective Java by Joshua Bloch (there is an item on Interfaces and Inheritance).
If we take your example, the methods "Run" and "Jump" can be either defined in Animal base class or they can go in an interface as you mention, in fact they can actually go in multiple interfaces too. So you might start off by building a inheritance hierarchy and later refactor them into interfaces as the system evolves.
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 9 years ago.
Improve this question
Say I have a class in a programming language:
class name {
variable_name = 1;
method_name(x) {
// return something
}
}
foo = new name();
print(foo.method_name(foo.variable_name));
How correct is the following? Can we make it more correct?
If I want to talk about a specific instance of a method (foo.method_name), would I say 'the method_name-method of the object foo'? Or something else? Or does talking about the instance of a variable of method make no sense?
If I want to talk about a general object of any name, and refer to its method_name-method or variable, what would I say? Would I say 'the method_name-method/variable_name-variable of the class name?' or something else?
Thank you for your time.
Kind regards,
Marius
Talking about a specific instance of a method doesn't really make any sense as you say. Usually we talk about instances of classes - objects - and their methods. Thus one would normally talk about something like "calling method_name on foo" or simply foo dot method_name.
That's a fine way of saying it. In my experience it doesn't really matter all that much in day to day communication as the method really does the same thing anyways, just with different values in it's scope. It's what it does that really matters (e.g. accelerate() or toString()). Perhaps the most important part when talking about methods, variables etc. is communicating clearly if they happen to be static - i.e. not belonging to any given instances. In day to day speak I wouldn't make any effort to differentiate very clearly between "then we can just call accelerate on our car instance" and "the car class has a method named accelerate" (it's given that this is a non-static method) - I might however specify that "our car class has a static method to help us calculate acceleration.
In a nutshell:
Classes: (which may be instantiated to objects)
can have -
(non-static / instance) members
- public
- methods
- properties
- private
- methods
- properties
(static / class) members
- public
- methods
- properties
- private
- methods
- properties
However, methods have/can also be called messages, selectors, or behaviours (depending on the language in question, and in particular contexts.) It's occasionally considered incorrect to call them functions, however no one in their right mind should take you to task over such things. (notably the appearance of the keyword function in ECMAScript shows its level of acceptability. As a rule of thumb, the language domain would always define correctness, otherwise generally the term is fine/understandable but can lead to ambiguity.) Similarly properties are variously called, fields, attributes or variables.
An alternative name for non-static methods or properties is to call them instance methods or properties. While static methods / properties may be referred to as class methods / properties. By the way, ommitting the non-static qualifier, is usual and implicit.
As a general guideline, refer to the language under use to determine the correct terms, as they are specific to the various language cultures.
The assumption in writing this, is that there's no need to outline the scope/access differences of these class members. If that's required, I'd be happy to add a note.
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 5 years ago.
Improve this question
Assume there is an abstract class with a constructor that calls a protected abstract method that is yet to be implemented by the child class. Is this a good or bad idea? Why?
This is a bad idea.
You're basically creating inversion of control within a constructor. The method in the base class that is being called gets called before the base class data is initialized (in most languages), which is dangerous, as well. It can easily lead to indeterminate behavior.
Remember, in most languages, when you construct a class, all of the base class construction runs first. So, if you have something like: MyClass() : MyBaseClass() {}, typically, MyBaseClass's constructor runs in its entirety, then MyClass's constructor executes. However, by using a virtual method in the base class, you're calling an instance method in MyClass before it's fully initialized - which could be very dangerous.
This is a bad idea, because in most OOP languages, the child is initialized after the parent is initialized. If the abstract function is implemented in the child, then it may operate on data in the child under the incorrect assumption that it has already been initialized, which is not the case in parent construction.
Example:
class Base {
public:
Base() { virtualInit(); }
virtual ~Base() {}
protected:
virtual void virtualInit() {}
};
class Derived : public Base {
public:
Derived() : ptr_(new SomeObject) {}
virtual ~Derived() {}
protected:
virtual void virtualInit() {
// dereference ptr_
}
private:
scoped_ptr<SomeObject> ptr_;
};
In the example above, Base::Base() gets executed before Derived::Derived(), which is responsible for initializing ptr_. Hence, when virtualInit() is called from Base::Base() it dereferences an uninitialized pointer, leading to all sorts of trouble. This is why ctors and dtors should call only non-virtual functions (in C++), final functions (in Java), or the language-specific equivalent.
I can't see the reasoning of why you would want to do this, let alone qualify it. Sounds like your trying to inject some functionality into the object. Why wouldn't you just overload the constructor or create a property that can be set so that you can inject the functionality through composition or even create the constructor with a parameter which is the IOC object.
As another has already posted, it does depend on the context in which your trying to solve a particular problem. The natural fit would be to adhere to an interface, develop an abstract class, and overload the constructor in each implementation. Without further information I can only comment on what has been posted in your question.
This design you have can not be regarded good or bad. Simply from the fact that it may be the only way you can achieve what your trying to do.
It is only then a GOOD idea, IFF you can manage it to not shoot in your own foot. But anyway, OOP is always prone to bad designs; so if your language allows other paradigms than OOP, to use OOP in this case is definitely a BAD choice.
At least in C++,
the child class defines in which sequence all the initialisations are made; that are the initialisations of all member-variables and the constructors of all parent classes. This has to be considered!
Alternatively, you could give the constructor (as parameter) a pointer to a specific function (I would prefer static functions), instead of calling an abstract member-function. This could be a far more elegant and sane solution; and this is the usual solution in (probably all) non-OOP languages. (in java: A pointer to one function or a list of functions is the design pattern of an interface and vice versa.)
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 5 years ago.
Improve this question
Consider that I have a complex class structure where many elements inherit from other elements. I may have a method GetStuff(string stuffName, int count) defined in an interface, which is inherited by other interface, which is then implemented abstractly by an abstract class, which is then implement explicit in a concrete class etc. etc...
How should I handle inherited members such as GetStuff() when documenting my code with XML comments which will be used with a tool such as Doxygen or Sandcastle? It seems wrong to just copy and paste the same description at each level. Should I be considering a different audience at the interface level vs the concrete class level? For example the documentation for GetStuff() at the interface may consider people implementing the interface, whereas the documentation at the concrete level may instead consider people who will be using the class?
Document the interface method according to its code contract. Do not comment on its implementation, only on its semantic purpose, i.e. what it’s supposed to do, not how. The audience for this documentation is both your implementors and your users: the method will both be implemented as well as called.
Document the abstract method simply by saying that it implements the interface method and linking to it. There is nothing extra to be said about it, and duplicating the comment violates the DRY (Don’t Repeat Yourself) principle: you would have to remember to make any change to it in both places. (Of course, in the case of an abstract method that doesn’t implement an interface method, document it in the same way that you would document an interface method.)
Document the concrete implementation by saying that it implements the interface method and/or that it overrides the abstract member. Optionally add information about its implementation if it is relevant to the caller — for example, its performance characteristics, or situations in which it might throw, etc.
remark
on part of post
by Eric Anastas
It seems wrong to just copy and paste
the same description at each level.
I can imagine it being wrong to just copy. It is however possible to let doxygen copy it for you and then change what you would like to change for that implementation/scope.
For more information, you can look at the description for #copydoc.
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 6 years ago.
Improve this question
I'm trying to figure out the best way to register my C++ Classes constructors with Lua (from a software design perspective, not a coding perspective)
How shall I do this ?
My Ideas:
1) Make some kind of "init Lua bindings" file which binds each of the C++ constructors that I want to have available in Lua ? (problem: this file would tend to get bigger and bigger and difficult to sync/debug)
2) Each class is responsable to register it's own constructor with my "LuaManager" Class
(problem: it would be stupid to bind the same constructor to Lua over and over again for the same Class of kind A, so ideally, each kind of scriptable Class should bind it's constructor with Lua only Once when using this approach.)
Ideas, or opinions are very welcome.
I understand what you mean by asking
from a software design perspective,
not a coding perspective
however I'm not sure there's clear distinction between the two. Or, more correctly, the coding approach you take will determine your design options. For example, if you use SWIG, the options in your question don't really make sense, since you write a separate "interface" file. If you are using luabind, the options do make sense, but I would definitely choose 1) in that case as luabind headers slow compilation dramatically and I'd like to have them included in as few compilation units as possible. If your "coding" approach doesn't have that luabind shortcoming then 2) seems like the more sensible thing to do.
Your second approach will work well. One way to avoid multiple registrations is to use a static initialization list approach. Each class would add a Lua registration function to a static std::set pre-main. Then you'd walk this std::set when your application starts and add each class constructor binding to your Lua runtime. This would ensure your class bindings are registered only once.