If you want to show, for example, that a class Match contains an instance of class Game and class Set, then do you just simply have them in the attributes or do you have a line to the classes representing that when the instance of Match is created then that also creates an instance of Game and Set?
Here's what I mean in code:
public class Match {
private Set set = new Set();
private Game game = new Game();
}
This kind of relationship between classes is called association. Association is marked in UML with simple arrow:
We also have to types of association:
1. Composition - when our class contains reference to the other class and other class cannot exist without our class.
For example Human contains Hand, Leg, Heart, Car conatins Engine, Wheels. This type of association is understood as strong reference in garbage collection programming languages.
2. Aggregation - when our class contains reference to the other class and other clas can exist without our class, for example School contains Student.This type of association is understood as weak reference in garbage collection programming languages.
Composition is definetly the stronger one.
Hope it helps.
Both listing as attributes and showing as association (line pointing to another class) are valid and have exactly similar semantic.
Showing graphically rather than textually gives you opportunity to optionally present additional information: aggregation/composition, availability, ownership. Yet if none of this is present or important, the meaning is precisely the same and one can be replaced with another depending on what is more useful for you.
Related
my program runs through source code easily enough and I can detect easy relationships such as implementation or inheritance using extends just by searching for where the class is defined. However, I'm a bit stuck with ideas on how to detect other relationships such as if a class has association or aggregation with another class.
So far I have tried parsing the code and looking for where other methods are called but I'm not sure of an exact code definition of these relationships.
Sorry if I am being unclear I can try and explain better if you don't understand just let me know in the comments.
Aggregation and composition both look like member variables in Java
e.g.
class MyClass {
private HerClass h;
}
MyClass HAS-A HerClass member - so that's composition or possible aggregation. You could tell the difference based on whether MyClass creates the HerClass - that would PROBABLY be composition.
Association is based on dependency. Why don't you use the imports to find out which classes are depended on? Or you could scan any use of type names in the code - the moment a type name is mentioned, there's a "uses" association.
The problem is that there is not any strict definition how to translate Java classes relations in associations, dependencies and aggregations. You should set the rules yourself, only check them against the UML standard.
I would advice the following :
UML Java
Dependency A->B Class A mentions class B
Association A->B Class A has reference {that can have reference} (it is recursive!} to class B
Composition A->B Class A has array or collection of B or of references to B AND
(black diamond) no other classes have instances of B or references to them,
either single or collective (arrays, collections)
Shared aggregation A->B Class A has array or collection of B or of references to B AND
(empty diamond) at least one other class has an instance of B or references to such,
either single or collective (arrays, collections)
If according to the last rule, you get two-sided shared aggregation A-B, it is forbidden. So, change it to two mutual shared aggregations.
Remember, that Association and Shared aggregation have NO strict definitions, only limitations.
Is a class an instance of an object?
Can you create many objects from the same class, and can a class have many instances?
Thank you for your help, I'm reading a book on Java programming and am currently confused about these definitions.
A "class" conceptually is not an object (or an "instance of an object", which makes no sense really), but rather a sort of blueprint from which objects are created. Objects are instances of classes. You can indeed instantiate a class many times.
Don't confuse this with instances of the Class class, which are objects (e.g. String.class, int.class etc.).
A class describes the structure of an object and is not an instance.
An instance is an object that conforms to the structure defined by the class.
There can be many instances of a class.
For example, consider a "Person" class. When creating the class, you could say, "A person may have a first name or a last name," but you're not creating an actual person, you're just saying what makes up a person. When you create a person, you create an instance of the class "Person" and you may have many people, which means having many instances of the class "Person".
The CLASS works as a BLUEPRINT which allows you to create OBJECTS based on this BLUEPRINT.
You CAN create many instances (OBJECTS) of the same CLASS.
To clarify:
Object - Objects have states and behaviors. Example: A dog has states
- color, name, breed as well as behaviors -wagging, barking, eating. An object is an instance of a class.
Class - A class can be defined as a template/blue print that describes
the behaviors/states that object of its type support.
A class is not an instance of an object. In fact, an object is an instance of a class. Here is the explanation,
Conceptually, each class represents and describes the characteristics of an independent concept in a program. these characteristics are also owned by any object of this class type. Usually, instance variables of a class defines properties of an entity. For example, if you have a class called Student, then obviously this class should have instance variables that represents student's characteristics such as name, level, grade...etc. Also, it can have methods like getGrade (), getName (). Now, any object of type Student will have the properties defined by its class (eg. name, level..), meaning the information stated in the class is encapsulated in its objects. Also, this object can be used to reach for the methods like getGrade or getName (again because these methods are encapsulated inside each object).
The class is the definition of a single concept structure, and the object is an implementation of this structure. That's why, we say, an object is an instance of a class. Note that we can have various instances (objects) of a single class, each object will encapsulate the same structure defined by its class, but with different values. For example, you may have several objects of the class Student each represents a different student with different name, level, grade...etc. Although these objects are different, they share the same structure, meaning they are all students.
Data encapsulation provided by class/object technique is really useful. Suppose you have 100 students who you need to store their names, levels, and any other related information. Instead of defining 100 String variables to store each student name, and 100 int variables to store the levels, you simply create a class which defines a student structure and create as many objects as you want. It saves both time and effort, and it makes debugging much easier.
My program has one public class followed by a constructor and 2 local classes (the inner classes have action events) called from a method. There is one additional static methods.
Public class
Constructor
local Classes
Methods
I am very confused to how the UML diagram would look for this. I have made one for a super class and subclasses before and it was straightforward enough, but i'm not sure how to include local classes and action events (like key listener).
Thank you for your help. I am new to java so go easy please.
Edit: I meant Class diagrams not all UML in general. Sorry.
A quick Google search yielded the following from http://www.sparxsystems.com/resources/uml2_tutorial/uml2_classdiagram.html:
Nestings
A nesting is connector that shows the source element is nested within the target element. The following diagram shows the definition of an inner class, although in EA it is more usual to show them by their position in the project view hierarchy.
(source: sparxsystems.com)
UML defines 14 different types of diagrams. In the following I will assume you refer to the most common one: the Class Diagram.
Local classes have no inheritance relationship to the class they are defined in. However, each of their instances contain a reference to an instance of the class where they were defined. When you write new LocalClass() (which is the most usual), the referenced "parent" object is this. When you write aDefiningClassInstance.new LocalClass(), the referenced "parent" object is aDefiningClassInstance.
That clarified, the relationship of what you call the "public class" with the local classes is one of composition. Cardinality depends on you particular case, but it's most probably one-to-one with each local class.
Modern versions of UML introduce syntax for inner classes (which are practically the same as local ones), but IMHO this is excesively related to specific programming languages and does not represent the high-level relationships that UML is usually used for.
Whatever method calls the event handlers, it should belong to a class directly or indirectly storing references to them. Here you have two additional UML aggregation relationships (also of probable cardinality of one-to-one) if the calling method belongs to a class different to the defining one.
I am curious as to how the concept of "inheritance" takes place in the world of object oriented programming. Let me explain my dilemma (I came across this dilemma while studying Java but I hope that my question is generic in nature) :
Suppose there is a class A and a class B. Class A "inherits" Class B. What does this actually mean? Does the compiler make a "new" class, which is THEN instantiated into an object which contains the elements of both the classes A and B behind the scenes? If that's the case, then how are the access restrictions implemented according to the access specifiers?
For a moment, I wondered if it happens in the following manner :
An object of class A is created and then an object of class B is created. Java then somehow "link" the members of A to the members of B and make it appear as if they belonged to the same class and it does that according to the access specifiers.
But then, it occurred to me that there is a fault with this theory. Suppose two different classes, B and C are inheriting class A. Then, if we are going to make objects of class B and class C, then they'll have their OWN copies of the elements of class A. So this theory fails too.
I was just trying to explain the confusion about inheritance that I have in my mind. It's giving me headache. Please help.
EDIT : This is a link to a discussion related to my question which i found on this site.
Do subclasses inherit private fields?
I may fail, but I'm going to take a stab at an explanation on this for you.
In honesty, I think you may be making what is really a very classic mistake in how you conceive object programming - and that's making the distinction between objects and classes. Object creation in virtually any object-oriented language is one of construction based on a class definition. From your question, it sounds as though you are mentally modeling an OO language in general and object inheritance in particular as aggregating discrete objects, where in reality the objects are being defined in terms of aggregated class definitions.
public class A
{
public A();
}
public class B:A
{
public B();
}
public class C:B
{
public C();
}
In your A->B->C model, C's definition is in terms of its own unique properties plus all the members of its immediate ancestor, B, which, in turn, is defined in terms of its own unique properties plus all the members of its immediate ancestor, A. The process of creating the object is still a unique and discrete event, and the object, despite its multi-layered heritage, is still only one object at instantiation time.
Regarding the visibility of certain members: When a class author designs and builds a class, he makes certain decisions about what he makes available in two distinct perspectives: that which is exposed to consumers of the class, and that which is exposed or available to subclasses. Members and fields declared private are every bit a part of descendant classes, even if they are "contractually" forbidden to be accessed by subclasses. You could make a crude analogy that a TV has a "public" interface of an on/off button, volume control, and color controls, but has "internal" controls not intended for the consumer such as the internal electronic components, or the power supply. They're still very much there even though they are not "visible" or "available" to consumers or subclasses.
Now, that said, there are constructs in most OO languages that reflect the properties you describe - multiple objects - and that involve a design pattern known as Composition (or, sometimes, Aggregation. This is where a class isn't derived from an ancestor class - typically because the class is declared "sealed" (C#) or "final" (Java) (or other designation that prohibits inheritance). That forces a developer interested in using the class to make it a member of another class, such that when the an object of the class is instantiated, you DO have discrete objects of both classes.
You might have the following:
public final class InterestingThing
{
//definitions
public InterestingThing()
}
public final class MyThing
{
InterestingThing _interestingThing = new InterestingThing();
public MyThing()
}
This is very much the kind of scenario you were describing in your original question, in which the creation of MyThing implies the distinct creation of an InterestingThing. Keep in mind, too this structure is generally forced by the design and definition of the original class of interest.
Ultimately, objects are defined by their classes, and multiply-inherited classes are still just a class, but in a refined, hopefully increasingly robust, hierarchy based on good, incremental object design.
I hope, in some way, this explanation helps to answer your question.
Class A "inherits" Class B. What does this actually mean?
If class A extends class B, it inherits all members (fields and methods) of B, i.e. class A will have these members even through they are not declared in the body of class A.
Whether class A is permitted to access a particular member is an unrelated matter.
An object of class A is created and then an object of class B is created. Java then somehow "link" the members of A to the members of B and make it appear as if they belonged to the same class and it does that according to the access specifiers.
No. A single object of class A is created. That object just happens to have all inherited members, too. For instance, if you have:
class B {
private int x;
}
class A extends B {
private int y;
}
The runtime will store, for every object of class A, the value of x and the value of y.
That code in class A does not access the value of x is enforced by verifying that the source code of A does not use the name x upon compilation, and by verifying that the bytecode of A does not refer to the field x upon loading the class at runtime. Put differently, access modifiers are independent of memory layout.
The word 'class' is used very loosely in Java tutorials and study material. There are many many different meanings to this word. Can some body please enumerate and explain all meanings of this word. E.g.: 'class' means an object, 'class' is an file extension, 'class' is the first word used in declaring object, etc.
There are many many differnt meanings
to this word.
No. There is exactly one meaning:
A class is a blueprint for object instances
You define such a blueprint in your Java source code by using the 'class' keyword
The Compiler will turn your source code into byte code files - one file with the extension .class for each class in your source code
There are different places where the word "class" occur, but they are all related to the same basic meaning. Or are you also confused by the fact that "World of Warcraft" is a game you bought in a store, a shortcut on your desktop, and the name of a folder on your harddisk?
Class is an object-oriented term. A class is a description of a set of objects, the common behaviour they have and the state they have. Classes can inherit state and behaviour from superclasses. To put this another way:
Human is a class. Humans have state:
Eye colour;
Skin colour;
Type and colour of hair;
Height;
Weight;
and so on.
and behaviour:
Walk;
Run;
Swim;
Eat;
Drink;
etc.
Human has two subclasses in this example: Man and Woman. They have all the state and behaviour of Human but also some state and behaviour unique to each, like the obvious anatomical differences as state and behaviour as, for example, women can have babies.
An object is an instance of a slass. To put this another way: Megan Fox is an instance of the class Woman. Being a Woman, she is also an instance of the superclass Human.
As for Java, it generates one .class file for each class encountered when it compiles source code. Source files can contain multiple class files.
There is a keyword "class" use to define a class in Java. There is a "Class" class which is the parent class of all classes. And there is a ".class" which is a file extension.
You should be able to determine which is which from context.
class describes the blueprint or prototype from which objects are created.
object is an individual instance or unit of that class
A file can have several classes but just one public. The public one has to be the same name as the file for e.g public class Car - has to be Car.java.
You should name your classes starting with an uppercase and objects starting with an lowercase. A class contains a set of variables which tell you the state of a object from this class. A class contains a set of methods which tell you the behavior of the objects.
A class is like a describtion from one or more similar objects. A object is an instance of that class. You can have a Class Car with the variables speed, color, name. Then you can make for e.g. 2 objects peugeot and a porsche. Both can have diffrend speed, color and a name. You can make as many cars as you want by making a object from the class Car.