Where should I write phpDoc? Upon interface in interface file or upon class that implements the interface?
I am a bit sad that I can't write return types and types of params before param in methods. In PHP I have to do that in phpDoc, but where should I write this?
I would write the docblock in the interface. If there is something specific for some class, you could write docblock for it.
You can specify argument types, see http://php.net/manual/en/language.oop5.typehinting.php
Related
The interfaces portion of Golang CodeReviewComments states:
Go interfaces generally belong in the package that uses values of the interface type, not the package that implements those values. The implementing package should return concrete (usually pointer or struct) types: that way, new methods can be added to implementations without requiring extensive refactoring.
Yet, Go's context.go module both defines the Context interface and implements it for type emptyCtx int and type cancelCtx struct.
Note, the portion listed above says they "generally" belong in the package that uses values of the interface type — so I understand that this is not a strict rule.
However, I am curious as to what the criteria is that makes it OK for them to do this in the context package.
Also, this assumes CodeReviewComments is a canonical resource for Go code reviews and style guide.
Defining implementations of an interface in the same package is actually pretty common, especially when implementing a strategy pattern or chain of responsibility(like context).
Take the net package for example, it defines the Listener interface, but also TCPListener, UDPListener, and UnixListener. In this case it would be illogical to place the functionality in another package.
The io package does a similar thing with the readers and writers.
Another handy pattern is to define a function alias for interfaces which only have 1 function. Like how HandlerFunc implements Handler, allowing users to cast closures as HandlerFunc so they don't have to define their own type, which is much more work.
As it commonly known, one cannot extend or redefine interface of the overridden method in the inherited ABAP class. Help:
The interface and the category of the method (a general or functional instance method or event handler) are not changed in a redefinition.
This covers both global and local classes redefinition.
What are the probable workarounds of this limitation if one wants to add or remove methods parameters or change their type? Optional parameters is a way, though not very comfy. Any other ways?
You cannot change the signature of an interface method in any way in its implementations. This is simply because there is no way to do this that would not produce hard-to-analyze syntax errors at run time. An interface is a contract - any class implementing it promises that it will implement all methods (and variables...) that are present in the interface.
Assume there is a method METH of interface IF1 taking a single parameter PAR1 of type TYPE1. If you now write a class that implements a method METH with a single parameter PAR1 of type TYPE2, then you have not written a class that implements IF1. A caller that passes a parameter of type TYPE1 to the method of your class will encounter a type conversion error (whether at runtime or at compile time depends somewhat on the genericity of the types).
Therefore, there is no way to change the signature of an interface method in its redefinition without producing such runtime errors - your class does not implement the interface. Implementing an interface means that the class will accept exactly the number, type and kind of parameters specified for the methods in the interface. There is literally no use case in which you could meaningfully want to change this while still claiming that your class implements the interface. Whatever you're trying to do, this isn't the solution.
You can create your own interface, extending the existing interface. Add same method with different parameters. Then create abstract class from your extended interface and fill methods with code for calling real method with setting values to optional parameters. After then create your class from abstract.
interface
|--> extented interface
|--> abstract class
|--> class
I need an io.Writer for a function. I don't know how to get one from a file...
I know interface are implicit so it complicated the search...
Look at the os.File documentation: it has a func (*File) Write method, which means it is a Writer.
You can use the command guru to list all types implementing an interface.
Notably, the implements query:
The implements query shows interfaces that are implemented by the selected type and, if the selected type is itself an interface, the set of concrete types that implement it.
An implements query on a value reports the same information about the expression’s type.
An implements query on a method shows the set of abstract or concrete methods that are related to it
According to the documentation for EventMachine.watch_file the handler argument has to be a Module (or a class inheriting from EventMachine::FileWatch). Why is it designed this way? For me a block (or Proc) argument would be more natural and flexible (since it allows to use local variables via closure)...
The docs are not super clear, but you can also supply a sub-class of FileWatch. That would let you use locals more easily.
It takes either a module with the needed methods, or a class with the needed methods AND it must be a sub-class of the desired class.
Take a look at the code, specifically, the klass_from_handler method.
I'm learning MVP patter. In some examples, I saw this! Any one could demonstrate why programmers use this name convention?
Usually I is there to indicate an Interface. Without the I is it a class. Personally I am not a fan of this. I think it is more common in dot net. I havent seen it too much in Java
Reasons why I dislike:
IDEs now show icons that indicate whether a class is an interface or not.
If I want to change the interface to an abstract class I then have to rename the class
It hurts readability.
'I' stands for interface. It's a common naming convention to distinguish interfaces from classes / structures.
Interfaces are not classes - they define behaviour and classes provide implementation.
Read this article on MSDN for more info: Choosing Between Classes and Interfaces
An interface defines the signatures for a set of members that
implementers must provide. Interfaces cannot provide implementation
details for the members. For example, the ICollection interface
defines members related to working with collections. Every class that
implements the interface must supply the implementation details for
theses members. Classes can implement multiple interfaces.
It is an artifact from age when Hungarian notation was thought to be a good idea. It lets the user know that the name is for an interface.
Also, it is an extremely stupid practice.
Name of the interface should reflect what sort of contract between classes it signifies. It should not tell you to which class it has been tied to.
It should be class PDF extends Document implements Printable because it lets you know that class implements print() method for some reason (in a real world it would be actually a bad API design, but this is an example) instead of class PDF extends Document implements IDocument .. because this tell you nothing.