So I'm currently working on an ontology which has an EnumerationClass set up in a similar manner to how Enumeration is set up in Schema.org (https://schema.org/Enumeration).
It has subclasses which I'll call ProgramTypeEnumeration and SubstanceTypeEnumeration. Both of these have defined instances. Let's say ProgramTypeEnumeration has instances BasicProgram and AdvancedProgram.
Then there is a property called hasProgramType which relates an AcademicClass class to a program type in the ProgramTypeEnumeration. My assumption is that domain would be AcademicClass and range would be ProgramTypeEnumeration.
That being said, my understanding is that an enumeration is effectively a list. Is it correct to say that BasicProgram is an instance of ProgramTypeEnumeration when BasicProgram is not a list? As well, I'm not saying that hasProgramType has a range of instances of lists of programs, but a range of instances of programs. Would it be better to have a class ProgramType which is a part_of a ProgramTypeEnumeration and then have ProgramType be the range of hasProgramType?
As well, more broadly, is every finite class with a set number of instances technically a subclass of enumeration? e.g. would a class "U.S. State" be a subclass of enumeration if it has exactly 50 instances? Would "ZIP Code" be a subclass of enumeration since it technically also has an exactly number of instances? How do I define whether a class is or isn't an enumeration?
EDIT 1: Attempting to provide a more clear example here.
So Schema.org has an Enumeration subclass which is "MedicalSpecialty" (https://schema.org/MedicalSpecialty). "MedicalSpecialty" has instances which are medical specialties (anesthesia, cardiovascular, etc.).
In Schema.org, the property "medicalSpecialty" (https://schema.org/medicalSpecialty) has rangeIncludes "MedicalSpecialty" (the Enumeration subclass).
Two fundamental questions:
(1) Is there a benefit to having "MedicalSpecialty" as an Enumeration subclass and not a subclass outside of an enumeration?
(2) Is an Enumeration a class which contains lists, and if so, wouldn't an instance of an Enumeration also be a list, instead of a single option? (i.e. wouldn't an instance of the "MedicalSpecialty" enumeration itself be an enumeration?)
The main advantage of an Enumeration is that it makes clear to everyone that uses your ontology that a class consists of a finite list of named individuals. As for the example you mention of MedicalSpecialty, you will see that Schema.org has a list of "Enumeration Members" that are the named individuals MedicalSpecialty consists of.
An Enumeration and a plain class are indeed very similar. Both an Enumeration and a class consists of individuals (also called instances). The difference is that for a class all the individuals it may consist of is usually not known, but for an Enumeration it is known. Furthermore, a class may have a finite or an infinite number of individuals, whereas an Enumeration has a finite number of known individuals.
If you have a list of named individuals, then it is a good idea to use Enumeration.
Answers to your questions:
(1) The value of using Enumeration is to make clear to users the expected values to use for properties as for example with the medicalSpeciality property. If a reasoner or rules engine is used, these will be able to pick up errors when example the medicalSpeciality property is used incorrectly.
(2) An Enumeration is not a class that contains lists. Rather an Enumeration is a class that consists of named individuals. Thus, an instance of an Enumeration is an individual just like an instance of a class is an individual. An instance of an Enumeration is not an Enumeration, it is an individual.
If this may be helpful, I have written about Schema.org and OWL on my blog.
Related
The above statement is taken from www.uml-diagrams.org section Assocation ends from the rather beginning.
Is there a real-world example for this?
What exactly means owned by association itself?
What is association class or how is it implement in code?
Here's my attempt. I also was unsure about the nature of an association in the past and until not so long ago where I sort of grasped it. For the full pain you have to go through pp. 197 of UML 2.5 (11.5 Associations)
What is an association?
When you have a number of classes (we may call them A, B, etc. here for brevity. They are designed to be somewhat self-consistent. So you have properties and operations which work with the latter. If our A is some mathematical class you may have a well working black box. Fine.
Now, when any class is in need of another (e.g. the B class needs objects of type A to have that math toolbox handy) you create some reference. In a programming language that will be some variable holding a reference to an instance of the needed class. That's the moment where you have an association.
In UML you can denote such an association as a property typed with the other class. Or (!) you draw a line for an association between both class boxes and place the role name towards the referenced class (telling the name of the variable the programmer shall use). This being quite simple got me some headaches since I saw notations with both property and role notation. I have not fosteres the UML spec as tho what this would mean, but I established a rule I was also teaching that this is not allowed. Tools like EA do not support roles in a correct way which forces you to manually maintain your diagrams. That is, if you have an association role from B to A and the diagram does not contain A then you should show the role as property (see my note about dot notation below). But once you place A on that diagram you should see the assocation line with the role name, but not the property (pretty confusing I admit).
Note: Dot notation
Since UML 2.5 (or was it 2.1?; but see p. 200 of UML 2.5) the OMG guys introduced the so called dot notation. That is, you have a little dot at the association line end along where the role name is. This dot indicates that the role name is actually the property of the referencing class. Pretty much what I was talking about above. And what I thought was the intention. So, I have no idea what a not-owned property would be in any case. May be a good question to be asked.
Associaton class
Assume you have class C which reflects some kind of relation between A and B (and eventually D, E, etc.). Doing that makes it an association class. It's doing that by exactly the same technique as above, just for multiple classes. (If a class has multiple relations to other classes it's not necessarily an association class, but only if it's main purpose is to set these into some relation. YMMV)
So here you have the case where an association owns the role since you have a real object. The association explained above exists only as a reference in the programming world, not a complex storage structure like an association class.
First of all, you should understand that, as opposed to the explanation of #qwerty_so, in data/information modeling, relations between two objects (called "links" in UML) are a first-class citizen. Logically/conceptually, they exist next to objects. In terms of OO implementation, they may exist either within one or both of the two participating objects in the form of object references, or outside of the two participating objects in the form of another object representing the "link".
Likewise, in data/information modeling, an Assocation, which classifies "links", is a first-class citizen that logically/conceptually exists next to the involved Classes. A binary Assocation is implementated either within one or both of the two (Java/C#/JS/etc.) classes involved in the form of a reference property (or possibly two mutually inverse reference properties), or outside of the two classes in the form of another class representing the Assocation.
In the case where a binary association has one ownership dot at one of its ends, it is unidirectional and implemented as a reference property in the corresponding class, while in the case where it has ownership dots at both of its ends, it is bidirectional and implemented as two mutually inverse reference properties, one in each of the involved classes.
What exactly means owned by association itself?
An Assocation End of a binary Assocation can be owned either by the Class on the opposite side or by the Assocation itself. In the former (more common) case, the Assocation End corresponds to a reference property of the (Java/C#/JS/etc.) class on the opposite side. In the former (less common) case, the Assocation End corresponds to a reference property of the (Java/C#/JS/etc.) class that represents the Assocation.
In principle, there could be an OOP language that supports Assocations as first-class citizens, having a keyword "assocation", in addition to "class".
What is association class or how is it implement in code?
The need for an Association Class arises when the "links" of an Association have to be characterized with the help of attributes, or when they have to be processed with the help of special operations. In such a case, an Association Class allows defining these attributes or operations. An Association Class is implemented in the form of a (Java/C#/JS/etc.) class that has corresponding reference properties for each of the Association's ends.
I have several small classes that are similar in that they only possess a few properties and no methods, and their instances often get passed around and put into arrays and what not. Is there a naming convention for such a class? At first I was naming them xxxObject, but in OOP that's not really what an object is. Then I considered naming them xxxHelper, but helper seems to indicate methods. What should I add on to the end of this type of class's name?
I would not make these classes at all, it looks like you're using some kind of a global enum or a dictionary.
Enum from C would indicate a key and an integer value.
Dictionary from Python would indicate key and value, value doesn't have to be a specific type.
I would probably use XXDictionary.
I have read a definition of encapsulation which stated that "Encapsulation is the wrapping of data and functions into a single unit called class" .My question is that can we not use the term object instead of class in the definition because at last objects are created using the classes and objects only encapsulate data and functions inside them?
I don't have a problem with replacing "class" with "object" in the example sentence. It remains valid in class-based OOP languages while being more appropriate for prototype-based OOP languages. Classes are just a type system for OOP after all and not as fundamentally essential as encapsulation is.
I would, however, want to improve that sentence to make it clear that data and functions aren't "wrapped" in the same way. Data must be hidden and only be accessible to methods of an object.
The more important question to consider is why encapsulation is essential to true oop. Objects are to hide their attributes and inner workings, and present an interface for use by other objects. oop begins to break down when this encapsulation is broken. Code becomes harder to maintain if everyone has their hands on everyone else’s data. Consider setters and getters and all the ways we tend to break encapsulation. True object thinking is not primarily about classes and polymorphism. It is definitely about encapsulation and interfacing between objects.
Not every class has objects.
We can have static classes that have no objects.
If the definition were changed to use the word "object", these classes would not be covered. With "class", both static and non static classes are covered.
Even if a class is not static, it could have static data and functionality, again the term class is more appropriate.
Other classes may be abstract and therefore have no objects, they may still provide some encapsulation.
Template classes could also be though of as being capable of encapsulation even though there will be no objects of the template itself - only objects of "concrete" classes with specific types provided for the templates type parameters.
Also, the word "single" becomes a bit confusing if we apply it to objects since we can have multiple object of a class.
Cid's comment offers an additional reason for "class" over "object".
I assume you have a rough idea of what encapsulation is? So you are asking why couldn't the definition bee rephrased to
Encapsulation is the wrapping of data and functions into a single unit called an object.
Because encapsulation has nothing to do with objects at all. You can create some class called Car and it has some fields like engine, seats, steeringWheel and some methods applyBrakes, openWindow as well as some private members. Now you can say that the class encapsulates the inner workings of a car into a single unit - the Car class.
See? I didn't say anything about objects. Car objects are really just a bunch of references in memory pointing to other Engine, Seat and SteeringWheel objects.
In my opinion, "data" is the problematic term. Classes encapsulate attributes and methods that work on these attributes together. "data" suggests actual data and not meta data. That is probably why you thought of objects instead of classes.
Other than that, I would not replace class with object here, because it leaves out the important feature that all objects from one class have the same methods. With object, one could interpret that each object has its own set of functions.
On page 13 in the GoF book there is a statement:
Two objects of the same type need only share parts of their interfaces.
I am not sure I understand this sentence.
EDIT: full quote might indeed help to understand that
A type is a name used to denote a particular interface. We speak of an
object as having the type "Window" if it accepts all requests for the
operations defined in the interface named "Window." An object may have
many types, and widely different objects can share a type. Part of an
object's interface may be characterized by one type, and other parts
by other types. Two objects of the same type need only share parts of
their interfaces. Interfaces can contain other interfaces as subsets.
In their language, an objects interface is the the entire public contract of the object (Don't think language implementation here).
The set of all signatures defined by an object is called the interface
to the object.
A type is more like what you would think of as a declared interface....
A type is a name used to denote a particular interface.
Imagine:
public class Foo : IBar, IBaz {}
public class Fuz : IBar, IBuz {}
A Foo and a Fuz are both IBar "types" but they only share that aspect of their respective interfaces.
a more full quote is:
A type is a name used to denote a particular interface. We speak of an
object as having the type "Window" if it accepts all requests for the
operations defined in the interface named "Window." An object may
have many types, and widely different objects can share a type. Part
of an object's interface may be characterized by one type, and other
parts by other types. Two objects of the same type need only share
parts of their interfaces. Interfaces can contain other interfaces as
subsets.
and pretty clearly, i think, this is talking about multiple inheritance. for example you might have TextWindow and MenuWindow that both subclass Window along with other classes. both objects can be considered, in the sense they are using, to have "type" Window, and they will both implement the operations associated with that type - they will both have Window's methods. but TextWindow may also subclass TextEditor while MenuWindow does not, so their total set of methods (what they mean by "interface") are not the same, even though the Window part overlaps.
http://www.uml.org.cn/c++/pdf/DesignPatterns.pdf
I don't know what it means as I don't have the book. But an interface is the method signatures of the class, combined with the public variables. As a subtype of a particular type, is also a type of its parent class, it can have methods that it parent does not have, hence it only shares some of the interface of the parent. I have no idea if that is actually what it was talking about though.
A friend who is new to OO programming asked me the difference between a Member and Property, and I was ashamed to admit that I couldn't give him a good answer. Since properties can also be objects themselves, I was left with a general description and list of exceptions.
Can somebody please lay out a good definition of when to consider something a member vs. a property? Maybe I'm bastardizing the concept, or is it just that a member is just the internal name I use, and the property is what's exposed to other objects?
I don't think that not knowing the answer to this question has affected the quality of my programming, and it's just a semantics point, but it still bothers me that I can't explain it to him.
A property is one kind of member. Others might be constructors, methods, fields, nested types, conversions, indexers etc - depending on the language/platform, of course. A lot of the time the exact meaning of terminology depends on the context.
To give a C#-specific definition, from the C# 3.0 spec, section 1.6.1:
The following table provides an overview of the kinds of members a class can contain.
(Rows for...)
Constants
Fields
Methods
Properties
Indexers
Events
Operators
Constructors
Destructors
Types
Note that that's members of a class. Different "things" have different kinds of members - in C#, an interface can't have a field as a member, for example.
Neither of the two terms has any defined meaning whatsoever in Object-Oriented Programming or Object-Oriented Design. Nor do they have any defined meaning in the overwhelming majority of programming languages.
Only a very small number of programming languages have a concept called property or member, and even fewer have both.
Some examples of languages that have either one of the two are C++ (which has members), ECMAScript (which has properties) and C# (which has both). However, these terms don't necessarily denote the same concepts in different programming languages. For example, the term "member" means roughly the same thing in C++ and C#, but the term "property" means completely different things in ECMAScript and C#. In fact, the term "property" in ECMAScript denotes roughly the same concept (ie. means roughly the same thing) as the term "member" in C++ and C#.
All this is just to say that those two terms mean exactly what the relevant specification for the programming language says they mean, no more and no less. (Insert gratuitous Lewis Carroll quote here.)
Properties is one kind of members.
In C#, for example, a class can have the following members:
Constructors
Destructors
Constants
Fields
Methods
Properties
Indexers
Operators
Events
Delegates
Classes
Interfaces
Structs
MSDN: C#: class
Members are just objects or primitive types belonging to a class.
Properties give you more power than members. It's like a simplified way to create getters and setters letting you make, for instance, public getters and private setters; and put whatever logic you want in the way it will be read or written to. They can be used as a way to expose members, being possible to change the reading and writing policy later more easily.
This applies to C#. Not sure if this is true for the other languages though.
A member (variable) is just some part of the object. A property is (I'll qualify this with "usually" - I'm not sure that it's a technically clear word that has unambiguous meaning across multiple languages) is a publicly accessible aspect of the object, e.g. through getter and setter methods.
So while (almost always) a property is a reacheable member variable, you can have a property that's not really part of the object state (not that this is good design):
public class Foo {
public String getJunk()
{ return "Junk";}
public void setJunk(String ignore){;}
}
}
Both properties and methods are members of an object. A property describes some aspect of the object while a method accesses or uses the owning object.
An example in pseudo-code:
Object Ball
Property color(some Value)
Method bounce(subroutine describing the movement of the Ball)
Where the ball is defined and given a color(property) while the method bounce is a subroutine that describes the how the ball will react on hitting another object.
Not all languages have properties, i.e. Java only has fields that must be accessed by getters and setters.
Properties are a way to expose fields, where fields are the actual variables. For example (C#):
class Foo {
private int field;
public int Property {
get { return field; }
set { field = value; }
}
}
from PHP manual:
Class member variables are called "properties". You may also see them referred to using other terms such as "attributes" or "fields". They are defined by using one of the keywords public, protected, or private, followed by a normal variable declaration. This declaration may include an initialization.
Member is a generic term (likely originated in C++, but also defined in Java) used to denote a component of a class. Property is a broad concept used to denote a particular characteristic of a class which, once the class is instantiated, will help define the object's state.
The following passages, extracted from "Object-Oriented Analysis and Design" by Grady Booch help clarify the subject. Firstly, it's important to understand the concepts of state and behaviour:
The state of an object encompasses all of the (usually static) properties of the object plus the current (usually dynamic) values of each of these properties. By properties, we mean the totality of the object's attributes and relationships with other objects.
Behaviour is how an object acts and reacts, in terms of its state changes and message passing (methods); the outwardly visible and testable activity of an object.
So, the behaviour of an object depends on the available operations and its state (properties and their current values). Note that OOP is quite generic regarding certain nomenclature, as it varies wildly from language to language:
The terms field (Object Pascal), instance variable (Smalltalk), member object (C++), and slot (CLOS) are interchangeable, meaning a repository for part of the state of an object. Collectively, they constitute the object's structure.
An operation upon an object, defined as part of the declaration of a class. The terms message (Smalltalk), method (many OO languages), member function (C++), and operation are usually interchangeable.
But the notation introduced by the author is precise:
An attribute denotes a part of an aggregate object, and so is used during analysis as well as design to express a singular property of the class. Using the language-independent syntax, an attribute may have a name, a class, or both, and optionally a default expression: A:C=E.
An operation denotes some service provided by the class. Operations (...) are distinguished from attributes by appending parentheses or by providing the operation's complete signature, composed of return class, name, and formal arguments (if any): R N(Arguments)
In summary, you can think of members as everything that composes the class, and properties as the members (attributes) that collectively define the structure of the class, plus its relationships to other classes. When the class is instantiated, values are assigned to its properties in order to define the object's state.
Cheers