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.
Related
As far as I can tell, Laravel refers to the interfaces it extends as Contracts because they are used by Laravel. But this seems a bit like circular reasoning. There is no value added in changing the terminology of an existing PHP feature simply because your project uses it.
Is there something more to it? What's the logic behind coining a new term for something that's a standard PHP feature? Or is there some feature of Contracts that are not already in Interfaces?
Edit: To clarify, it's the usage of Contract as a proper noun in the documentation that has me confused, as explained in my comment on Thomas's post
"Contract" isn't some new terminology that Taylor coined. It's a very common term programmers use.
An interface is a contract, but a contract doesn't necessarily have to be an interface. The interface in a nutshell defines the contract that the classes must implement.
An abstract class is also a contract. The difference is that an abstract class can provide actual implementations, state, etc., and as a result, it is (in a sense) a more rigorous contract.
Another key difference is that a child class can only extend 1 abstract class but it can implement multiple interfaces.
So basically, "contract" isn't a new naming convention. It's a common term that Taylor is using.
It's just a nice word to describe the idea of using interfaces.
Laravel contracts are just PHP interfaces so they don't provide any other functionality.
You can read more on this subject in the documentation http://laravel.com/docs/5.1/contracts
As others have said, that is just a fancy word for Interfaces, but I think that Taylor made that decision to make it more personal.
What I mean by personal is that interface it's a very broad/common word on programming language, you have your interfaces, libraries (that you might be using) have their own interfaces and so on.
Contracts you just assume as the Laravel interfaces it's like a wrapper or alias for all the Interfaces that belong to this repo.
Short description: Contract is a term used for interfaces, but also for abstract classes.
I read through the TypeScript Coding guidelines
And I found this statement rather puzzling:
Do not use "I" as a prefix for interface names
I mean something like this wouldn't make a lot of sense without the "I" prefix
class Engine implements IEngine
Am I missing something obvious?
Another thing I didn't quite understand was this:
Classes
For consistency, do not use classes in the core compiler pipeline. Use
function closures instead.
Does that state that I shouldn't use classes at all?
Hope someone can clear it up for me :)
When a team/company ships a framework/compiler/tool-set they already have some experience, set of best practices. They share it as guidelines. Guidelines are recommendations. If you don't like any you can disregard them.
Compiler still will compile your code.
Though when in Rome...
This is my vision why TypeScript team recommends not I-prefixing interfaces.
Reason #1 The times of the Hungarian notation have passed
Main argument from I-prefix-for-interface supporters is that prefixing is helpful for immediately grokking (peeking) whether type is an interface. Statement that prefix is helpful for immediately grokking (peeking) is an appeal to Hungarian notation. I prefix for interface name, C for class, A for abstract class, s for string variable, c for const variable, i for integer variable. I agree that such name decoration can provide you type information without hovering mouse over identifier or navigating to type definition via a hot-key. This tiny benefit is outweighed by Hungarian notation disadvantages and other reasons mentioned below. Hungarian notation is not used in contemporary frameworks. C# has I prefix (and this the only prefix in C#) for interfaces due to historical reasons (COM). In retrospect one of .NET architects (Brad Abrams) thinks it would have been better not using I prefix. TypeScript is COM-legacy-free thereby it has no I-prefix-for-interface rule.
Reason #2 I-prefix violates encapsulation principle
Let's assume you get some black-box. You get some type reference that allows you to interact with that box. You should not care if it is an interface or a class. You just use its interface part. Demanding to know what is it (interface, specific implementation or abstract class) is a violation of encapsulation.
Example: let's assume you need to fix API Design Myth: Interface as Contract in your code e.g. delete ICar interface and use Car base-class instead. Then you need to perform such replacement in all consumers. I-prefix leads to implicit dependency of consumers on black-box implementation details.
Reason #3 Protection from bad naming
Developers are lazy to think properly about names. Naming is one of the Two Hard Things in Computer Science. When a developer needs to extract an interface it is easy to just add the letter I to the class name and you get an interface name. Disallowing I prefix for interfaces forces developers to strain their brains to choose appropriate names for interfaces. Chosen names should be different not only in prefix but emphasize intent difference.
Abstraction case: you should not not define an ICar interface and an associated Car class. Car is an abstraction and it should be the one used for the contract. Implementations should have descriptive, distinctive names e.g. SportsCar, SuvCar, HollowCar.
Good example: WpfeServerAutosuggestManager implements AutosuggestManager, FileBasedAutosuggestManager implements AutosuggestManager.
Bad example: AutosuggestManager implements IAutosuggestManager.
Reason #4 Properly chosen names vaccinate you against API Design Myth: Interface as Contract.
In my practice, I met a lot of people that thoughtlessly duplicated interface part of a class in a separate interface having Car implements ICar naming scheme. Duplicating interface part of a class in separate interface type does not magically convert it into abstraction. You will still get concrete implementation but with duplicated interface part. If your abstraction is not so good, duplicating interface part will not improve it anyhow. Extracting abstraction is hard work.
NOTE: In TS you don't need separate interface for mocking classes or overloading functionality.
Instead of creating a separate interface that describes public members of a class you can use TypeScript utility types. E.g. Required<T> constructs a type consisting of all public members of type T.
export class SecurityPrincipalStub implements Required<SecurityPrincipal> {
public isFeatureEnabled(entitlement: Entitlement): boolean {
return true;
}
public isWidgetEnabled(kind: string): boolean {
return true;
}
public areAdminToolsEnabled(): boolean {
return true;
}
}
If you want to construct a type excluding some public members then you can use combination of Omit and Exclude.
Clarification regarding the link that you reference:
This is the documentation about the style of the code for TypeScript, and not a style guideline for how to implement your project.
If using the I prefix makes sense to you and your team, use it (I do).
If not, maybe the Java style of SomeThing (interface) with SomeThingImpl (implementation) then by all means use that.
I find #stanislav-berkov's a pretty good answer to the OP's question. I would only share my 2 cents adding that, in the end it is up to your Team/Department/Company/Whatever to get to a common understanding and set its own rules/guidelines to follow across.
Sticking to standards and/or conventions, whenever possible and desirable, is a good practice and it keeps things easier to understand. On the other side, I do like to think we are still free to choose the way how we write our code.
Thinking a bit on the emotional side of it, the way we write code, or our coding style, reflects our personality and in some cases even our mood. This is what keeps us humans and not just coding machines following rules. I believe coding can be a craft not just an industrialized process.
I personally quite like the idea of turning a noun into an adjective by adding the -able suffix. It sounds very impropper, but I love it!
interface Walletable {
inPocket:boolean
cash:number
}
export class Wallet implements Walletable {
//...
}
}
The guidelines that are suggested in the Typescript documentation aren't for the people who use typescript but rather for the people who are contributing to the typescript project. If you read the details at the begging of the page it clearly defines who should use that guideline. Here is a link to the guidelines.
Typescript guidelines
In conclusion as a developer you can name you interfaces the way you see fit.
I'm trying out this pattern similar to other answers, but exporting a function that instantiates the concrete class as the interface type, like this:
export interface Engine {
rpm: number;
}
class EngineImpl implements Engine {
constructor() {
this.rpm = 0;
}
}
export const createEngine = (): Engine => new EngineImpl();
In this case the concrete implementation is never exported.
I do like to add a Props suffix.
interface FormProps {
some: string;
}
const Form:VFC<FormProps> = (props) => {
...
}
The type being an interface is an implementation detail. Implementation details should be hidden in API:s. That is why you should avoid I.
You should avoid both prefix and suffix. These are both wrong:
ICar
CarInterface
What you should do is to make a pretty name visible in the API and have a the implemtation detail hidden in the implementation. That is why I propose:
Car - An interface that is exposed in the API.
CarImpl - An implementation of that API, that is hidden from the consumer.
In Spring MVC, one can define interceptors that can perform work before and after a particular controller is invoked. This can be used, for example, to do logging, authentication etc.
The programmer who wishes to write a custom interceptor is supposed to implement the HandlerInterceptor interface. To aid this task, the HandlerInterceptorAdaptor abstract base class has been provided, which provides default implementations of all the methods specified in the interface. So, if just wants to do some pre processing, one can just extend HandlerInterceptorAdaptor and #Override public boolean preHandle(...), and not worry about implementing the postHandle function.
My doubt concerns the name. From what I understand of the Adapter pattern, it adapts syntactic impedance mismatches between interfaces.
Is that so? If yes, should the class providing the boilerplate implementations be called HandlerInterceptorDefaultImpl, or something along those lines?
Is there a different nomenclature/pattern for what is happening here?
Is the fact that we need a boilerplate class a code smell, and could be removed by refactoring the HandlerInterceptor interface into two: HandlerPreInterceptor and HandlerPostInterceptor? Or is that overkill?
From GOF book about the Adapter pattern:
Adapters vary in the amount of work they do to adapt Adaptee to the Target Interface. There is a spectrum of possible work, from simple interface conversion-for example,changing the names of operations-to supporting an entirely different set of operations. The amount of work Adapter does depends on how similar the Target interface is to Adaptee's.
The boilerplate class that you are referring to is called skeletal implementation class. This is mentioned in Effective Java by Joshua Bloch. From the book:
You can combine the virtues of interfaces and abstract classes by providing an abstract skeletal implementation class to go with each nontrivial interface that you export. The interface still defines the type, but the skeletal implementation takes all of the work out of implementing it.
By convention, skeletal implementations are called AbstractInterface, where Interface is the name of the interface they implement. For example, the Collections Framework provides a skeletal implementation to go along with each main collection interface: AbstractCollection, AbstractSet, AbstractList, and
AbstractMap. Arguably it would have made sense to call them SkeletalCollection, SkeletalSet, SkeletalList, and SkeletalMap, but the Abstract convention is now firmly established.
The Wikipedia COM article is vague when it comes to this issue.
Can anybody give an explanation that would be suitable for a COM beginner, or article link(s) providing the same.
It helped me to think about it the following way:
A COM class to me is an instance of a class that implements a certain interface. I don't need to know how the implementation is done, as long as it works as expected. Also, a COM class is not language dependent - it's a description of methods.
A Co-Class is an actual implementation that gets instantiated when requesting a COM class.
For example: A COM class could define method to encrypt or decrypt data. There could be two Co-Classes, each for a special encryption algorithm.
coclass is nothing but a type library declaration of a class. There are no assumptions on interfaces implemented by a class (other than perhaps IUnknown, or the class makes no sense), however if a declaration references certain interfaces within the type library, it is expected that real instance would implement those.
To answer your exact question, coclass stands for "component object class"; it is the same thing as "COM class". Your Wikipedia link answers this exactly:
A COM class (coclass) is...
I'm trying to use TDD when writing a class that needs to parse an XML document. Let's say the class is called XMLParser, and its constructor takes in a string for the path to the XML file to parse. I would like to have a Load() method that tries to load this XML into memory, and performs a few checks on the file such as file system errors, whether or not its an XML file, etc.
My question is about alternatives: I've read that it's bad practice to have private methods that you need to test, and that you should be able to just test the public interface and let the private methods do their thing. But in this case, this functionality is pretty important, and I don't think it should be public.
Does anyone have good advice for a scenario like this?
I suggest to redesign your architecture a bit. Currently, you have one high level class with low level functionality embedded. Split that into multiple classes that belong to different layers (I use the term "layer" very loosely here).
Example:
Have one class with the public interface of your current class. (-> High level layer)
Have one class responsible for loading files from disk and handling IO errors (-> Low level layer)
Have one class responsible for validating XML documents (-> Inbetween)
Now you can test all three of these classes independently!
You will see that your high level class will do not much more than just composing the two lower level classes.
Use no access modifier (which is the next up to private) and write the test in the same package.
Good OOD is important but for really important functionality testing is more important. Good practices are always only a guideline and they are good in the general scenario.
You could also try to encapsulate that specific file-checking behaviour in another object and have your parser instantiate it and use it. This is probably what I would do. In this way you could also even use this functionality somewhere else with minimal effort.
You can make a subclass as part of your test package that exposes public accessors to the private methods (which should then be protected).
Public class TestableClass : MyClass
{
public someReturnType TestMethod() {
return base.PrivateMethod();
}
}