Android requires that all Activity sub-classes invoke super methods from their lifecycle methods. An exception is thrown if the super method is not invoked. Why does Android use a RuntimeException mechanism to force super methods to be called. Why does it not use the 'Template' design pattern so that super methods get executed automatically before the child methods. For example onDestroy() can be handled as follows :-
Class Activity{
public void onDestroyFrmwork()
{
//do whatever the super onDestroy() method has to do
onDestroy();//this will invoke the subclass method.
}
public void onDestroy()
{
//empty. will get overridden by subclasses.
}
}
I know I am answering this question 11 months after it was asked. I guess the reason is that the order of calling the super method cannot be determined in advance. For example, I might want to do my clean up before calling super.onDestroy(), after super.onDestroy() or even mix it up like follows:
#Override
protected void onDestroy() {
// Do some initial clean-up
preDestroy();
//Then call super
super.onDestroy();
//In the end do some final clean-up
postDestroy();
}
This example is for the sake of argument; but I'm sure you would come across real world examples if you look hard enough.
This kind of mixed ordering would be hard to achieve using Template design pattern.
Your application won't work correctly if you don't call the superclass methods, so the API throws a RuntimeException to make sure you don't forget to do so.
Related
After my research, my own answer to my question is: unfortunately, no. But I'd like to hear your opinion as well.
I have 4 controllers each having 5 methods. Every method has a try-catch block. In case of an exception, I want to log on a file a message with all the parameters of that controllers. So I have to write the basically same log instruction 4x5=20 times. If I want to change the logging message, I have to do it 20 times. On one hand, sounds like a hard to maintain problem. But on the other hand, every controller has its own signature.
Would it be possible to have some base/parent/God method that virtually logs for every controller? And of course if I will be needing to adapt/override the logging instruction just for one controller this should be also possible. Is there any technique?
How about if I just need to generate for every controller methods a GUID?
There are many ways to achieve a single piece of code that can log all your controller methods. The easiest implementation which comes to my mind is to just write a method that takes an action or function. Then inside just call that action/function and wrap it in any logging that you wish to use. Like so:
public void ExecuteWithLogging(Action actionToExecute)
{
try
{
action() // the same as action.Invoke()
}
catch(Exception e)
{
// code your logging here
}
}
then inside your controller's methods you could use it like this:
ExecuteWithLogging(() =>
{
// your controller code
});
But there are other ways. You could probably use attributes to mark each method as logged. Or maybe you could write some middle-ware that just logs everything (like maybe in this article -> https://exceptionnotfound.net/using-middleware-to-log-requests-and-responses-in-asp-net-core/).
The options are many!
I have abstracted a bunch of code to behaviors, and now when i do:
class B extends A with behave {
B():super(){}
}
class A extends PolymerElement{
A(){}
}
abstract class behave {
test(){ print("Test"); }
}
So what I have been trying to do is create a workflow without having to append references to this new function test
As of right now, if you implement test in A or B, it will override the behavior I had created. But I was hoping to append more to it, something similar to:
class B extends A with behave {
B():super(){}
test():super.test(){}
}
and this would do something like call the parent test. Now when looking this, i would say, this would make sense if the behavior was in the parent. So lets test that out.
abstract class behave { ... }
class A extends behave { ... }
class B extends A {
test(){
super.test();
}
}
This would work and execute what I was wanting to do... Why cant i reference it in the instantiation? test():super.test(){ ... } It seems that doing as just stated will error as a constructor error.
Now what if we put it back to my original design, as behave being with B
abstract class behave { ... }
class A { ... }
class B extends A with behave {
test(){
super.test();
print("Foo");
}
}
now here it seems to work as expected, requiring us to create a super reference to this behavior.
Is there an idea of using : for referencing a parent function call, or is this only ever used for constructors? I would say, yes it is only used for constructors for now, but why not append additional functionality. If i wanted to create a series of functions in the behavior which mimic the child implementation, I should either run super.test() either at the top of bottom of the function depending on the order required to function?
Is there something I am missing in dart when reading the docs, or is this how it is suppose to work for the time being?
I doubt that foo() : super.foo() syntax will be added to the language. The : for constructor initializers is useful because the initializers can be analyzed at compile time, which make it simple to verify that final fields are set for instance. The : syntax in a function would just be syntactic sugar for putting that function call at the beginning of the function, which doesn't seem to add much value.
By the way, you can add #mustCallSuper to your the test() function. This will add a check to the linter that all methods that override test() must call super.test().
How to declare a method inside a closure.Or which is better to use method or closure.
I have a closure and in that closure i have a method to call and i defined method as
def getBindedGenes(Long colId) {
........
}
But when i used codenarc plugin for code review it is showing the rule as GrailsPublicControllerMethod and the message as The Grails controller has a public method getBindedGenes. This should be a closure property or moved
What is the cause and what is happening exactly.
Thanks in advance
I think CodeNarc is warning you that your controller actions must be public closures, not public methods. Given that you can't use a public controller method as an action, there's probably no good reason to have one.
Grails 2.0 Update
Since Grails 2.0, public methods of controllers can be used as actions, and if fact, it is now recommended to use methods instead of closures.
My use case is to log every method call on an object.
After adding a method interceptor on the target object, I call the method Foo. This method Foo calls a method Bar. Only the method Foo will be logged.
class MyClass {
public void Foo() {Bar();}
public void Bar() {}
}
Reading the Spring documentation, I have found a sentence that explained why I cannot implement what I want. From Spring documentation (page 146):
Please note that in both cases a target method implementation that calls
other methods on the target object will not be advised.
Am I missing something here? Or is this really a Spring limitation?
A start of solution...
http://www.digizenstudio.com/blog/2007/05/29/the-self-calling-limitation-in-spring-aop-and-one-unintrusive-solution/
EDIT
Finally, I decided to switch to Castle AOP. They propose a class proxy that feets my needs.
You could use AspectJ weaving that will not have any such limitations.
Everytime I ask anyone what the Spring Framework is or what it does, they simply say to me, you remember that Hollywood principle right "Don't call me, I will call you", that's exactly what Spring Framework does.
What should I make out of this?
It means that a class doesn't manually instantiate the components that it depends on -- something (such as Spring's IoC context) gives the class an instance of each component that it needs. This is usually done either via setters for each component, or a constructor that takes all those components.
Basically instead of a class doing manual instantiation by itself:
public class Foo {
private Bar bar;
public void doStuff() {
bar = new BarImplementation();
bar.doMoreStuff();
}
}
IoC injects the dependency Bar into Foo, so that when you get a Foo object from the context, you know it's ready to use.
public class Foo {
private Bar bar;
public void setBar(Bar bar) { this.bar = bar; }
public void doStuff() {
// bar's already been set by the time this is called!
bar.doMoreStuff();
}
}
You didn't manually instantiate Bar, instead your configuration files (such as Spring XML) set it for you. Additionally, Foo is no longer tied to BarImplementation. Using interfaces allows you to insert different implementations, including mocks used for testing.
Sometimes callback models are more efficient, especially with anything to do with parsing
if you imagine the hollywood situation, its way more efficient for the "casting agent" to call everyone once they know who they are going to cast (or even not call) rather than having to keep taking calls from every applicant wanting an update.
Callbacks. :P That's what that means for me. Callbacks are functions that wait to be called.
See http://en.wikipedia.org/wiki/Inversion_of_Control
Spring does other things too but IoC/Dependency injection seems to be the most noted feature. It can help to make a system less coupled and more flexible.