What is the difference between these 2 relationships?
Edit: Also if you could provide a simple code example illustrating the difference, that would be really helpful!
I'm trying to give simple examples of the two types of lines.
In the first diagram, the solid line shows an association:
If the classes were declared in Java, this would be like ClassA storing a reference to ClassB as an attribute (it could be passed in to the constructor, created, etc.). So, you might see something like:
public class ClassA {
ClassB theClassB = ...
...
}
In the second diagram, it shows a dependency:
A dependency is much weaker than an association. To quote from UML Distilled:
With classes, dependencies exist for various reasons: One class sends a message to another; one class has another as part of its data; one
class mentions another as a parameter to an operation. [...] You use dependencies
whenever you want to show how changes in one element might alter other elements.
Again, using Java, a couple of examples exist: an argument of type ClassB is passed to a method, or a method declares a local variable of type ClassB:
public class ClassA {
...
public void someMethod(ClassB arg1) {...}
...
public void someOtherMethod() {
ClassB localReferenceToClassB = ...
}
...
}
Other ways ClassA could depend on ClassB without having an association (not an exhaustive list):
ClassB has a static method that ClassA calls
ClassA catches exceptions of type ClassB
Whenever ClassB is modified, ClassA must also be modified (e.g., some logic is shared)
Your question gave me a good chance to learn myself, here is what I found -
Association: Ownership of another type (e.g. 'A' owns a 'B')
//#assoc The Player(A) has some Dice(B)
class Player {
Dice myDice;
}
Dependency: Use of another type (e.g. 'C' uses a 'D')
//#dep The Player(C) uses some Dice(D) when playing a game
class Player {
rollYahtzee(Dice someDice);
}
Here's a crisp ref I found - Association vs. Dependency
This webpage says enough I think
The following text comes from it, but should be enough to understand the difference.
So basically the solid line is an association and the dashed/dotted line is a dependency.
Associations can also be unidirectional, where one class knows about
the other class and the relationship but the other class does not.
Such associations require an open arrowhead to point to the class that
is known and only the known class can have a role name and
multiplicity. In the example, the Customer class knows about any
number of products purchased but the Product class knows nothing about
any customer. The multiplicity "0..*" means zero or more.
A dependency is a weak relationship between two classes and is
represented by a dotted line. In the example, there is a dependency
between Point and LineSegment, because LineSegment's draw() operation
uses the Point class. It indicates that LineSegment has to know about
Point, even if it has no attributes of that type. This example also
illustrates how class diagrams are used to focus in on what is
important in the context, as you wouldn't normally want to show such
detailed dependencies for all your class operations.
Since my reputation is only 8 I can't place the images itself, but they can still be found on the webpage I mentioned at the start.
[EDIT]
I don't have code examples right here, but how I personally would explain it is as simple as a car and a door.
When a car has a door (or more) it's just a car
Car --- has a --> Door
But when you have a door which can be opened the door class will have a function like
public void openDoor(){
this.open();
}
To use the function above the car will have to create an instance of the door
Class Car(){
Door door1 = new Door();
door1.open();
}
In this way you have created a dependency.
So the solid line is just pointing an object(1) to another object(2), but when you start using the object(1) it becomes a dependency.
Okay, since you didn't accept the first answer; let me try.
Arrow 1: A normal association
UML has different types of lines and arrows. Above is the simple association arrow, that means that one class can have a link to the other class. Below I will explain each type WITH code examples.
In the first example, you can see that there isn't really specified who knows who (who is the owner of the relationship). An animal can know the human and the human can know the animal. It's not specified and thus not really helpful for the programmer.
In the second example, the artist can have a guitar. Because there is an arrow and there isn't one on the other side, we know that the guitar doesn't know the artist. A guitar is an object that can totally exist on its own and doesn't need anybody.
In the third example, you see a marriage. Really simple; the husband knows the wife and the wife knows her husband. In our situation, the husband has only one wife and vice versa.
How do we accomplish this usually in code?
class Husband{
Wife bestWomanInTheWorld;
public Husband(Wife theWife){
this.bestWomanInTheWorld = theWife;
}
}
Because the husband always needs a wife, we put the required relationship in the constructor. Because an artist can have a guitar, we would leave the constructor empty like this:
class Artist{
List<Guitar> guitars;
public Artist(){
}
public AddGuitarToCollection(Guitar newGuitar){
Guitars.Add(newGuitar);
}
}
So, that's how we accomplish this in code (most of the time!). You won't usually need different types of lines and arrows if you are new to programming. Keep it simple.
Arrow 2: Dependency
Okay, so we know about normal associations which we will use most of the time. But when will we use the 'dependency' arrow? Well, lets define a dependency (wikipedia):
Dependency is a weaker form of bond which indicates that one class depends on
another because it uses it at some point in time. One class depends on
another if the independent class is a parameter variable or local variable of
a method of the dependent class. This is different from an association, where
an attribute of the dependent class is an instance of the independent class.
Sometimes the relationship between two classes is very weak. They are not
implemented with member variables at all. Rather they might be implemented as
member function arguments.
If there is a connection, relation, association etc. that requires to be present, to the classA to work; it's a dependency. Example: Husband needs the Wife to exist. A car needs a wheel to be a car (and drive). A car factory needs a car class to make an object from it. Your RSSNewsItem class needs an XMLReader class to do anything.
When to use which?
Well, this is the only valid question in my eyes; since google shows alot of valid answers to your question. Try to never use a dependency in a class diagram because it usually means that you aren't specific enough. Always aim for associations, realisations etc. Only use realisations (in my opinion) if there is a required need to use an other class without maintaining a relationship. Example; Utility classes (like the XMLReader).
If you have any questions after reading this full explanation, feel free to ask. :-)
Dotted line indicates dependency to (in the direction of the arrow). Assuming you have assembled your source code neatly into separate files and headers for each class
- the give away is simply that the code includes the line #include ClassB.h.
HOWEVER The fact of the matter is that all class relationships (generalisation, realisation, composition, aggregation, association etc) all inherit the dependency relationship. For this reason I never use dotted arrows when documenting code. Where possible I would aim to document the relationship in more specific terms eg. diamonds, triangles etc. If I don't know the exact relationship my starting point is a solid line with arrows (an association, with (implicit) dependence).
Notwithstanding this the dotted arrow notation can be useful in other aspects of UML modelling eg. showing dependencies to requirements in Use Case analysis for example.
NOTE The Thought Police would have us reduce coupling & dependencies between classes by using interfaces (pure virtual classes) as far as practical.
Whilst pure virtual classes offer the prospect of multiple inheritance and tightest coupling of all between classes as is possible. Interface classes have the advantage that they are made entirely out of dark matter and so totally invisible to the police. With this in mind it is possible to write c++ code with apparently zero coupling between classes -which they love because they never really did understand all those funny looking symbols anyway.
dotted mean implements (an interface)
solid means extends (a base class)
This article speaks of the difference between types and classes. Since I've only worked with languages that treat both as identical, please suggest material/programming-languages that will teach me the difference.
Difference is not the right word - classes are certainly types. But not all types are classes. Note also that the word "class" is quite vague - it could be just a tuple type (with no operations except construction and projection - a C struct so to speak) or, on the other side of the spectrum, a class that contains only methods, but no state.
Sather is the oldest language i know of which treats types and classes separately. However, it is not completely rigorous, as one can still use a class as a variable type (i think), one just can't subtype it.
This is not terribly different from what C++ lets you do: you can use purely abstract classes to define types, and have all concrete classes implement them using public inheritance, but subclass each other using private inheritance. You then use the abstract classes for variable types, using the concrete classes only in constructor expressions.
Java lets you do more or less the same, defining types using interfaces and implementations using classes, but because there is no private inheritance, there is no way to hide the inheritance relationship of the classes.
Does that make any sense at all?
Java, pre-autoboxing. int and Integer are both types, but only the latter is a class.
A subjective question, hence if there are complaints I'll wiki, but I'd like to know what people's takes are on the different terms that are used for inheritance almost interchangeably.
We have "is-a", "extends", "derives", "subclasses" and simply "inherits"
The words we choose have a lot of meaning packed into them. What is your preferred term for "inheritance" and why?
Be compelling!
I most often uses "A subclasses B" (very direct) or "A inherits from B" (modestly more circumlocutory). "extends" is fine in languages where it's a keyword such as Java, but using it for (say) C++ or Python seems to be a bit of a stretch, for some reason. "IS-A" is a relationship constraint that inheritance must respect (Liskov's principle) and holds between instances (left side) and classes (right side) -- so you can say "x IS-A Foo" (when x is an instance of Foo or any subclass of Foo), but "Bar IS-A Foo" (where they're both classes) seems wrong, it would cause confusion in languages where classes are also instances of (meta)classes such as Python.
I like to say derived because it strongly implies the class / subclass relationship, but would be reasonably accurate in the more exotic cases, like multiple inheritance, interface implementation, and mixins.
I have various secondary arguments. For one thing, "parent" and "child" strongly imply a specific structural analogy that may clash with the actual relationship. For another, the entire point is the reuse of both code and also the abstraction itself. If memory was free and we all typed one million words per minute, it still would not be a good idea to copy and paste code, because that would hide the relationship between the various abstractions. Derived makes it clear that what you are doing is sharing at least a part of the abstraction you started with.
I was tought to consider that if you can connect to classes A and B between an "A is a B" (whale is a mammal) relationship, then they are bound by inheritance.
So i prefer IS A
There are differnet terminoligies in different languages.
"is a" suits dynamic languages and relects the chimeric qualities of perl/php/python and javascript objects. Lassie is a Dog, is a Mammal, is a Pet, is a Movie Star is also an asset of MGM.
"extends" suits the declarative, strict typing of nature of Java (and its lack of multiple inheritance!). "Lassie extends Dog", Lassie can walk and bark but cannot star or perform when she is implemneted in Java!
There are two ways to think about inheritance:
is-a : Polymorphism is when an interface is defined by a base class, but the implementation can be provided by an inherited class.
public class Polygon
{
public abstract int Points();
};
public class Triangle : Polygon
{
public override int Points() { return 3; }
}
void Foo( Polygon p )
{
int points = p.Points();
}
main()
{
Foo( new Triangle() );
}
extends - a way of capturing shared implementation.
public class iTouch
{
// cool pda features
}
public class iPhone : private iTouch
{
// phone features
// cool pda features comes from the base class
}
The preferred terminology usually depends greatly on the language, but I find that most OO developers understand each other regardless of the terms. (That being said, I definitely agree that word choice is important for maximizing effectiveness of communication.)
My preferred terminology is "subclasses" or "extends" for classes, and "implements" for interfaces. (In Objective-C, one "adopts" or "conforms to" a protocol, the inspiration for Java's interfaces.) Often, I use "parent" and "child" to describe the relationship itself.
I find that "is a" works best when contrasting with "has a" (composition), but it doesn't make sense for all forms of inheritance — sometimes, narrowing specificity makes sense, but not always. Similarly, there are times that "derives" just doesn't seem right — many people will understand it as specialization, but not everyone will. (For example, one can derive a proof, derive chemicals via a reaction, etc. Check out a dictionary entry on the word to see the variety of possible meanings, many of which have to do with a set of steps, which sounds more like an algorithm than inheritance.) On a side note, I've found that "base class" and "derived class" are preferred by many academics, but perhaps not as often in industry.
I'll say here that simplicity is a good thing. I'm all for "A Is a B" when referring to a subclass (A) that is obviously an instance of the parent class (B) (A Dog is a Mammal etc). If the relationship isn't that simple, I prefer to simply say "A is a subclass of B".
Class composition clearly makes the idea of "A Is a B" difficult, so there's obviously a time when "A Has a B" or "A Owns a B" is easier to understand.
For the continued sake of simplicity, I prefer to say a class conforms to a protocol, or implements an interface (although I don't program in java much).
The key as far as I'm concerned, is simplicity and ease of communication. If you're working on a project yourself, and will never have to discuss your design or code to anyone else, call it whatever you want. If you're working on a team, establishing the simplest possible standard of communication saves a lot of headache trying to decipher everyone's different slang for OOP patterns.
Here is the terminology that I prefer:
A inherits from B - This is the simples most precise method.
A derives from B - This is useful to generally describe cases where A inherits B or from some other class which derives from B.
Here is the terminology that I dislike:
A extends B - This is not quite accurate because a class can derive from another class, and just do things differently without literally extending it. It is also often used to describe the relationship between interfaces.
A subclasses B - Inheritance isn't restricted to just classes.
A is a B - If A inherits from B, it isn't necessarily the same things as a B, unless it can be used legally wherever a B can be used. If the design contract preconditions and postconditions of virtual function aren't properly weakened and strengthened in the new class, the A is not technically a B because it violates the Liskov substitution principle.
I like to kick it old-school and say "A implies B" or "A is less than B". These are not ambiguous like the other terms, i.e. they have precise meanings.
Footnote: I sometimes say "better than" and "worse than" to mean supertype and subtype relations, respectively. I do this to disambiguate this relation when it's not clear that the objects in question are types. I inherited this habit from Edward Kmett.
See here.
What makes a type different from class and vice versa?
(In the general language-agnostic sense)
The following answer is from Gof book (Design Patterns)
An object's class defines how the
object is implemented. The class
defines object's internal state and
the implementation of its
operations.
In contrast, an object's
type only refers to its interface - a
set of requests to which it can
respond.
An object can have many types,
and objects of different classes can
have the same type.
//example in c++
template<typename T>
const T & max(T const &a,T const &b)
{
return a>b?a:b; //> operator of the type is used for comparison
}
max function requires a type with operation > with its own type as one of it interface any class that satisfies the above requirement can be used to generate specific max<particular class/primitive type> function for that class.
Inspired by Wikipedia...
In type theory terms;
A type is an abstract interface.
Types generally represent nouns, such as a person, place or thing, or something nominalized,
A class represents an implementation of the type.
It is a concrete data structure and collection of subroutines
Different concrete classes can produce objects of the same abstract type (depending on type system).
*For example, one might implement the type Stack with two classes: SmallStack (fast for small stacks, but scales poorly) and ScalableStack (scales well but high overhead for small stacks).*
Similarly, a given class may have several different constructors.
The banana example.
A Banana type would represent the properties and functionality of bananas in general.
The ABCBanana and XYZBanana classes would represent ways of producing bananas.
(Different banana suppliers in real life, or different data structures and functions to represent and draw bananas in a video game).
The ABCBanana class could then produce particular bananas which are
instances of the ABCBanana class, they would be objects of type Banana.
It is not rare the programmer provide a single and only implementation for a type. In this case the class name is often identical with the type name. But there is still a type (which could be extracted in an interface if required), and an implementation (which would implement the separate interface) which builds instances (objects) of the class.
I always think of a 'type' as an umbrella term for 'classes' and 'primitives'.
int foo; // Type is int, class is nonexistent.
MyClass foo; // Type is MyClass, class is MyClass
Type is the umbrella term for all the available object templates or concepts. A class is one such object template. So is the structure type, the Integer type, the Interface type etc. These are all types
If you want, you can look at it this way: A type is the parent concept. All the other concepts: Class, Interface, Structure, Integer etc inherit from this concept.i.e They are types
Taken from the GoF citation from below:
An objects's class defines how the
object is implemented .The class
defines the object's internal state and
the implementation of its
operations.
In contrast, an objects's
type only refers to its interface - the
set of requests to which it can
respond.
I want to provide an example using Java:
public interface IType {
}
public class A implements IType {
public A{};
}
public class B implements IType {
public B{};
}
Both classes A and B implement the interface and thus are of the type IType. Additionally in Java, both classes produce their own type (respectively to their class name). Thus the class A is of type A and IType and the class B is of type B and IType satisfying:
An object can have many types,
and objects of different classes can
have the same type.
The difference between subtypes and subclass probably helps to understand that issue as well:
https://www.cs.princeton.edu/courses/archive/fall98/cs441/mainus/node12.html
In general language-agnostic sense - Class is an realization of the Type.
Often when this is the only realization of that type, you can use both terms to reference it in some context.
On the contrary, for example, in C# context - Class is just one of the many more implementations of a Type concept like primitives, structs, pointers etc.
Type contains description of the data (i.e. properties, operations, etc),
Class is a specific type - it is a template to create instances of objects.
Strictly speaking class is a special concept, it can be seen as a package containing subset of metadata describing some aspects of an object.
For example in C# you can find interfaces and classes. Both of them are types, but interface can only define some contract and can not be instantiated unlike classes.
Simply speaking class is a specialized type used to encapsulate properties and behavior of an object.
Wikipedia can give you a more complete answer:
Definition of class
Definition of data type
Type is conceptually a superset of class. In the broader sense, a class is one form of type.
Closely related to classes are interfaces, which can bee seen as a very special kind of class - a purely abstract one. These too are types.
So "type" encompasses classes, interfaces and in most languages primitives too. Also platforms like the dot-net CLR have structure types too.
To illustrate it the fastest way:
A Struct is a Type, but a Struct is not a Class.
As you can see, a Type is an "abstract" term for not only definitions of classes, but also structs and primitive data types like float, int, bool.
I think of a type as being the set of things you can do with a particular value. For instance, if you have an integer value, you can add it to other integers (or perform other arithmetic operations), or pass it to functions which accept an integer argument. If you have an object value, you can call methods on it that are defined by its class.
Because a class defines what you can do with objects of that class, a class defines a type. A class is more than that though, since it also provides a description of how the methods are implemented (something not implied by the type) and how the fields of the object are laid out.
Note also that an object value can only have one class, but it may have multiple types, since every superclass provides a subset of the functionality available in the object's class.
So although objects and types are closely related, they are really not the same thing.
To add another example of distinction: in C++ you have pointer and reference types which can refer to classes, but are not classes in and of themselves.
Bar b; // b is of type "class Bar"
Bar *b2 = &b; // b2 is of type "pointer to Class Bar"
Bar &b3 = b; // b3 is of type "reference to Class Bar"
Bar *b4[7]; // b4 is of type "7-element array of pointers to Class Bar"
Bar ***b5; //b5 is of type "pointer to a pointer to a pointer to Class Bar"
Note that only one class is involved, but a near infinite number of types can be used. In some languages, function are considered "first-class-objects" in which case, the type of a function is a class. In others, the type of a function is merely a pointer. Classes generally have the concepts of being able to hold data, as well as operations on that data.
My thoughts are pretty much in line with aku's answer.
I see classes as a template for building objects, while types are a way to classify those objects, and provide us with an interface to them.
Python also adds metaclasses, that are just a mechanism to build classes, in the same way as classes build objects (and well, classes and metaclasses are both objects).
This response to the same question in lamba the ultimate seems to me like a perfect explanation.
Types in C, like Int Float, char etc define data that can be acted on with specific methods that can operate on them. It's no more complicated than that. Like for int I can add, subtract multiply and maybe divide. Those are my methods (or operations) for int. A Class is simply a definition of a new type. I first define what the data looks like. Maybe its a single bit. Maybe it's two words like a complex with a real and imaginary part. Or maybe its this complex thingy with 309734325 bytes representing the atomic makeup of a weird particle on Jupiter. I don't care. Just like an integer, I get to make up the operations I can do with this new data type. In the case of the integer I had add, subtract, etc. With this new data type I can define whatever operations I think make sense. They might be add subtract etc. but they may add other things. These are whatever methods I decide to add to my class.
The bottom line is that with a type in C, you have a definition of what the data is, ie; a byte, word, float, char etc. But any of these also implies what operations are legal and will produce reliable results.
A class is no different except it is up to you to define the interface and acceptable operations. The class defines these things and when you instantiate it in an Object it defines the behavior of the object just like a type definition defines the behavior of an integer when you operate on it.
Classes just give you the flexibility to define new types and everything about how they operate.
Once this is defined, every time I instantiate an object of class "thingy", it has the data structure I defined and the operations (methods) that I said you can do with it. The class "thingy" is clearly nothing more or less than a new type that C++ lets me define.
Type generally refers to the classification of primitive values - integers, strings, arrays, booleans, null, etc. Usually, you can't create any new types.
Class refers to the named set of properties and methods which an object is associated with when it is created. You can usually define as many new classes as you want, although some languages you have to create a new object and then attach methods to it.
This definition is mostly true, but some languages have attempted to combine types and classes in various ways, with various beneficial results.
Types and classes are related but not identical. My take is that classes are used for implementation inheritance, whereas types are used for runtime substitution.
Here is a link explaining the substitution principle and why subclasses and subtypes are not always the same thing (in Java for example). The wikipedia page on covariance and contravariance has more information on this distinction.
In langugages like Haskell, the concept of Class doesn't exist. It only has Types. (And Type Class. Not to be confused with Class, Type Class is more of an abstracted version of Type).
Monad is a Type Class.
class Monad m where
(>>=) :: m a -> ( a -> m b) -> m b
(>>) :: m a -> m b -> m b
return :: a -> m a
fail :: String -> m a
From a (pure) functional programming perspective, Type is more fundemental than Class as one can trace its root to Type Theory (e.g. from a PTL perspective, lambda calculus with types and without types behave quite differently), while Class is really just a construct to enable OO.
In languages that only support Type and don't support Class, functions are often treated as first-class citizen.
Meanwhile, when a language makes a distinction between Type and Class, functions are more of a second-class citizens that can be attached to Objects, etc. And yup, often you can attach a function onto a Class itself (aka a static function).
Interesting question. I think aku's answer is spot on. Take the java ArrayList class as an example
public class ArrayList<E> extends AbstractList<E>
implements List<E>, RandomAccess, Cloneable, java.io.Serializable
An instance of the ArrayList class is said to be of type of every superclass it extends and every interface it implements. Therefore, an instance of the ArrayList class has a type ArrayList, RandomAccess, Cloneable, and so forth. In other words, values (or instances) belong to one or more types, classes define what these types are.
Different classes may describe the same type.
Type consists of these parts:
Operations = syntax
Description of operations = semantics
Class consists of these parts:
Operations = syntax
Implementation (= various implementations describe same semantics)
Some notes:
Interface (as in Java) is not type, because it does not describe semantics (describes only syntax)
Subclass is not subtype, because subclass may change semantics defined in superclass, subtype cannot change supertype semantics (see Liskov Substitution Principle, e.g. this LSP example).
Obviously, as there are languages with type system that are not OO programming languages, type must be a broader concept than class
Even in languages like Java, int is a (primitive) type, but not a class.
Hence: every class is a type, but not every type is a class.
If we think to this question in C# context, we reach bellow answer.
C# type system is divided into following categories:
Value types:
Simple types: like int, long, float, etc.
Enum types
Struct types
Nullable types
Reference types:
Class types
Interface types
Array types
Delegate types
As you can see there are many types in C# which Class is only one of them.
There is just one important note:
C#’s type system is unified such that a value of any type can be treated as an object. Every type in C# directly or indirectly derives from the object class type, and object is the ultimate base class of all types. Values of reference types are treated as objects simply by viewing the values as type object. Values of value types are treated as objects by performing boxing and unboxing operations.
so as I see, type is an umbrella over many items which class is one of them.
Referece: CSahrp Language Specification doc, page 4
This was a good question for me, which made me think hard. I would dare to say that Class is a compiletime thingy and Type is a runtime thingy. I say this because you write classes not types. The compiler then creates types from classes, and the runtime use types to create instances of objects.
types are programming constructs that helps the compiler to perform type checking and ensure that the variables have the right properties for an operation.
classes are user defined types that an objects or variables referencing them could have. These are also subjected to type checking.