I have searched for writing junits for anonymous inner class, but cannot find any solution. Is there a simple example for writing junits for anonymous inner class using Mockito?
An anonymous inner class is an implementation detail, don't try and "write a test for it".
Instead write a test that describes the behaviour of the class that uses the inner class. It should be possible to fully exercise the code of the inner class from the parent's public interface, otherwise why is the code there?
Should ever you wish to change the implementation of this functionality the test will now support you in making that change. If you somehow "tested the inner class" you would need to also rewrite the test and it would make your job harder rather than easier.
Related
I feel like this subject is touched in some other questions but it doesn't get into Python (3.7) specifically, which is the language I'm most familiar with.
I'm starting to get the hang of abstract classes and how to use them as blueprints for subclasses I'm creating.
What I don't understand though, is the purpose of concrete methods in abstract classes.
If I'm never going to instantiate my parent abstract class, why would a concrete method be needed at all, shouldn't I just stick with abstract methods to guide the creation of my subclasses and explicit the expected behavior?
Thanks.
This question is not Python specific, but general object oriented.
There may be cases in which all your sub-classes need a certain method with a common behavior. It would be tedious to implement the same method in all your sub-classes. If you instead implement the method in the parent class, all your sub-classes inherit this method automatically. Even callers may call the method on your sub-class, although it is implemented in the parent class. This is one of the basic mechanics of class inheritance.
Let's say in my program I have a class called Robot that inherits from some other class.
Until now I have some methods inside Robot like addPart or getCost. Now I'm asked to add a new module of functionality to it (a few methods that use it's parts) but they explicitly ask the new module to be added with little to no impact to the current class.
I thought a Visitor could solve this but the thing is I won't be applying the pattern to a hierarchy. Is this a correct thing to do? (as you can see my Robot is part of a composite)
Fundamentally, I agree with your approach. You have successfully identified an approach that allows you to extend Robot (a parts composite) without having to actually modify the Robot class. The only changes I would make are the following:
I would introduce a new interface named something like IPartsComposite that would define the Accept method. This interface would be implemented by Robot since it is composed of Part instances.
The base Visitor would be a base generic class or interface i.e.Visitor<T>. This type would define a single method Visit(T). Then, in your case, you would have three concrete implementations of Visitor<IPartsComposite>.
PartsVisitorService
PartsVisitorCosts
PartsVisitorProduction
In each of these concrete classes you would implement Visit(IPartsComposite).
I recently read in "Professional C# 4 and .NET 4" that:
You can never instantiate an interface.
But periodically I see things like this:
IQuadrilateral myQuad;
What are the limitations in using interfaces directly (without having a class inherit from the interface)? How could I use such objects (if they can even be called objects)?
For example instead of using a Square class that derives from IQuadrilateral, to what extent could I get away with creating an interface like IQuadrilateral myQuad?
Since interfaces don't implement methods, I don't think I could use any methods with them. I thought interfaces didn't have fields to them (only properties), so I'm not sure how I could store data with them.
The answer is simple, you can't instantiate an interface.
The example you provided is not an example of instantiating an interface, you are just defining a local variable of the type IQuadrilateral
To instantiate the interface, you would have to do this:
IQuadrilateral myQuad = new IQuadrilateral();
And that isn't possible since IQuadrilateral does not have a constructor.
This is perfectly valid:
IQuadrilateral myQuad = new Square();
But you aren't initiating IQuadrilateral, you are initiating Square and assigning it to a variable with the type IQuadrilateral.
The methods available in myQuad would be the methods defined in the interface, but the implementation would be based on the implementation in Square. And any additional methods in Square that are not part of the IQuadrilateral interface would not be available unless you cast myQuad to a Square variable.
You can't create an instance of an interface.
The code you showed defines a variable of type IQuadrilateral. The actual instance this variable points to will always be of a concrete class implementing this interface.
Background Knowledge
Think of an interface as a contract. In a contract between two people, it defines what is capable, what is expected from the parties involved. In programming, it works the same way. The interface defines what to expect, what must exist for you to conform to that interface. Therefore, since it only defines what to expect, it itself, doesn't provide the implementation, the "code under the covers" so to speak, does.
A property behaves like a field, but allows you to intercept when someone assigns a value to it or reads the value. You can also deny reading or writing to it, your choice when you define the property. Interfaces work with properties instead of fields because of this. Since the "contract" is just defining what property should be there (name and type), and if it should allow a read or write capabilities, it leaves it up to the implementer to provide this.
Take for example the IEnumerator interface from the .NET framework. This interface was designed to allow iteration over a collection of objects. The purpose is not to change items, or randomly access them, it's just for getting object A and moving to the next, and the next, and the next, as many times as needed. Many collection type classes implement this: Queue, ArrayList, SortedList, Stack, etc. All these types of objects store many objects and now they all share the common "contract": the ability to iterate one-by-one over them.
However, you can see that the IEnumerator interface has a MoveNext() method declared. Why? This is because the items may not be served in the same manner. For example, people will generally access the ArrayList from the first item to the last. But a Stack was designed opposite, for people to access the last object down to the first.
Questions Answered
With all this knowledge, the limitation of declaring a variable as the interface type as opposed to the class type that implemented the interface is that you only get access to what the interface (the contract) says should be there. The benefit though is that you can assign to this variable any class type that implements the interface.
Background: I am programming a .NET compiler (very similar to C#) for a school project. One of the features I am currently trying to add is tailcall recursion within methods.
More info: In CIL, the "this" is passed into instance methods as if it were just another argument. So, accessing the first argument of a static method, you would emit ldarg.0, but accessing the first argument of an instance method, you would emit ldarg.1, and accessing "this" in an instance method you would emit ldarg.0. (Instance methods are even more similar to extension methods than I ever imagined.)
Question: Can you set "this" using starg.0 without any side effects?
Why this is in question: Whether or not a method is an instance method is set with the MethodBuilder, which is a bit of a black box. Although "this" seems just like any other argument, for all I know some JIT compilers keep track of "this" separately and change their behavior depending on this value. If there are side effects when you set "this" in an instance method, then how can I avoid them?
You may want to have a look at how F# implements tail-call.
You can extract this as a local variable. This way you will know that you can set it safely. (I hope I understand your question correctly)
AST Transformations are implemented in Groovy. What's a practical example of using an AST Transformation?
This page has practical examples of how to use:
#Singleton, #Lazy, #Immutable, #Delegate, #Newify, #Category, #Mixin, #PackageScope
Scenarios like:
Authorization Checking - Security by checking role from context
Print Parameter values with which the method is called
Asserts Parameters are not null or any validation
Check various entry-conditions/Pre-Conditions of the method
Generic AOP style BeforeMethod() implementation
Create a method and mark it to run as runnable or main method
Take a look at my blog post at AST AOP and AST Param not null
Hope this helps!
Most of the practical examples of using the AST transformations are provided on that page. I've often used #Delegate to delegate to another class or #Lazy for lazy loading. #Grab is great for pulling in dependencies from a Maven/ivy repository. All of those are based on AST transformations and are part of the core language.
You can use transformations directly too but most of the stuff you would want them for is already built. You can do things that you might want to do with AOP in other languages.