Let say I want to create an interface for a class that should be name JQuery.
If this class is an interface, from the conventions, I should name it IJQuery, but I find it's made the name look weird.
What you think ?
I've never been a big fan of embedding information of the type of an object into its name, so I would not use I as a prefix anyway. But if you are doing it is a good idea to keep with the convention, but based on your example I would also consider how you name your interfaces, because from what I can tell you would have an IJQuery and a JQueryImpl.
I would consider naming your interface something like JavaScriptLibrary and then name your implementing class JQuery or Prototype.
In Java:
public interface JavaScriptLibrary { ... }
public class JQuery implements JavaScriptLibrary { ... }
public class Prototype implements JavaScriptLibrary { ... }
Most naming conventions "look weird" when compared to written language. But consistently following a convention pays off in the long run.
Ponzao has a good point and I tend to not embed type information into the names of classes, variables, etc. However, when dealing with more than a few files I have found marking interfaces to be helpful.
I use two naming conventions that have been very helpful in past:
1) m_variableName
m_ stands out in the code, marking member variables.
2) IThisIsAnInterface
For interfaces you might consider something like I_JQuery with the I_ marking your interface.
-bn
Related
I was reading an article about composition vs inheritance and the article uses the terms "domain class" and "implementation class". The author specifically says "Domain classes should use implementation classes, not inherit from them". Please explain the difference between a domain class and an implementation class.
The example of an implementation class given in the article is ArrayList. It's not part of the code describing business entities, it's just a commonly-used general purpose class.
This contrasts with the Customer class that they mention. Customer would be a class that is part of the domain, where it is describing an entity specific to the business.
The article is telling you not to extend from utility classes like this when creating domain classes.
How to Misuse Inheritance - Example 2
Creating a domain-concept class by inheriting from an implementation class is a common misuse of inheritance. For example, suppose we want to do something with a certain segment of our customers. The easy and obvious thing to do is to subclass ArrayList, call it CustomerGroup, and start coding, right?
Wrong. That would be a cross-domain inheritance relationship, and those should be avoided:
1) ArrayList is a subclass of list already, a utility collection - an implementation class.
2) CustomerGroup is another subclass - a domain class.
3) Domain classes should use implementation classes, not inherit from them.
If you need to implement a CustomerGroup class it could have an ArrayList as an instance member, like this:
public class CustomerGroup {
private List<Customer> customers = new ArrayList<>();
public List<Customer> getCustomers() {return customers;}
}
but you wouldn't make the class itself be a subclass of ArrayList.
The reason is that when you subclass something the users of your class get all the functionality of the superclass even if it isn't appropriate. You don't really need a domain class to see this in action, just go check out the source for java.util.Properties, which is badly designed, extending java.util.Hashtable. When you use a Properties object the methods from Hashtable are available to you, even though they are totally unnecessary and confusing, and using the superclass methods doesn't work or causes problems.
I writing a small Snake game in Lazarus, and Lazarus complains when I write
type
ISegment = interface(IRenderable, IMover)
end;
When I'm trying to achieve is to make ISegment a combined interface, but it doesn't seem to work. Does Lazarus not support multiple interface inheritance?
There is no multiple inheritance supported in the language. A class cannot be derived from multiple base classes. An interface cannot be derived from multiple base interfaces.
What you can do however, is have a class that implements multiple interfaces. Like this:
type
TMyClass = class(TInterfacedObject, IFoo, IBar)
....
end;
It does, you just need a better reading skill to understand this (look at the syntax diagram, in the heritage part). class type identifier is not stated as optional, but implemented interface does. It's roughly read as:
"A class may extend a base class and implements as many interfaces as possible. When an interface is about to be implemented, the base class must also be specified. The other way around does not apply, you can perfectly have a class extends a base class without specifying any interface"
The answer is no, Pascal is not supposed to support multiple inheritance so I don't see why it should do a different thing for interfaces then
As explained in previous answer, you still can implement several interfaces in a class
With reference to UML diagrams, what is an interface? and can someone explain in more simpler words. I cant understand anything from googling it.
An interface is like a template design for a class that contains no data or implemetnation; only definitions for methods, properties etc. These are abstract and cannot be instantiated but can be inherited from at which point all specified methods etc must be implemented by the concrete class inheriting the interface.
An interface is a design item describing a behaviour.
Classes implementing the interface will/must behave according to its definition.
Interfaces are used to promote loose coupling and the base of many IoC patterns (Inversion of Control)
A Interface is just a description of a class nothing concrete.
You use it to create a new class "with the same description" without knowing the concrete implementation.
In one word: it's a contract. Every class that implements this contract (interface) will have to implement the methods defined on it.
I've written a Scala trait, named Cache[A,B], to provide a caching API. The Cache has the following methods, asyncGet(), asyncPut(), asyncPutIfAbsent(), asyncRemove().
I'm going to have a few static methods, such as getOrElseUpdate(key: A)(op: => B). I don't want methods like this as abstract defs in the Cache trait because I don't want each Cache implementation to have to provide an implementation for it, when it can be written once using the async*() methods.
In looking at Google Guava and parts of the Java library, they place public static functions in a class that is the plural of the interface name, so "Caches" would be the name I would use.
I like this naming scheme actually, even though I could use a Cache companion object. In looking at much of my code, many of my companion objects contain private val's or def's, so users of my API then need to look through the companion object to see what they can use from there, or anything for that matter.
By having a object named "Caches" is consistent with Java and also makes it clear that there's only public functions in there. I'm leaning towards using "object Caches" instead of "object Cache".
So what do people think?
Scala's traits are not just a different name for Java's interfaces. They may have concrete (implemented) members, both values (val and var) and methods. So if there's a unified / generalized / shared implementation of a method, it can be placed in a trait and need not be replicated or factored into a separate class.
I think the mistake starts with "going to have a few static methods". Why have static methods? If you explain why you need static methods, it will help figure out what the design should be.
I am looking at nServiceBus and came over this interface
namespace NServiceBus
{
public interface IMessage
{
}
}
What is the use of an empty interface?
Usually it's to signal usage of a class. You can implement IMessage to signal that your class is a message. Other code can then use reflection to see if your objects are meant to be used as messages and act accordingly.
This is something that was used in Java a lot before they had annotations. In .Net it's cleaner to use attributes for this.
#Stimpy77 Thanks! I hadn't thought of it that way.
I hope you'll allow me to rephrase your comment in a more general way.
Annotations and attributes have to be checked at runtime using reflection. Empty interfaces can be checked at compile-time using the type-system in the compiler. This brings no overhead at runtime at all so it is faster.
Also known as a Marker Interface:
http://en.wikipedia.org/wiki/Marker_interface_pattern
In java Serializable is the perfect example for this. It defines no methods but every class that "implements" it has to make sure, that it is really serializable and holds no reference to things that cannot be serialized, like database connections, open files etc.
In Java, empty interfaces were usually used for "tagging" classes - these days annotations would normally be used.
It's just a way of adding a bit of metadata to a class saying, "This class is suitable for <this> kind of use" even when no common members will be involved.
Normally it's similar to attributes. Using attributes is a preferred to empty interfaces (at least as much as FxCop is aware). However .NET itself uses some of these interfaces like IRequiresSessionState and IReadOnlySessionState. I think there is performance loss in metadata lookup when you use attributes that made them use interfaces instead.
An empty interface acts simply as a placeholder for a data type no better specified in its interface behaviour.
In Java, the mechanism of the interface extension represents a good example of use. For example, let's say that we've the following
interface one {}
interface two {}
interface three extends one, two {}
Interface three will inherit the behaviour of 'one' and 'two', and so
class four implements three { ... }
has to specify the two methods, being of type 'three'.
As you can see, from the above example, empty interface can be seen also as a point of multiple inheritance (not allowed in Java).
Hoping this helps to clarify with a further viewpoint.
They're called "Mark Interfaces" and are meant to signal instances of the marked classes.
For example... in C++ is a common practice to mark as "ICollectible" objects so they can be stored in generic non typed collections.
So like someone over says, they're to signal some object supported behavior, like ability to be collected, serialized, etc.
Been working with NServiceBus for the past year. While I wouldn't speak for Udi Dahan my understanding is that this interface is indeed used as a marker primarily.
Though I'd suggest you ask the man himself if he'd had thoughts of leaving this for future extension. My bet is no, as the mantra seems to be to keep messages very simple or at least practically platform agnostic.
Others answer well on the more general reasons for empty interfaces.
I'd say its used for "future" reference or if you want to share some objects, meaning you could have 10 classes each implementing this interface.
And have them sent to a function for work on them, but if the interface is empty, I'd say its just "pre"-work.
Empty interfaces are used to document that the classes that implement a given interface have a certain behaviour
For example in java the Cloneable interface in Java is an empty interface. When a class implements the Cloneable interface you know that you can call run the clone() on it.
Empty interfaces are used to mark the class, at run time type check can be performed using the interfaces.
For example
An application of marker interfaces from the Java programming language is the Serializable interface. A class implements this interface to indicate that its non-transient data members can be written to an ObjectOutputStream. The ObjectOutputStream private method writeObject() contains a series of instanceof tests to determine writeability, one of which looks for the Serializable interface. If any of these tests fails, the method throws a NotSerializableException.
An empty interface can be used to classify classes under a specific purpose. (Marker Interface)
Example : Database Entities
public interface IEntity {
}
public class Question implements IEntity {
// Implementation Goes Here
}
public class Answer implements IEntity {
// Implementation Goes Here
}
For Instance, If you will be using Generic Repository(ex. IEntityRepository), using generic constraints, you can prevent the classes that do not implement the IEntity interface from being sent by the developers.