I am writing a payment service class in Dart that wraps more than 1 payment provider. The expectation is the caller can simply switch one to another without any hassle.
Let's imagine I have classes like this:
enum PaymentProvider { providerA, providerB }
abstract class PaymentService {
void processPayment(Order oder);
}
class PaymentServiceA implements PaymentService {
final String appKey;
final String merchantId;
PaymentServiceA(this.appKey, this.merchantId);
#override
void processPayment(Order oder) {
// concrete implementation to process payment
}
String getVoucher() {
// return voucher code
}
}
class PaymentServiceB implements PaymentService {
final PaymentBOptions options;
PaymentServiceB(this.options);
#override
void processPayment(Order oder) {
// concrete implementation to process payment
}
List<PaymentBHistory> getPaymentHistory() {
// return payment history
}
}
class PaymentBOptions {
final bool sendEmailReceipt;
final Function()? successCallback;
PaymentBOptions(this.sendEmailReceipt, this.successCallback);
}
So here PaymentServiceA and PaymentServiceB have same method (processPayment) so we can create base class PaymentService and let them implements this base class.
However as you can see each of them also has different constructor parameter and specific methods.
How is the best approach to create PaymentService that wrap more than 1 provider like this?
I was trying to use factory pattern like this:
abstract class PaymentService {
factory PaymentService(PaymentProvider provider) {
switch(provider) {
case PaymentProvider.providerA:
String appKey = "xxxx";
String merchantId = "123"
return PaymentServiceA(appKey, merchantId);
case PaymentProvider.providerB:
PaymentBOptions options = PaymentBOptions(() {
});
return PaymentServiceB(options);
}
}
void processPayment(Order order);
}
But I don't think this is the good practice because:
If we create PaymentServiceA or PaymentServiceB instance using PaymentService factory method it will return as PaymentService and we need to cast to appropriate class in order to access specific PaymentService method.
We can't supply specific constructor parameter of PaymentServiceA or PaymentServiceB outside PaymentService abstract class via factory constructor.
Any idea on how is the best practice and what's the suitable design pattern when facing this kind of scenario?
Thanks.
How can I have an abstract private method in dart?
// person.dart
abstract class Person{
void _walk(); //Abstract Method
void _talk(); //Abstract Method
}
// jay.dart
import "person.dart";
class Jay extends Person{
#override
void _walk() {
print("Jay can walk");
}
#override
void _talk() {
print("Jay can talk");
}
}
I want to hide _walk and _talk from Jay instance
package:meta provides a #visibleForOverriding annotation that might do what you want. Note that violating it will generate only an analysis warning, and it won't be enforced at runtime.
Personally I think that putting things that are meant to be private in the abstract base class is a bad idea since they shouldn't be part of the interface. Consider instead doing:
abstract class Person {
...
}
abstract class _Person extends Person {
void walk();
void talk();
}
and now your library can internally derive classes from _Person and use walk and talk, and they won't be exposed at all to external consumers of your library.
Say I have the following Annotation and 2 classes:
class AppModel extends Reflectable {
final String name;
const AppModel([this.name])
: super(newInstanceCapability, metadataCapability);
}
const appModel = const AppModel();
#appModel
class ImGonnaBePickedUp {
}
#AppModel(' :( ')
class AndImNotPickedUpOnServer_IDoOnWebClient {
}
main() {
appModel.annotatedClasses // that's what I mean by "Picked Up".
}
On CmdApp side (Server): only AndImNotPickedUpOnServer_IDoOnWebClient is given in appModel.annotatedClasses.
On the web side, both classes are given.
Long story short, how do I retrieve classes annotated with direct const constructor calls like in the example above #AppModel(' :( ') (for both CmdApp and Web)?
since version 0.5.4 reflectable classes doesn't support constructors with arguments
This appears in reflectable documentation:
Footnotes: 1. Currently, the only setup which is supported is when the metadata object is an instance of a direct subclass of the class [Reflectable], say MyReflectable, and that subclass defines a const constructor taking zero arguments. This ensures that every subclass of Reflectable used as metadata is a singleton class, which means that the behavior of the instance can be expressed by generating code in the class. Generalizations of this setup may be supported in the future if compelling use cases come up.
one possible solution could be to use a second annotation to handle the name, for example:
import 'package:reflectable/reflectable.dart';
import 'package:drails_commons/drails_commons.dart';
class AppModel extends Reflectable {
const AppModel()
: super(newInstanceCapability, metadataCapability);
}
const appModel = const AppModel();
class TableName {
final String name;
const TableName(this.name);
}
#appModel
class ImGonnaBePickedUp {
}
#appModel
#TableName(' :( ')
class AndImNotPickedUpOnServer_WorksOnWebClient {
}
main() {
print(appModel.annotatedClasses); // that's what I mean by "Picked Up".
print(new GetValueOfAnnotation<TableName>()
.fromDeclaration(appModel.reflectType(AndImNotPickedUpOnServer_WorksOnWebClient)).name);
}
Note: I'm also using drails_common package
A few times now I've run into a use case where I need to define an interface for how classes construct themselves. One such example could be if I want to make an Interface Class that defines the interface by which objects can serialize and unserialize themselves (for input into a database, to be sent as JSON, etc). You might write something like this:
abstract class Serializable {
String serialize();
Serializable unserialize(String serializedString);
}
But now you have a problem, as serialize() is properly an instance method, and unserialize() should instead be a static method (which isn't inheritable or enforced by the Interface) or a constructor (which also isn't inheritable).
This leaves a state where classes that impliment the Serializable interface are required to define a serialize() method, but there is no way to require those classes to define a static unserialize() method or Foo.fromSerializedString() constructor.
If you make unserialize() an instance method, then unserializing an implementing class Foo would look like:
Foo foo = new Foo();
foo = foo.unserialize(serializedString);
which is rather cumbersome and ugly.
The only other option I can think of is to add a comment in the Serializable interface asking nicely that implementing classes define the appropriate static method or constructor, but this is obviously prone to error if a developer misses it and also hurts code completion.
So, is there a better way to do this? Is there some pattern by which you can have an interface which forces implementing classes to define a way to construct themselves, or something that gives that general effect?
You will have to use instance methods if you want the inheritance guarantees. You can do a bit nicer than manual instantiation though, by using reflection.
abstract class Serializable {
static Serializable fromSerializedString(Type type, String serializedString) {
ClassMirror cm = reflectClass(type);
InstanceMirror im = cm.newInstance(const Symbol(''), []);
var obj = im.reflectee;
obj.unserialize(serializedString);
return obj;
}
String serialize();
void unserialize(String serializedString);
}
Now if someone implements Serializable they will be forced to provide an unserialize method:
class Foo implements Serializable {
#override
String serialize() {
// TODO: implement serialize
}
#override
void unserialize(String string) {
// TODO: implement unserialize
}
}
You can get an instance like so:
var foo = Serializable.fromSerializedString(Foo, 'someSerializedString');
This might be a bit prettier and natural than the manual method, but keep in mind that it uses reflection with all the problems that can entail.
If you decide to go with a static method and a warning comment instead, it might be helpful to also provide a custom Transformer that scans through all classes implementing Serializable and warn the user or stops the build if any don't have a corresponding static unserialize method or constructor (similar to how Polymer does things). This obviously wouldn't provide the instant feedback the an editor could with instance methods, but would be more visible than a simple comment in the docs.
I think this example is a more Dart-like way to implement the encoding and decoding. In practice I don't think "enforcing" the decode signature will actually help catch bugs, or improve code quality. If you need to make the decoder types pluggable then you can make the decoders map configurable.
const Map<String,Function> _decoders = const {
'foo': Foo.decode,
'bar': Bar.decode
};
Object decode(String s) {
var obj = JSON.decode(s);
var decoder = _decoders[obj['type']];
return decoder(s);
}
abstract class Encodable {
abstract String encode();
}
class Foo implements Encodable {
encode() { .. }
static Foo decode(String s) { .. }
}
class Bar implements Encodable {
encode() { .. }
static Foo decode(String s) { .. }
}
main() {
var foo = decode('{"type": "foo", "i": 42}');
var bar = decode('{"type": "bar", "k": 43}');
}
A possible pattern I've come up with is to create a Factory class that utilize instance methods in a slightly less awkward way. Something like follows:
typedef Constructable ConstructorFunction();
abstract class Constructable {
ConstructorFunction constructor;
}
abstract class Serializable {
String serialize();
Serializable unserialize(String serializedString);
}
abstract class SerializableModel implements Serializable, Constructable {
}
abstract class ModelFactory extends Model {
factory ModelFactory(ConstructorFunction constructor) {
return constructor();
}
factory ModelFactory.fromSerializedString(ConstructorFunction constructor, String serializedString) {
Serializable object = constructor();
return object.unserialize(serializedString);
}
}
and finally a concrete implementation:
class Foo extends SerializableModel {
//required by Constructable interface
ConstructorFunction constructor = () => new Foo();
//required by Serializable interface
String serialize() => "I'm a serialized string!";
Foo unserialize(String serializedString) {
Foo foo = new Foo();
//do unserialization work here to populate foo
return foo;
};
}
and now Foo (or anything that extends SerializableModel can be constructed with
Foo foo = new ModelFactory.fromSerializedString(Foo.constructor, serializedString);
The result of all this is that it enforces that every concrete class has a method which can create a new instance of itself from a serialized string, and there is also a common interface which allows that method to be called from a static context. It's still creating an extra object whose whole purpose is to switch from static to instance context, and then is thrown away, and there is a lot of other overhead as well, but at least all that ugliness is hidden from the user. Still, I'm not yet convinced that this is at all the best way to achieve this.
I suggest you define the unserialize function as named constructor like so:
abstract class Serializable<T> {
String serialize();
Serializable.unserialize(String serializedString);
}
This eliminates the need of static methods.
A possible implementation could look like this:
import 'dart:convert';
class JsonMap implements Serializable<JsonMap> {
Map map = {};
JsonMap() {
}
String serialize() {
return JSON.encode(map);
}
JsonMap.unserialize(String serializedString) {
this.map = JSON.decode(serializedString);
}
}
You can (de)serialize like so:
JsonMap m = new JsonMap();
m.map = { 'test': 1 };
print(m.serialize());
JsonMap n = new JsonMap.unserialize('{"hello": 1}');
print(n.map);
While testing this, I noticed that Dart will not throw any errors at you if you dont actually implement the methods that your class promises to implement with implements. This might just be a hicc-up with my local Dart, though.
I am porting some Java-code to Dart and it heavily uses these kinds of maps:
Map<Class<? extends SomeClass>, SomeOtherClass> map = new HashMap<>();
At the moment this seems to be impossible in dart. I am aware that there is a proposal to introduce first level types: http://news.dartlang.org/2012/06/proposal-for-first-class-types-in-dart.html which would introduce
class Type {
#native String toString();
String descriptor(){...} // return the simple name of the type
}
So until this proposal gets implemented I have created following class:
class Type {
final String classname;
const Type(this.classname);
String descriptor() => classname;
}
and the classes where I need it have a simple get-method
abstract Type get type();
That way I can use my Type just like I would use the real Type and to switch later I'd just have to delete my workaround.
My question: Is there some dart-way of doing this kind of mapping (which I am not seeing) or is the way I do it a reasonable workaround until the real Type class gets introduced?
Update for Dart 1.0
It can be done this way:
var map = new Map<Type, SomeOtherClass>();
// either
map[SomeOtherClass] = new SomeOtherClass();
// or
var instance = new SomeOtherClass();
map[instance.runtimeType] = instance;
Update: this construction is not currently doable in Dart
Map<Class<? extends SomeClass>, SomeOtherClass>
you will have to wait for .type/.class to arrive for an elegant solution to this (lots of us Dartisans are hoping that this will arrive sooner rather than later). However for the simpler case
Map<? extends SomeClass, SomeOtherClass>
You can just do
Map<SomeClass, SomeOtherClass> aMap;
as in Dart any class that extends SomeClass is also going to be a valid SomeClass. For example if you run the following code in checked mode:
main() {
Map<Test, String> aMap = new HashMap<Test, String>();
var test = new Test("hello");
var someTest = new SomeTest("world");
var notATest = new NotATest();
aMap[test] = test.msg;
aMap[someTest] = someTest.msg;
aMap[notATest] = "this fails";
}
class Test implements Hashable {
Test(this.msg);
int hashCode() => msg.hashCode();
final String msg;
}
class SomeTest extends Test {
SomeTest(String message): super(message);
}
class NotATest implements Hashable {
int hashCode() => 1;
}
then you you will get the error:
type 'NotATest' is not a subtype of type 'Test' of 'key'.