In Java, it is very common to have a list of utility functions
public class Utils {
private Utils() {
}
public static void doSomething() {
System.out.println("Utils")
}
}
If I were in Swift, should I use class or struct to achieve the similar thing? Or, it really doesn't matter?
class
class Utils {
private init() {
}
static func doSomething() {
print("class Utils")
}
}
struct
struct Utils {
private init() {
}
static func doSomething() {
print("struct Utils")
}
}
I think a conversation about this has to start with an understanding of dependancy injection, what it is and what problem it solves.
Dependancy Injection
Programming is all about the assembly of small components into every-more-abstract assemblies that do cool things. That's fine, but large assemblies are hard to test, because they're very complex. Ideally, we want to test the small components, and the way they fit together, rather than testing entire assemblies.
To that end, unit and integration tests are incredibly useful. However, every global function call (including direct calls to static functions, which are really just global functions in a nice little namespace) is a liability. It's a fixed junction with no seam that can be cut apart by a unit test. For example, if you have a view controller that directly calls a sort method, you have no way to test your view controller in isolation of the sort method. There's a few consequences of this:
Your unit tests take longer, because they test dependancies multiple times (e.g. the sort method is tested by every piece of code that uses it). This disincentivizes running them regularly, which is a big deal.
Your unit tests become worse at isolating issues. Broke the sort method? Now half your tests are failing (everything that transitively depends on the sort method). Hunting down the issue is harder than if only a single test-case failed.
Dynamic dispatch introduces seams. Seams are points of configurability in the code. Where one implementation can be changed taken out, and another one put in. For example, you might want to have a an MockDataStore, a BetaDataStore, and a ProdDataStore, which is picked depending on the environment. If all 3 of these types conform to a common protocol, than dependant code could be written to depend on the protocol that allows these different implementations to be swapped around as necessary.
To this end, for code that you want to be able to isolate out, you never want to use global functions (like foo()), or direct calls to static functinos (which are effectively just global functions in a namespace), like FooUtils.foo(). If you want to replace foo() with foo2() or FooUtils.foo() with BarUtils.foo(), you can't.
Dependancy injection is the practice of "injecting" dependancies (depending on a configuration, rather than hard coding them. Rather than hard-coding a dependancy on FooUtils.foo(), you make a Fooable interface, which requires a function foo. In the dependant code (the type that will call foo), you will store an instance member of type Fooable. When you need to call foo, call self.myFoo.foo(). This way, you will be calling whatever implementation of Fooable has been provided ("injected") to the self instance at the time of its construction. It could be a MockFoo, a NoOpFoo, a ProdFoo, it doesn't care. All it knows is that its myFoo member has a foo function, and that it can be called to take care of all of it's foo needs.
The same thing above could also be achieve a base-class/sub-class relationship, which for these intents and purposes acts just like a protocol/conforming-type relationship.
The tools of the trade
As you noticed, Swift gives much more flexibility in Java. When writing a function, you have the option to use:
A global function
An instance function (of a struct, class, or enum)
A static function (of a struct, class, or enum)
A class function (of a class)
There is a time and a place where each is appropriate. Java shoves options 2 and 3 down your throat (mainly option 2), whereas Swift lets you lean on your own judgement more often. I'll talk about each case, when you might want to use it, and when you might not.
1) Global functions
These can be useful for one-of utility functions, where there isn't much benefit to " grouping" them in a particular way.
Pros:
Short names due to unqualified access (can access foo, rather than FooUtils.foo)
Short to write
Cons:
Pollutes the global name space, and makes auto-completion less useful.
Not grouped in a way that aids discoverability
Cannot be dependancy injected
Any accessed state must be global state, which is almost always a recipe for a disaster
2) Instance functions
Pros:
Group related operations under a common namespace
Have access to localized state (the members of self), which is almost always preferable over global state.
Can be dependancy injected
Can be overridden by subclasses
Cons:
Longer to write than global functions
Sometimes instances don't make sense. E.g. if you have to make an empty MathUtils object, just to use its pow instance method, which doesn't actually use any instance data (e.g. MathUtils().pow(2, 2))
3) Static functions
Pros:
Group related operations under a common namespace
Can be dependancy in Swift (where protocols can support the requirement for static functions, subscripts, and properties)
Cons:
Longer to write than global functions
It's hard to extend these to be stateful in the future. Once a function is written as static, it requires an API-breaking change to turn it into an instance function, which is necessary if the need for instance state ever arrises.
4) Class functions
For classes, static func is like final class func. These are supported in Java, but in Swift you can also have non-finals class functions. The only difference here is that they support overriding (by a subclass). All other pro/cons are shared with static functions.
Which one should I use?
It depends.
If the piece you're programming is one that would like to isolate for testing, then global functions aren't a candidate. You have to use either protocol or inheritance based dependancy injection. Static functions could be appropriate if the code does not nned to have some sort of instance state (and is never expected to need it), whereas an instance function should be when instance state is needed. If you're not sure, you should opt for an instance function, because as mentioned earlier, transitioning a function from static to instance is an API breaking change, and one that you would want to avoid if possible.
If the new piece is really simple, perhaps it could be a global function. E.g. print, min, abs, isKnownUniquelyReferenced, etc. But only if there's no grouping that makes sense. There are exceptions to look out for:
If your code repeats a common prefix, naming pattern, etc., that's a strong indication that a logical grouping exists, which could be better expressed as unification under a common namespace. For example:
func formatDecimal(_: Decimal) -> String { ... }
func formatCurrency(_: Price) -> String { ... }
func formatDate(_: Date) -> String { ... }
func formatDistance(_: Measurement<Distance>) -> String { ... }
Could be better expressed if these functions were grouped under a common umbrella. In this case, we don't need instance state, so we don't need to use instance methods. Additionally, it would make sense to have an instance of FormattingUtils (since it has no state, and nothing that could use that state), so outlawing the creation of instances is probably a good idea. An empty enum does just that.
enum FormatUtils {
func formatDecimal(_: Decimal) -> String { ... }
func formatCurrency(_: Price) -> String { ... }
func formatDate(_: Date) -> String { ... }
func formatDistance(_: Measurement<Distance>) -> String { ... }
}
Not only does this logical grouping "make sense", it also has the added benefit of bringing you one step closer to supporting dependancy injection for this type. All you would need is to extract the interface into a new FormatterUtils protocol, rename this type to ProdFormatterUtils, and change dependant code to rely on the protocol rather than the concrete type.
If you find that you have code like in case 1, but also find yourself repeating the same parameter in each function, that's a very strong indication that you have a type abstraction just waiting to be discovered. Consider this example:
func enableLED(pin: Int) { ... }
func disableLED(pin: Int) { ... }
func checkLEDStatus(pin: Int) -> Bool { ... }
Not only can we apply the refactoring from point 1 above, but we can also notice that pin: Int is a repeated parameter, which could be better expressed as an instance of a type. Compare:
class LED { // or struct/enum, depending on the situation.
let pin: Int
init(pin: Int)? {
guard pinNumberIsValid(pin) else { return nil }
self.pin = pin
}
func enable() { ... }
func disable() { ... }
func status() -> Bool { ... }
}
Compared to the refactoring from point 1, this changes the call site from
LEDUtils.enableLED(pin: 1)`
LEDUtils.disableLED(pin: 1)`
to
guard let redLED = LED(pin: 1) else { fatalError("Invalid LED pin!") }
redLED.enable();
redLED.disable();
Not only is this nicer, but now we have a way to clearly distinguish functions that expect any old integer, and those which expect an LED pin's number, by using Int vs LED. We also give a central place for all LED-related operations, and a central point at which we can validate that a pin number is indeed valid. You know that if you have an instance of LED provided to you, the pin is valid. You don't need to check it for yourself, because you can rely on it already having been checked (otherwise this LED instance wouldn't exist).
I'm trying to get my head around DI. Am I doing it correctly for classes that follow DI pattern?
class Boo
{
public $title = 'Mr';
public $name = 'John';
protected $deps;
public function __construct($deps)
{
$this->deps = $deps;
}
public function methodBoo()
{
return 'Boo method '.$this->deps;
}
}
class Foo
{
private $objects;
public function __construct()
{
}
// Set the inaccessible property magically.
public function __set($name, $value)
{
$this->$name = $value;
}
// Set the inaccessible $class magically.
public function __get($class)
{
if(isset($this->objects[$class]))
{
return $this->objects[$class];
}
return $this->objects[$class] = new $class($this->deps);
}
public function methodFoo()
{
return $this->Boo->methodBoo();
}
}
$Foo = new Foo();
$Foo->deps = 'says hello';
var_dump($Foo->methodFoo());
result,
string 'Boo method says hello' (length=21)
I don't want to use construction injection in some cases because not all methods in Foo rely on the same injections. For instance,methodFoo()in Foo relies on Boo only, while other methods rely on other classes/ injections.
Also, I don't want to use setter injection either because I might have to write lots of them in Foo, like
setBoo() {}
setToo() {}
setLoo() {}
... and so on...
So I thought using the magic method __get and __set could save me from ending up writing a long list of them. With this, I only 'inject' the dependency when it is needed by a method in Foo.
Is this correct way of doing it? I haven't done any test with an unit test before. Can this solution be tested?
Or any better solutions you have got?
Don't Use Magic Methods If Possible...
Don't use magic methods if possible as it can make it very difficult for yourself or anyone else to come back at a later date and understand where and how certain objects were injected (even when using a good IDE). These __set and __get magic methods are not a long term solution to your problem and will only add confusion in the long run.
As you already know you can use 'constructor' injection for setting properties and injecting objects that are 'required' during instantiation of your object.
Alternatively, if you have dependencies that are 'optional' then use setter / getter methods. That way you 'know' what objects your class uses to perform it's function.
If your class needs say 5 or more dependencies (required or optional) than perhaps your class is try to do to much. Break it down into smaller classes that require less dependencies and you will find your code not only becomes more readable / understandable but also more modular and reusable. (Separation of concerns, etc.)
Regarding testing of a class that uses magic methods, I'm sure it can be done but at much more pains than if one didn't use magic methods.
Google 'Design Patterns'. What you find and learn about design patterns will improve the way you 'join' or 'wire' your classes together.
Suppose I want my class to do things on attribute access. I can of course do that in setters and getters:
class Foo {
set bar (v) {
// do stuff
}
}
However, if I want to attach the same behavior to multiple attributes, I'd have to explicitly define the same setters and getters for every one of them. (The use case I have in mind is an observable, i.e. a class that knows when its attributes are being changed).
What I'd like to do is something like:
class Foo {
var bar = new AttributeWithAccessBehavior();
}
Python does this with descriptors - what is the closest thing in Dart?
AFAIK there isn't anything with getter/setter syntax that you can reuse.
You could assign a function to a field, that you can access using call notation (), but you have to be careful to call the function instead of overriding the field assignment.
A similar but more powerful alternative are classes that can emulate functions (see https://www.dartlang.org/articles/emulating-functions/)
A class that has a call method can be used like a method.
This is similar to assigned functions mentioned above but in addition you can store state information.
If you implement actual getter/setter you can of course delegate to whatever you want, but that is obviously not what you are looking for.
For the use case you mentioned, there is the observe package.
I have no idea how exactly it solves the problem, but it works quite well.
Method 1:
def funtion1(){
//Code here
}
Method 2:
def function2={
//code here
}
actually what are the difference between defining these two type of method... And which one is good ..
Controller Actions as Methods
It is now possible to define controller actions as methods instead of using closures as in previous versions of Grails.
In fact this is now the preferred way of expressing an action.
So, if you use grails > 2.*, define actions as methods instead of as clothures.
Similar questions:
https://stackoverflow.com/a/1827035/1815058
https://stackoverflow.com/a/9205312/1815058
Well, the first one if a function and the second is a closure.
A Groovy Closure is like a "code block" or a method pointer. It is a piece of code that is defined and then executed at a later point. It has some special properties like implicit variables, support for currying and support for free variables.
I think that traditional methods is what you need. You probably should use closures in some special cases, but it's really big topic for thought.
So you better read about closures here and may be here.
If I have a default impl of a class, and it does define #Inject constructor, that's great. The system picks it up.
If one app wants to override that default impl with a subclass, I can define an #Provides in its module and call "new" on that subclass in my own code, and dagger uses that impl instead (from what I can tell so far, this works).
However, if I want dagger to instantiate that subclass, it there a way to do it without declaring "override=true" in the #Module? I like not having the override=true so that all the duplicate checks at build time give me appropriate warnings.
One way to do it, of course, it to force all apps to declare the #Provides directly. That just adds to the bloat.
I've used GIN (Guice for GWT) before, and you can define a binding to the class you want by a .class reference, but I don't see anything similar in dagger.
Right now, there is no way to have a "default binding" which you can freely override, without using the "overrides" attribute (which was intended more for testing than this.) We are considering how to do default bindings.
You might consider using a set binding to do this, by having something like along these lines:
#Module(...)
class MyModule {
#Qualifier #interface OverridableFoo { }
#Provides(type=SET_VALUES) #OverridableFoo Set<Foo> provideOverriddenFoo() {
return new HashSet<Foo>(); // Empty set to ensure the Set is initialized.
}
#Provides Foo provideFoo(#OverridableFoo Set<Foo> Foo overriddenFoo) {
switch (overriddenFoo.size()) {
case 0: return new DefaultFooImpl();
case 1: return overriddenFoo.iterator().next();
default: throw new IllegalStateException("More than one overridden Foo Provided.");
}
}
}
Then, when you want to override, you simply include this:
#Module(...)
class MyModule {
#Provides(type=SET_VALUE) #OverridableFoo Foo provideBetterFoo() {
return new MyAwesomeFoo();
}
}
This is not a great way to go, as it moves what should be a compile-time error to run-time, but as a stop-gap while we attempt to decide how to handle default bindings, I think it is workable.