I was checking Equatable package "how to use" examples and they pass values to the super class, and this subject like a blind spot for me, and I see it everywhere:
import 'package:equatable/equatable.dart';
class Person extends Equatable {
final String name;
// why? what's happening behind the scene here?
Person(this.name) : super([name]);
}
another example
#immutable
abstract class MyEvent extends Equatable {
MyEvent([List configs = const []]) : super(configs);
}
1- why we do that? why to pass values for abstract thing? for a blueprint? what's the use of this?
2- why sometimes developers pass values for abstract class like this?
3- what's happening behind the scene here?
4- what is the use cases for such a code?
thanks a lot.
A class being abstract doesn't exclude that it has some concrete members in Dart.
Take the following class as an example:
abstract class Foo {
Foo(this.value);
final int value;
#override
String toString() => value.toString();
}
While it is abstract, it has a concrete implementation of the property value, that is initialized via a custom constructor.
And since the parameter is required, the subclass must call the super constructor like so:
class Subclass extends Foo {
Subclass(): super(42);
}
Related
sealed class DestinationScreen(val route:String){
object Signup: DestinationScreen(route = "signup")
}
Now I am developing navigation screen above.
I don't understand this statement.
object Signup: DestinationScreen(route = "signup")
I think Signup is property. So to set it, should we write this below?
object Signup = DestinationScreen(route = "signup")
Why does not using = issue the instance and set the Signup property?
Please teach me. Thank you.
Nope. Signup is not a property. It's basically a class which extends DestinationScreen except it's a special class object which acts as a singleton and is initiated at the same point it's described. That's why you write it like that.
Why it looks like a property to you is you happen to declare it in another class (which makes it an inner class). But you can declare it outside of the class too.
More about Kotlin objects https://kotlinlang.org/docs/object-declarations.html
Sealed classes represent a class with a fixed number of subclasses. At first, you declare the parent class, for example, a class that describes Screen of your app. Then, you declare all children of this class. For example, HomeScreen and LoginScreen:
sealed class Screen
class HomeScreen : Screen()
class LoginScreen : Screen()
All subclasses can be written outside of the parent class (but must be located in the same file due to compiler limitations).
You can use the object keyword instead of class modifier in case of a class has no properties. It means that the object keyword declares a singleton class.
Because you are using inheritance, not an assigment.
A sealed class is a class which subtypes are known by the compiler so it allows you to create flow controls by type:
sealed class Result {
data class Success(val data...): Result()
data class Error(val exception...): Result()
}
So you can do:
when(val result = ...) {
is Success -> result.data
is Error -> result.error
}
Whith normal inheritance like on interfaces, open classes or abstract classes you dont know the typed thar inherit from the super type.
abstract class MyClass() {
protected static foo: Array<number>;
protected static doWorkOnFoo(): void {
let x: number = 0;
for (let f of | what goes here? this? self?|.foo) {
x = x + foo;
}
}
}
When implementing an abstract class, and wanting derived classes to have a static property and a static method that operates on those properties, how would one access those in the abstract class so that the derived class can just use that method?
I know this can be worked around by just setting a default value on the static property and using this, but this sparked my interested and I'm curious to know if there's some way to access generic derived class or something from an abstract class in TS.
Thanks in advance!
EDIT:
While I wasn't able to find exactly what I was looking for (see comments), a workable solution is to change the signature of the doWorkOnFoo() method to the following:
protected static doWorkOnFoo(): (typeof MyClass) => void;
Since it is already an abstract class it can take a derived class as an argument and then reference the derived class's static properties.
As far as I've understood in Dart is possible to use abstract classes to declare "interfaces" or "protocols" (if you come from objective-c).
Anyway I'm having trouble in finding a way to declare an optional method in the abstract class/interface.
If I declare a method in the abstract class A, and let the concrete class B implement A, I get a warning in the compiler.
I'd like to be able to declare a method as optional or at least to provide a default implementation without needing to "re-declare" it in a class that implements my interface.
abstract class A{
void abstractMethod();
}
class B implements A{
//not implementing abstract method here gives a warning
}
That's not how interfaces work. If your class states to implement an interface, then this is what it has to do.
You can split the interface
abstract class A {
void abstractMethod();
}
abstract class A1 extends A {
void optionalMethod();
}
class B implements A {
//not implementing abstract method here gives a warning
}
only when it states to implement A1 it has to implement optionalMethod.
Alternatively you can extend the abstract class
abstract class A{
void abstractMethod();
void optionalMethod(){};
}
class B extends A {
//not implementing abstract method here gives a warning
}
then only abstractMethod needs to be overridden because A doesn't provide an implementation.
Abstract methods defined in classes cannot be marked as optional. (At least not in the regular Dart language, I don't know of annotations that might support something like this.)
Any class that implements an interface must provide an implementation of all abstract methods, but, those method implementations may trivially throw an error to indicate that the method is not available.
Throw UnimplementedError if the implementing class is incomplete and the proper implementation is to be added later
Throw UnsupportedError if the implementing class does not intend to implement the method.
Note that UnimplementedError implements UnsupportedError.
Obviously you have to be judicious about what you choose to not implement. If it's in code that is not intended to be shared you can get away only implementing methods that you explicitly know are required. If it's in a library package intended to be shared with others you would need a good reason to not implement a method, and that reason should be well documented.
Example code:
abstract class A {
void abstractMethod();
}
class B implements A {
void abstractMethod() { throw new UnimplementedError(...); }
// or
void abstractMethod() { throw new UnsupportedError(...); }
}
See:
https://api.dartlang.org/stable/1.18.1/dart-core/UnimplementedError-class.html
https://api.dartlang.org/stable/1.18.1/dart-core/UnsupportedError-class.html
I have an abstract base class and an implementation class like:
public abstract class Base
{
public Base getInstance( Class<? extends Base> clazz )
{
//expected to return a singleton instance of clazz's class
}
public abstract absMeth();
}
public A extends Base
{
//expected to be a singleton
}
In this example I can make A to be a singleton and even write getInstance in Base to return a singleton object of A for every call, doing this way:
public abstract class Base
{
public Base getInstance( Class<? extends Base> clazz )
{
try
{
return clazz.getDeclaredMethod("getInstance").invoke(null,null);
}
}
public abstract void absMeth();
}
public A extends Base
{
private static A inst;
private A(){}
public static A getInstance( )
{
if( inst!= null)
inst = new A();
return inst;
}
public void absMeth(){
//...
}
}
But my concern is how do I ensure that if somebody writes another class class B extends Base it should also be a singleton and it necessarily implements a static method called getInstance?
In other words I need to enforce this as a specification for all classes extending with the Base class.
You cannot trust classes that extend you to create a single instance of themselves1: even if you could somehow ensure that they all implement getInstance, there is no way to tell that inside that method they check inst before constructing a new instance of themselves.
Stay in control of the process: create a Map<Class,Base>, and instantiate the class passed in through reflection2. Now your code can decide whether to create an instance or not, without relying on the getInstance of a subclass.
1 A popular saying goes, "If you want a job done right, do it yourself."
2 Here is a link describing a solution based on setAccessible(true)
Singleton is a design pattern, not a language feature. It is pretty much impossible to somehow enforce it on the inheritance tree through syntax.
It certainly is possible to require all subclasses to implement a method by declaring it abstract but there is no way to control implementation details. Singleton is all about implementation details.
But why is this a concern at all? Do not make your app dependant on internal details of someone else's code. It is Bad Design™ and having this issue is a sure sign of it. Code against a well-defined interface and avoid relying on internal details.
i have Abstract class
Public class Abstract baseClass
{
public abstract string GetString();
public abstract string GetString1();
}
public class DerivedClass : baseClass
{
public override string GetString()
{
return "test data";
}
public override string GetString1()
{
throw new NotImplementedException();
}
}
In above line of code, i have to implement both abstract method in derived class. But due to some reason i don't want to implement all methods, just one of them like GetString() only. How can it be done?
Thanks
If DerivedClass is going to offer common functionality to other classes, you can mark it as abstract, implement one of the methods here, and then inheritors will only have to implement the remaining method.
If you aren't going to support the other method in a given implementation, you still have to expose the method in your class, but similar to what you have here, you would typically throw a NotSupportedException. For void methods, you could simply return (do nothing).
Finally, if you want to separate out the things that have both methods and those that have only one, you can use interfaces.
public interface IBase
{
string GetString();
}
public interface IBasePlus : IBase
{
string GetStringPlus();
}
You can have one class that implements IBasePlus, but you can supply this to methods that take a parameter of type IBase, in which case you won't see the extra method.
Generally, if you don't implement all the abstract methods then your new class is also an abstract class. To get a concrete class, you need all the methods to be implemented. If you only want/need to implement a subset of the methods, consider using multiple interfaces (one interface with GetString and another with GetString1) rather than an abstract class. Then you can just implement the interfaces with the methods you want to use in the class.
Take the abstract keyword off the other method and provide a default implementation in the base class