Update for Angular 10+ As of Angular 10, when using the IVY compiler, components that are inherited, and which contain Angular functionality, must be decorated with an empty @Directive() decorator. Read more about it here There’s no need to add @Component() annotations to abstract classes or register them to any module. It could be that …
I haven’t seen the content at urban potato (its down) but Me and Smelch came up with a solution. Form itself inherits from an abstract class, so what they dont tell you is that its only the 1st level of inheritance that can’t be abstract, the 2nd on down can. From there its simply a …
You can’t. The place to do this is with Attributes. Eg [Name(“FooClass”)] class Foo { }
I don’t see anything wrong with this approach. You might have some basic type that can be described in concrete terms. Now, just because an object of this type might be further classified according to some subtype, it does not follow that all such subtypes are just as concrete; they may in turn require further …
You can’t get much simpler than using an enum with no instances. public enum MyLib {; public static void myHelperMethod() { } } This class is final, with explicitly no instances and a private constructor. This is detected by the compiler rather than as a runtime error. (unlike throwing an exception)
No it is not – you are instantiating a Dog, but since a Dog is an Animal, you can declare the variable to be an Animal. If you try to instantiate the interface Animal it would be: Animal baby2 = new Animal(); Try that, and watch the compiler scream in horror 🙂
For dynamic (runtime) polymorphism, I would recommend using the Non-Virtual-Interface (NVI) idiom. This pattern keeps the interface non-virtual and public, the destructor virtual and public, and the implementation pure virtual and private class DynamicInterface { public: // non-virtual interface void fun() { do_fun(); } // equivalent to “this->do_fun()” // enable deletion of a Derived* through …
Abstract methods are supposed to be less useful in Ruby because it’s not strongly statically typed. However, this is what I do: class AbstractThing MESS = “SYSTEM ERROR: method missing” def method_one; raise MESS; end def method_two; raise MESS; end end class ConcreteThing < AbstractThing def method_one puts “hi” end end a = ConcreteThing.new a.method_two …
Things are not so simple. If a class implements multiple interfaces that defines default methods with the same signature the compiler will force you to override this method for the class. For example with these two interfaces : public interface Foo { default void doThat() { // … } } public interface Bar { default …
This is a correct implementation; you should use static, not self, in order to use late static bindings: abstract class AbstractFoo{ public static function foo() { throw new RuntimeException(“Unimplemented”); } public static function getFoo(){ return static::foo(); } } class ConcreteFoo extends AbstractFoo{ public static function foo(){ return “bar”; } } echo ConcreteFoo::getFoo(); gives the expected …