4 replaced http://programmers.stackexchange.com/ with https://softwareengineering.stackexchange.com/
source | link

Names have the opportunity to convey meaning. Why would you throw away that opportunity with Impl?

First of all, if you will only ever have one implementation, do away with the interface. It creates this naming problem and adds nothing. Even worse, it could cause trouble with inconsistent method signatures in APIs if you and all other developers aren't careful to always use only the interface.

Given that, we can assume that every interface has or may have two or more implementations.

  • If you have only one right now, and you don't know in what way the other may be different, Default is a good start.

  • If you have two right now, name each one according to its purpose.

    Example: Recently, we had a concrete class Context (in reference to a database). It was realized that we needed to be able to represent a context that was offline, so the name Context was used for a new interface (to maintain compatibility for old APIs), and a new implementation was created, OfflineContext. But guess what the original was renamed to? That's right, ContextImpl (yikes).

    In this case, DefaultContext would probably be ok, and people would get it, but it is not as descriptive as it could be. After all, if it's not offline, what is it? So we went with: OnlineContext.


Special case: Using the "I" prefix on interfaces

One of the other answersother answers suggested using the I prefix on interfaces. Preferably, you don't need to do this.

However, if you need both an interface, for custom implementations, but you also have a primary concrete implementation that will be used often, and the basic name for it is just too simple to give up to an interface alone, then you can consider adding "I" to the interface (though, it's completely fine if it still doesn't sit right for you and your team).

Example: Many objects can be an "EventDispatcher". For the sake of APIs, this must conform to an interface. But, you also want to provide a basic event dispatcher for delegation. DefaultEventDispatcher would be fine, but it's a bit long, and if you are going to be seeing the name of it often, you might prefer to use the base name EventDispatcher for the concrete class, and implement IEventDispatcher for custom implementations:

/* Option 1, traditional verbose naming: */
interface EventDispatcher { /* interface for all event dispatchers */ }
class DefaultEventDispatcher implements EventDispatcher {
  /* default event dispatcher */
}

/* Option 2, "I" abbreviation because "EventDispatcher" will be a common default: */
interface IEventDispatcher { /* interface for all event dispatchers */ }
class EventDispatcher implements IEventDispatcher {
  /* default event dispatcher. */
}

Names have the opportunity to convey meaning. Why would you throw away that opportunity with Impl?

First of all, if you will only ever have one implementation, do away with the interface. It creates this naming problem and adds nothing. Even worse, it could cause trouble with inconsistent method signatures in APIs if you and all other developers aren't careful to always use only the interface.

Given that, we can assume that every interface has or may have two or more implementations.

  • If you have only one right now, and you don't know in what way the other may be different, Default is a good start.

  • If you have two right now, name each one according to its purpose.

    Example: Recently, we had a concrete class Context (in reference to a database). It was realized that we needed to be able to represent a context that was offline, so the name Context was used for a new interface (to maintain compatibility for old APIs), and a new implementation was created, OfflineContext. But guess what the original was renamed to? That's right, ContextImpl (yikes).

    In this case, DefaultContext would probably be ok, and people would get it, but it is not as descriptive as it could be. After all, if it's not offline, what is it? So we went with: OnlineContext.


Special case: Using the "I" prefix on interfaces

One of the other answers suggested using the I prefix on interfaces. Preferably, you don't need to do this.

However, if you need both an interface, for custom implementations, but you also have a primary concrete implementation that will be used often, and the basic name for it is just too simple to give up to an interface alone, then you can consider adding "I" to the interface (though, it's completely fine if it still doesn't sit right for you and your team).

Example: Many objects can be an "EventDispatcher". For the sake of APIs, this must conform to an interface. But, you also want to provide a basic event dispatcher for delegation. DefaultEventDispatcher would be fine, but it's a bit long, and if you are going to be seeing the name of it often, you might prefer to use the base name EventDispatcher for the concrete class, and implement IEventDispatcher for custom implementations:

/* Option 1, traditional verbose naming: */
interface EventDispatcher { /* interface for all event dispatchers */ }
class DefaultEventDispatcher implements EventDispatcher {
  /* default event dispatcher */
}

/* Option 2, "I" abbreviation because "EventDispatcher" will be a common default: */
interface IEventDispatcher { /* interface for all event dispatchers */ }
class EventDispatcher implements IEventDispatcher {
  /* default event dispatcher. */
}

Names have the opportunity to convey meaning. Why would you throw away that opportunity with Impl?

First of all, if you will only ever have one implementation, do away with the interface. It creates this naming problem and adds nothing. Even worse, it could cause trouble with inconsistent method signatures in APIs if you and all other developers aren't careful to always use only the interface.

Given that, we can assume that every interface has or may have two or more implementations.

  • If you have only one right now, and you don't know in what way the other may be different, Default is a good start.

  • If you have two right now, name each one according to its purpose.

    Example: Recently, we had a concrete class Context (in reference to a database). It was realized that we needed to be able to represent a context that was offline, so the name Context was used for a new interface (to maintain compatibility for old APIs), and a new implementation was created, OfflineContext. But guess what the original was renamed to? That's right, ContextImpl (yikes).

    In this case, DefaultContext would probably be ok, and people would get it, but it is not as descriptive as it could be. After all, if it's not offline, what is it? So we went with: OnlineContext.


Special case: Using the "I" prefix on interfaces

One of the other answers suggested using the I prefix on interfaces. Preferably, you don't need to do this.

However, if you need both an interface, for custom implementations, but you also have a primary concrete implementation that will be used often, and the basic name for it is just too simple to give up to an interface alone, then you can consider adding "I" to the interface (though, it's completely fine if it still doesn't sit right for you and your team).

Example: Many objects can be an "EventDispatcher". For the sake of APIs, this must conform to an interface. But, you also want to provide a basic event dispatcher for delegation. DefaultEventDispatcher would be fine, but it's a bit long, and if you are going to be seeing the name of it often, you might prefer to use the base name EventDispatcher for the concrete class, and implement IEventDispatcher for custom implementations:

/* Option 1, traditional verbose naming: */
interface EventDispatcher { /* interface for all event dispatchers */ }
class DefaultEventDispatcher implements EventDispatcher {
  /* default event dispatcher */
}

/* Option 2, "I" abbreviation because "EventDispatcher" will be a common default: */
interface IEventDispatcher { /* interface for all event dispatchers */ }
class EventDispatcher implements IEventDispatcher {
  /* default event dispatcher. */
}
3 Explaining the last sentence better, I think.
source | link

Names have the opportunity to convey meaning. Why would you throw away that opportunity with Impl?

First of all, if you will only ever have one implementation, do away with the interface. It creates this naming problem and adds nothing. Even worse, it could cause trouble with inconsistent method signatures in APIs if you and all other developers aren't careful to always use only the interface.

Given that, we can assume that every interface has or may have two or more implementations.

  • If you have only one right now, and you don't know in what way the other may be different, Default is a good start.

  • If you have two right now, name each one according to its purpose.

    Example: Recently, we had a concrete class Context (in reference to a database). It was realized that we needed to be able to represent a context that was offline, so the name Context was used for a new interface (to maintain compatibility for old APIs), and a new implementation was created, OfflineContext. But guess what the original was renamed to? That's right, ContextImpl (yikes).

    In this case, DefaultContext would probably be ok, and people would get it, but it is not as descriptive as it could be. After all, if it's not offline, what is it? So we went with: OnlineContext.


Special case: Using the "I" prefix on interfaces

One of the other answers suggested using the I prefix on interfaces. Preferably, you don't need to do this.

However, if you need both an interface, for custom implementations, but you also have a primary concrete implementation that will be used often, and the basic name for it is just too simple to give up to an interface alone, then you can consider adding "I" to the interface (though, it's completely fine if it still doesn't sit right for you and your team).

Example: Many objects can be an "EventDispatcher". For the sake of APIs, this must conform to an interface. But, you also want to provide a basic event dispatcher for delegation. DefaultEventDispatcher would be fine, but it's a bit long, and if you are going to be seeing the name of it often, you might prefer to use the base name EventDispatcher for the concrete class, and mark custom implementations withimplement IEventDispatcher. for custom implementations:

/* Option 1, traditional verbose naming: */
interface EventDispatcher { /* interface for all event dispatchers */ }
class DefaultEventDispatcher implements EventDispatcher {
  /* default event dispatcher */
}

/* Option 2, "I" abbreviation because "EventDispatcher" will be a common default: */
interface IEventDispatcher { /* interface for all event dispatchers */ }
class EventDispatcher implements IEventDispatcher {
  /* default event dispatcher. */
}

Names have the opportunity to convey meaning. Why would you throw away that opportunity with Impl?

First of all, if you will only ever have one implementation, do away with the interface. It creates this naming problem and adds nothing. Even worse, it could cause trouble with inconsistent method signatures in APIs if you and all other developers aren't careful to always use only the interface.

Given that, we can assume that every interface has or may have two or more implementations.

  • If you have only one right now, and you don't know in what way the other may be different, Default is a good start.

  • If you have two right now, name each one according to its purpose.

    Example: Recently, we had a concrete class Context (in reference to a database). It was realized that we needed to be able to represent a context that was offline, so the name Context was used for a new interface (to maintain compatibility for old APIs), and a new implementation was created, OfflineContext. But guess what the original was renamed to? That's right, ContextImpl (yikes).

    In this case, DefaultContext would probably be ok, and people would get it, but it is not as descriptive as it could be. After all, if it's not offline, what is it? So we went with: OnlineContext.


Special case: Using the "I" prefix on interfaces

One of the other answers suggested using the I prefix on interfaces. Preferably, you don't need to do this.

However, if you need both an interface, for custom implementations, but you also have a primary concrete implementation that will be used often, and the basic name for it is just too simple to give up to an interface alone, then you can consider adding "I" to the interface (though, it's completely fine if it still doesn't sit right for you and your team).

Example: Many objects can be an "EventDispatcher". For the sake of APIs, this must conform to an interface. But, you also want to provide a basic event dispatcher for delegation. DefaultEventDispatcher would be fine, but it's a bit long, and if you are going to be seeing the name of it often, you might prefer to use the base name EventDispatcher for the concrete class, and mark custom implementations with IEventDispatcher.

Names have the opportunity to convey meaning. Why would you throw away that opportunity with Impl?

First of all, if you will only ever have one implementation, do away with the interface. It creates this naming problem and adds nothing. Even worse, it could cause trouble with inconsistent method signatures in APIs if you and all other developers aren't careful to always use only the interface.

Given that, we can assume that every interface has or may have two or more implementations.

  • If you have only one right now, and you don't know in what way the other may be different, Default is a good start.

  • If you have two right now, name each one according to its purpose.

    Example: Recently, we had a concrete class Context (in reference to a database). It was realized that we needed to be able to represent a context that was offline, so the name Context was used for a new interface (to maintain compatibility for old APIs), and a new implementation was created, OfflineContext. But guess what the original was renamed to? That's right, ContextImpl (yikes).

    In this case, DefaultContext would probably be ok, and people would get it, but it is not as descriptive as it could be. After all, if it's not offline, what is it? So we went with: OnlineContext.


Special case: Using the "I" prefix on interfaces

One of the other answers suggested using the I prefix on interfaces. Preferably, you don't need to do this.

However, if you need both an interface, for custom implementations, but you also have a primary concrete implementation that will be used often, and the basic name for it is just too simple to give up to an interface alone, then you can consider adding "I" to the interface (though, it's completely fine if it still doesn't sit right for you and your team).

Example: Many objects can be an "EventDispatcher". For the sake of APIs, this must conform to an interface. But, you also want to provide a basic event dispatcher for delegation. DefaultEventDispatcher would be fine, but it's a bit long, and if you are going to be seeing the name of it often, you might prefer to use the base name EventDispatcher for the concrete class, and implement IEventDispatcher for custom implementations:

/* Option 1, traditional verbose naming: */
interface EventDispatcher { /* interface for all event dispatchers */ }
class DefaultEventDispatcher implements EventDispatcher {
  /* default event dispatcher */
}

/* Option 2, "I" abbreviation because "EventDispatcher" will be a common default: */
interface IEventDispatcher { /* interface for all event dispatchers */ }
class EventDispatcher implements IEventDispatcher {
  /* default event dispatcher. */
}
2 added 1016 characters in body; added 95 characters in body
source | link

Names have the opportunity to convey meaning. Why would you throw away that opportunity with Impl?

First of all, if you will only ever have one implementation, do away with the interface. It creates this naming problem and adds nothing. Even worse, it could cause trouble with inconsistent method signatures in APIs if you and all other developers aren't careful to always use only the interface.

Given that, we can assume that every interface has or may have two or more implementations.

  • If you have only one right now, and you don't know in what way the other may be different, Default is a good start.

  • If you have two right now, name each one according to its purpose.

    Example: Recently, we had a concrete class Context (in reference to a database). It was realized that we needed to be able to represent a context that was offline, so the name Context was used for a new interface (to maintain compatibility for old APIs), and a new implementation was created, OfflineContext. But guess what the original was renamed to? That's right, ContextImpl (yikes).

    In this case, DefaultContext would probably be ok, and people would get it, but it is not as descriptive as it could be. After all, if it's not offline, what is it? So we went with: OnlineContext.


Special case: Using the "I" prefix on interfaces

One of the other answers suggested using the I prefix on interfaces. Preferably, you don't need to do this.

However, if you need both an interface, for custom implementations, but you also have a primary concrete implementation that will be used often, and the basic name for it is just too simple to give up to an interface alone, then you can consider adding "I" to the interface (though, it's completely fine if it still doesn't sit right for you and your team).

Example: Many objects can be an "EventDispatcher". For the sake of APIs, this must conform to an interface. But, you also want to provide a basic event dispatcher for delegation. DefaultEventDispatcher would be fine, but it's a bit long, and if you are going to be seeing the name of it often, you might prefer to use the base name EventDispatcher for the concrete class, and mark custom implementations with IEventDispatcher.

Names have the opportunity to convey meaning. Why would you throw away that opportunity with Impl?

First of all, if you will only ever have one implementation, do away with the interface. It creates this naming problem and adds nothing. Even worse, it could cause trouble with inconsistent method signatures in APIs if you and all other developers aren't careful to always use only the interface.

Given that, we can assume that every interface has or may have two or more implementations.

  • If you have only one right now, and you don't know in what way the other may be different, Default is a good start.

  • If you have two right now, name each one according to its purpose.

    Example: Recently, we had a concrete class Context (in reference to a database). It was realized that we needed to be able to represent a context that was offline, so the name Context was used for a new interface (to maintain compatibility for old APIs), and a new implementation was created, OfflineContext. But guess what the original was renamed to? That's right, ContextImpl (yikes).

    In this case, DefaultContext would probably be ok, and people would get it, but it is not as descriptive as it could be. After all, if it's not offline, what is it? So we went with: OnlineContext.

Names have the opportunity to convey meaning. Why would you throw away that opportunity with Impl?

First of all, if you will only ever have one implementation, do away with the interface. It creates this naming problem and adds nothing. Even worse, it could cause trouble with inconsistent method signatures in APIs if you and all other developers aren't careful to always use only the interface.

Given that, we can assume that every interface has or may have two or more implementations.

  • If you have only one right now, and you don't know in what way the other may be different, Default is a good start.

  • If you have two right now, name each one according to its purpose.

    Example: Recently, we had a concrete class Context (in reference to a database). It was realized that we needed to be able to represent a context that was offline, so the name Context was used for a new interface (to maintain compatibility for old APIs), and a new implementation was created, OfflineContext. But guess what the original was renamed to? That's right, ContextImpl (yikes).

    In this case, DefaultContext would probably be ok, and people would get it, but it is not as descriptive as it could be. After all, if it's not offline, what is it? So we went with: OnlineContext.


Special case: Using the "I" prefix on interfaces

One of the other answers suggested using the I prefix on interfaces. Preferably, you don't need to do this.

However, if you need both an interface, for custom implementations, but you also have a primary concrete implementation that will be used often, and the basic name for it is just too simple to give up to an interface alone, then you can consider adding "I" to the interface (though, it's completely fine if it still doesn't sit right for you and your team).

Example: Many objects can be an "EventDispatcher". For the sake of APIs, this must conform to an interface. But, you also want to provide a basic event dispatcher for delegation. DefaultEventDispatcher would be fine, but it's a bit long, and if you are going to be seeing the name of it often, you might prefer to use the base name EventDispatcher for the concrete class, and mark custom implementations with IEventDispatcher.

1
source | link