I have a bad situation where a class i want to test is extending another class that has a pretty complex public static method. This wouldn't be such an issue if the parent class wasn't extending other classes that are required. In specific, I need \Illuminate\Database\Eloquent\Model to still be extended. My hands are tied regarding possible refactor to make this easier to test.
Is there any way to stub or change the parents of the class in question, while still allowing the Model class to perform?
Maybe you could create a YourClassTestCase that extends the class you are testing. Then, in YourClassTestCase override static method with a simplified return and launch the test over YourClassTestCase.
So you will have YourTest -> yourClassTestCase -> YourClass -> ParentWithStaticMethod.
You should use Mock Objects.
See here:https://phpunit.de/manual/current/en/test-doubles.html#test-doubles.mock-objects
In JavaFx, I understand that if I want a button to make some code run when it is clicked, I need to somehow have the code that I want to have run inside a method, and because this is Java, I wrap that method inside a class that extends EventHandler . For example:
// (myButton is a reference variable to a Button object)
myButton.setOnAction(new MyButtonEventHandlerClass() );
// inner class
public class MyButtonEventHandlerClass extends EventHandler<ActionEvent>{
public void handle(ActionEvent e) {
// (some code)
}
}
My confusion is: why is JavaFX designed to require me to make an instance of the class holding the handle() method? I had thought that non-static methods are used when the instance variables of an object are used; or in other words, if you just need a method that does not need an object, then you should use a static method. In this kind of thinking, handle() sounds like it should be a static method.
Why is handle() not a static method?
The criteria for a EventHandler to work in a meaningful way in this case are:
There needs to be some way to store the information.
The information has to be stored in a way that allows more than one way of dealing with a event.
Now regardless of the handle method actually using any fields in the EventHandlerand/or enclosing classes, there needs to be a way do identify the code that should handle the event.
If handle only was a static method, there only would ever be a single handler which even worse would be determined by the JavaFX programmers, since static methods cannot be overridden. It would not be possible to fulfil condition 2. without a non-static method.
For non-static methods however it's pretty simple to deal with this. Methods can be overridden and handling the event the correct way can simply be done by invoking EventHandler.handle for the event handler object.
In java 8 however method references (or lambda expressions) could be used to shorten this a bit by using method references, which allows you to "use a method as interface instance":
public class MyClass {
public static void handleMyButtonAction(ActionEvent evt) {
// (some code)
}
}
myButton.setOnAction(MyClass::handleMyButtonAction);
I've been using dart for quite a while now. If I want to implement dynamic getters, setters and functions for objects of a class, I can make use of the noSuchMethod-method. But what if I now want to have such a dynamic getter, setter of method on class layer? In Ruby, for example, if one wants to implement a dynamic class method, one would define the method_missing-method on the class object, like for example:
class Test
def self.method_missing
//Do some matching, return result or error
end
end
How would I achieve this in Dart?
I don't think you can do this in Dart without mirrors/reflection.
I also don't think this is very useful.
You can't call a static method on a 'dynamic' type and therefore you can't mock static methods.
If you need this you should just make it a normal method instead of a static one.
You can just override noSuchMethod as noticed here
Why is the FxCop rule CA1061 a bad idea?
The docs state that this rule should not be suppressed. If I have class like so:
public class Set<T>
{ List<T> m_backingList;
public bool Contains(T value)
{
return m_backingList.Contains(value);
}
}
then I add a specific implementation like this:
public class CaseInsensitiveSet : Set<String>
{
public bool Contains(object value)
{
string stringValue = value as string;
if (stringValue == null)
return false;
return base.Contains(stringValue);
}
}
the FxCop complains, but I'm not certain why this is such a bad idea. Is there some problem I don't see with this implementation?
The rule states why you're getting the message:
A method in a base type is hidden by
an identically named method in a
derived type when the parameter
signature of the derived method
differs only by types that are more
weakly derived than the corresponding
types in the parameter signature of
the base method.
In your child class, the Contains method takes an object which is more weakly typed than string and therefore hides the parent.
The reason you're getting the warning from FxCop is that this might not be an intentional design choice (since you're not overriding anything or using the new keyword).
Even if it is an intentional design choice, I would argue that it's not necessarily a good one. If you already know that the collection is going to contain strings and nothing else, why would you provide a Contains method that takes anything other than a string? It may appear that you're adding flexibility into the design but, in the end, you're really only going to confuse other developers.
There are also other naming options instead of calling the method Contains which wouldn't hide (intentionally or not) the base Contains method.
Ask yourself: do I want the users to be able to call the base class method on an instance of the derived class.
If the answer is yes: don't hide the base method, as this will make it more cumbersome to use it.
If the answer is no: don't derive from this class, or else they can still access the base method by casting the object to the base class.
http://msdn.microsoft.com/en-us/library/ms182143(VS.80).aspx
A method in a base type is hidden by
an identically named method in a
derived type when the parameter
signature of the derived method
differs only by types that are more
weakly derived than the corresponding
types in the parameter signature of
the base method.
EDIT
Basically you're hiding the base method (public bool Contains in Set), which will never now be run in preference to the derived method. But the derived method is more weakly defined than the base method so there are situations when the base method is the preferable method.
This question is meant to apply to interfaces in general, but I'll use AS3/Flex for my language. It should be [mostly] obvious how to apply it in different languages.
If I create a base class, and it extends an interface, there is an explicit contract defined: for every method in the interface, the base class must implement said method.
This is easy enough. But I don't understand why you have the capacity to cast an interfaced instance back to its original base class. Of course, I've had to do this a few times (the example below is very close to the situation I'm struggling with), but that doesn't mean I understand it :^)
Here's a sample interface:
public interface IFooable extends IUIComponent {
function runFoo():void;
}
Let's say I create a base class, which extends VBox and implements the interface:
public class Foo extends VBox implements IFooable {
public Foo() {
super();
//stuff here to create Foo..blah blah
}
public function runFoo():void {
// do something to run foo
}
}
Now, the reason I used the interface, is because I want to guarantee "runFoo" is always implemented. It is a common piece of functionality all of my classes should have, regardless of how they implement it. Thus, my parent class (an Application) will instantiate Foo via its interface:
public function init():void {
var foo:IFooable = new Foo();
foo.percentHeight = 100; //works because of IUIComponent
}
But, if I want to add Foo to the Application container, I now have to cast it back to the base class (or to a different base class):
public function init():void {
var foo:IFooable = new Foo();
foo.percentHeight = 100;
addChild(foo as DisplayObject); //_have_ to cast, because addChild takes a 'DisplayObject' class type
//could also do this:
//addChild(foo as VBox);
}
Wasn't the original intention to hide the implementation of Foo? There is still an assumption that Foo is a DisplayObject. Unfortunately, being able to add the custom object to a container seems impossible without casting.
Am I missing something entirely? Is this really just a phenomenon in Flex/AS3? If you have a container in the base API of a language, and it only allows you to add children of a certain class type, how do you then abstract out implementation?
For the record, this question appears to ask if this sort of operation is possible, but it doesn't really address why it might be bad design (and how to fix it).
2nd Thought:
Abstract Classes:
As Matthew pointed out, abstract classes helps solve some of this: I could create a base abstract class which inherits from the DisplayObject (or, in my case, the VBox, since it is a child of DisplayObject), and have the base class implement the interface. Thus, any class which extends the abstract class would then be required to implement the methods therein.
Great idea -- but AS3 doesn't have abstract classes (to my knowledge, anyway).
So, I could create a base class which implements interface and extends the VBox, and inherit from it, and I could insert code in those methods which need to be extended; such code would throw an error if the base class is the executor. Unfortunately, this is run-time checking as opposed to compile-time enforcement.
It's still a solution, though.
Context:
Some context might help:
I have an application which can have any number of sub-containers. Each of these sub-containers will have their own respective configuration options, parameters, etc. The application itself, however, has a global ApplicationControlBar which will contain the entry-point Menu for accessing these configuration options. Therefore, whenever I add a sub-component to the main Application (via "addChild"), it will also "register" its own configuration options with the ApplicationControlBar menu. This keeps the knowledge of configurability with the containers themselves, yet allows for a more unified means of accessing them.
Thus, when I create each container, I want to instantiate them via their interface so I can guarantee they can register with the ApplicationControlBar. But when I add them to the application, they need to be the base class.
#James Ward, That's definitely something I wish was in the language, probably a interface IDisplayObject. That would solve a lot of issues in OOP display programing in AS3.
In regards the the original question, something I've used in the past, and have seen mentioned on www.as3dp.com is to include a getDisplay():DisplayObject method in the interface, which would typically return "this" by its implementor. It's less than ideal, but works.
#Matthew Flaschen, While we don't have Abstarct Classes native to AS3, common practice is to name the class with the word Abstract ie: AbstarctMyObject, and then just treat it like the abstarct objects in Java and other languages. Our want for true abstarct classes is something the Flash player team is well aware of, and we'll likly see it in the next version of the ActionScript language.
Okay, I'm anaswering generally, because you said, "Is this really just a phenomenon in Flex/AS3?".
In your init method, obviously you're always calling addChild with foo. That means foo must always be an instance of DisplayObject. You also want it to be an instance of IFooable (though it's not clear here why). Since DisplayObject is a class, you would consider using a subclass of DisplayObject (e.g. FooableDisplayObject), that implemented IFooable. In Java, this would the below. I'm not familiar with AS, but I think this shows there's not any general flaw in interfaces here.
interface IFooable
{
public void runFoo();
}
class DisplayObject
{
}
abstract class FooableDisplayObject extends DisplayObject implements IFooable
{
}
class Foo extends FooableDisplayObject
{
public void runFoo()
{
}
}
public void init()
{
FooableDisplayObject foo = new Foo();
foo.percentHeight = 100;
addChild(foo);
}
I think this is a place where Flex's/Flash's API is not correct. I think that addChild should take an interface not a class. However since that is not the case you have to cast it. Another option would be to monkey patch UIComponent so that it takes an interface or maybe add another method like addIChild(IUIComponent). But that's messy. So I recommend you file a bug.
Situation here is that it should be just the other way around for optimal practice... you shouldn't look to cast your interface to a displayobject but to have your instance already as a displayobject and then cast that to your interface to apply specific methods.
Let's say I have a baseclass Page and other subclasses Homepage, Contactpage and so on. Now you don't apply stuff to the baseclass as it's kind of abstract but you desing interfaces for your subclasses.
Let's say sub-pages implement for example an interface to deal with init, addedtostage, loader and whatever, and another one that deals with logic, and have eventually the base req to be manageble as displayobjects.
Getting to design the implementation.. one should just use an interface for specialized stuff and extend the subclass from where it mainly belongs to.. now a page has a 'base' meaning to be displayed (design wise.. the 'base'-class is a displayobject) but may require some specialization for which one builds an interface to cover that.
public class Page extends Sprite{...}
public interface IPageLoader{ function loadPage():void{}; function initPage():void{}; }
public class Homepage extends Page implements IPageLoader
{ function loadPage():void{/*do stuff*/}; function initPage():void{/*do stuff*/}; }
var currentpage:Page;
var currentpageLoader:IPageLoader;
currentpage = new Homepage;
currentpageLoader = currentpage as IPageLoader;
currentpageLoader.loadPage();
currentpageLoader.initPage();
addChild(currentpage);
Tween(currentpage, x, CENTER);