The setup, java 8 using lombok, meanbean and equalsverifier(huge fan of all 3, and also limited in what versions I can use per co. policy - on 2.3.3 of equalsverifier):
#Data
#NoArgsConstructor
class A {...}
#Data
#NoArgsConstructor
class B extends class A {...}
I get the Significant fields error calling EqualsVerifier:
EqualsVerifier.forClass(B.class)
.withRedefinedSuperclass()
.suppress(Warning.STRICT_INHERITANCE, Warning.NONFINAL_FIELDS, Warning.INHERITED_DIRECTLY_FROM_OBJECT).verify();
Changed class B as follows, and got redefined superclass error instead:
#NoArgsConstructor
#ToString(callSuper=false)
class B extends class A {...}
Changed class B again as follows, and got significant fields error instead:
#NoArgsConstructor
#ToString(callSuper=false)
#EqualsAndHashCode(callSuper=false)
class B extends class A {...}
Any suggestions? I don't know how to get passed this one.
Creator of EqualsVerifier here.
I don't quite have enough information to be able to help you -- what fields doe A and B have? Also, I'm not sure if Lombok's #Data can be inherited; you'll have to check their documentation or run some experiments.
That said, combining equals with inheritance correctly is hard to get right. The advice I usually give people is, don't do it. If you have to, I've written something about it in the EqualsVerifier manual. I'd also recommend reading this article for some background info.
As general rules of thumb:
Always call super in your equals methods if you override them and intend to add state.
Make your classes final if you don't need to extend from them. In this case, B could be final, which would make it easier for you to appease EqualsVerifier.
If you don't know what code Lombok generates, use Delombok.
Related
I couldn't understand the difference between these two keywords.
By using extends we can get features from parent class. I think implements does that too.
First I thought the difference is overriding methods but with extends I can do that.(I might be wrong)
Is the difference of these two keywords about overriding methods or what? Thank you
extends means we get the implementation of a given class and we can then override members if we want our own implementation for certain variables or methods. You can also add new variables and methods.
implements means you get nothing from the class you implement from. But you promise that your class will be compatible with the interface of the class you are implementing. So no, you are not getting any implementation from the super class and you need to implement everything or declare your class abstract.
I have a class that extends another. The parent class is not intended to be used directly by the API rather it implements basic methods that are helpers for child classes.
When I use the child class in a program I can see all method from said class but also the one from the parent class that are not intended to be called directly, they exist to be called by the methods of the child class.
I tried to make parents method private. This would work I believe as long as parent and child are declared in the same library. But I have an issue with the "library" notion. I understand part/part of are somewhat depreciated, and I want the parent class to be in a specific file. I can't figure a way to do it with import/export.
Is there a way to either hide a public method from the parent class from all child classes usage or to make a private method from the parent class callable from all child classes ?
Best regards ;
Exemple:
myLib.dart
export mainClass.dart;
mainClass.dar
import baseClass.dart;
class MainClass extends BaseClass {
publicFunc() => ... //Can't call _hiddenFunc, can call wantToHideFunc()
}
In a second file (for code reusability purposes)
class MainClass extends BaseClass {
_hiddenFunc() => ...
wantToHideFunc() => ...
}
Using myLib public API
import myLib.dart
main() {
class = Class();
class.publicFunc(); //Intended
class.wantToHideFunc() //Wants to avoid...
}
Dart does not have protected access like Java or C#.
You can't hide a public member, you can't access a private member from a different library, and there is no third option.
It sounds like you want members of the superclass which can be invoked only from subclasses, not from outside of the object. That's what's called protected in, e.g., Java, and Dart does not have anything similar to that.
The only level of privacy in Dart is library-private, which is chosen by starting the name with a _.
The reason that Dart has this design is that it was originally a very dynamic language. You can preform "dynamic invocations" on a value with static type dynamic, say dynVal.foo(42) and it will call the method of that name.
To make a name unreachable, it needed to be safe from dynamic invocation as well. Because of that, Dart privacy does not care where the code doing the invocation is, it only cares whether you know the name - and library private names are considered different names depending on which library they're from.
Using part is not discouraged for situations where it actually serves a purpose. If you can put the part into a library of its own, that's better because it allows it to have its own privacy and imports, but if you need the classes to share privacy, using part files to split up a large file is perfectly reasonable. It's a tool, there is nothing wrong with using it when it's the right tool for the job. A library is often a better tool for modularity, but not always.
Now, there is a hack you can use:
// Declare the base and provide extensions for "protected" members:
abstract class Base {
int get _someHiddenStuff => 42;
int get somePublicStuff => 37;
}
extension ProtectedBase on Base {
int get someHiddenStuff => _someHiddenStuff;
}
Then import that in another library and do:
import "base.dart";
export "base.dart" hide ProtectedBase;
class SubClass extends Base {
int doSomething => someHiddenStuff + somePublicStuff;
}
Then anyone importing "subclass.dart" will also get a version of Base, but they won't get the ProtectedBase extensions. Hiding the extensions from your package's public API will allow yourself to use it, but prevent your package's users from seeing the helper extensions.
(This is likely highly over-engineered, but it's an option. It's the evolution of the hack of having static/top-level helper functions that you don't export.)
I have copied full Random class from math.dart package, gave it CustomRandom name, and now I don't see why my code fails to work.
abstract class CustomRandom {
external factory CustomRandom([int seed]);
external factory CustomRandom.secure();
int nextInt(int max);
double nextDouble();
bool nextBool();
}
I'm using it like
print("${Random().nextInt(10)}"); // standard one works
print("${CustomRandom().nextInt(10)}"); // my one fails
I know there are other things going around with standard class which isn't visible in code, but how can I make my class to work?
Your version won't do anything because it has no implementation.
The real Random class has an external factory constructor (whose implementation lives elsewhere, one for the Dart VM/runtime, one for JavaScript) and that implementation instantiates an object that actually does something.
For customizing Random class, The external factory class must me declared somewhere else.
The main reason behind working of "Random" class is that its eternal factories are defined somewhere else, and being used in Random class.
While the reason behind not working of your "CustomRandom" class is that you are missing the implementation of your external factory "CustomRandom" anywhere.
Apparent solutions:
1) Keep class name CustomRandom but keep external factory name unchanged same as "Random" class.
2) Create own external factory and use here.
Is it possible to apply a mixin to a class without the target class inheriting from any other class? For example, can I implement the following:
class User with Persistence {
// implementation
}
Most of your examples of Mixins in dart seem to be coupled with inheritance.
Thanks in advance!
You have to inherit from another class if you want to use a mixin. However, you can simply inherit from Object:
class User extends Object with Persistence {
// implementation
}
But really, you can just inherit from Persistence as well which will have the same effect:
class User extends Persistance {
// implementation
}
Gilad Bracha explains that the syntax is specifically designed this way:
I think it is important to understand the semantic model here. "with"
is the mixin application operator, and it takes two parameters: a
superclass and a mixin, and yields a class. Saying "with Foo" in
isolation makes as much sense as saying >> 2 (you could interpret both
as curried functions, but that is very far from Dart). When you write
"C extends S with M", you are specifying a superclass following the
extends keyword, just as you do when you write "C extends K" except
that the superclass is not specified via an identifier but via a mixin
application. So the superclass would be "S with M".
As Lasse points out, as practical matter it doesn't restrict you, but
having the syntax reflect the underlying structure is important.
I have a question regarding dependency injection.
say i want to create a class
call it, WebGetTask
WebGetTask would need a dependency to HttpService
bad code 1
Code:
private HttpService httpService;
...
List<WebGetTask> list = new ArrayList<WebGetTask>();
for(...)
{
list.add(new WebGetTask(httpService));
}
...
ok. i know this is bad, because httpService is injected, but its never used, except for the creation on a new WebGetTask
ok
bad code 2
Code:
private WebGetTaskFactory webGetTaskFactory;
...
List<WebGetTask> list = new ArrayList<WebGetTask>();
for(...)
{
list.add(webGetTaskFactory.newTask());
}
...
i think this is better, because we use a factory
but...
but..
from where i'm standing,
i can see that
in WebGetTaskFactory
we are still injecting a HttpService and not doing anything to it except for the sole purpose of creating a new WebGetTask
so
to recap
my question is
how do i design a factory class (WebGetTaskFactory), that creates new objects (WebGetTask) when the new objects require a dependency (HttpService) on their constructor without simply injecting and passing the dependency (HttpService) ?
or rather, is this the way to do it? if so, then it's all good, if its not, then please guide me to how to properly use DI and factory pattern.
thanks.
I'm going to assume that the code you have shown is part of a DownloadManager class, and that you inject your dependencies via the constructor. In this case, I would expect the start-up code which glues everything together to look like this:
IHttpService httpService = new HttpService();
IWebGetTaskFactory webGetTaskFactory = new WebGetTaskFactory(httpService);
IDownloadManager downloadManager = new DownloadManager(webGetTaskFactory);
The DownloadManager class only knows about the IWebGetTaskFactory interface. It does not know about IHttpService, thus satisfying the law of Demeter.
edit: After re-reading your question, it seems that you are worried that you are not "using" the HttpService in your factory, except to pass it on to a new WebGetTask. This is OK. Both WebGetTaskFactory and WebGetTask need an HttpService instance to do their job. This is not a violation of the law of Demeter.
Okay, there's nothing specifically wrong under the LoD about passing an implementation object, a "plugin" in the constructor. What's important is that the interface of the class doesn't tell you much about that implementation.
If your interface to WebGetTask depends on the exact implementation of HttpService, that violates the Law of Demeter.
The trick here is to think about the interface signature of WebGetTask. The name itself suggests that you're not quite following the Law of Demeter — or principle of least knowledge — because you're defining a class that (1) is defined as being specific for the web, and (2) is a verb instead of a noun.
Now, neither of those is necessarily wrong, but they are both "OO smells" if you will, signs that you may not be thinking object-ly enough.
So let's try "refactoring" the design. First thing, think about a GetTask that has no "web" associated with it. You can then, either at construction time or at some later time build a service object and pass it in. If it's HttpService, that's fine, but the user of your class doesn't need any information about what's under the covers.
Second thing, let's make it a noun. Call it TaskFactory — your intuition was leading you right there — with a ctor that takes an IOService, which I've just invented as being the abstract interface implemented by HttpService.
Now, you have (this is sort of Java/C++ pseudocode, don't get excited about syntax details):
class Task { ... }
class TaskFactory {
public TaskFactory(IOServer svc){...}
public Task get(){...}
}
and you use it by writing
TaskFactory fac = new TaskFactory(new HttpService());
Task tsk = fac.get();
Now, we kow the minimum about the innards of TaskFactory, the IO service, and for that matter Tasks.
There are two ways of DI: the first one is a constructor one, which is usefull when only one or two objects are injected, and a setter one (actually as many setters as needed).
If you want to use a factory method for DI than in principle its same as a constructor based one.
Example 1, for a constructor DI:
list.add( new WebGetTask( httpService ) ) ;
Example 2, for a setter DI:
WebGetTask webGetTask = new WebGetTask();
webGetTask.setHttpService(httpService);
// set other dependencies
list.add(webGetTask);
The factory method is best for when you need to use some greater logic when creating objects that may behave differently, but have the same interface, thus the LoD. Lets assume there is a DownloadManager interface implemented dynamically based on the factory parameter(s).
Example 3, creation logic encapsulated into a factory method:
public static DownloadManager createDownloadManager(HttpService httpService){
if(null!=httpService){
WebGetTask webGetTask = new WebGetTask();
webGetTask.setHttpService(httpService);
// set other dependencies
return new DownloadManagerImpl1(webGetTask);
} else {
return new DownloadManagerImpl2();
} // if-else
}