I am designing a class diagram for an assignment. In this design, I use a separate class called Currency, to define currency values and their functionality. there are at least four other classes have to use this Currency class.
How can I show it in the class diagram ? I mean, do I need to draw relationships (connecting lines) from the Currency class to all the others ?
Is there a better way ?
What am I doing wrong here ?
There is nothing wrong and a reusability of a class is valuable. Actually that's a standard situation.
If you use this class in another class as an attribute you have two options to depict that:
draw an association relationship (line) from the class using to the class that is used.
put the attribute in a proper compartment of a class that is using and as a type of an attribute (after a colon) put the name of the used class.
The benefit of the first approach is that you immediately see the dependency between the classes.
If you use a class but not directly as an attribute type you use other relationship types that suit best to the situation you want to describe.
As I imagine one of your concerns is that you'll have a lot of relationships pointing to your class (in your case Currency). Don't worry about that. You don't have to put everything in a single diagram. Put a full specification of your class on one diagram with those relationships where it uses something else and then put only the class box with a name (without any compartment) on diagrams defining those elements that use your class. It will make your model readable. And with a support of some CASE tool you will be able to see all relationship and dependencies of this class anyway. By the way that's how the UML specification is written. Look for example how Namespace is used in the diagrams there (and many others as well).
Of course I'm not suggesting creating one diagram per one element to define it. No. Collect them in logical Packages (hey - that's exactly what Packages are for!) and make a class diagram per Package. If the Package becomes too large - you might need to split it into smaller subpackages.
For Currency your Package would be probably something like Utils. It can also contain other elements like Date, Address etc. Note - these are typical examples, probably every analyst/designer/programmer sooner or later has to cope with those elements. If you build them well, you'll be really able to reuse them in future applications as well.
One last thought. While you build "package based" Class diagram you might also need a diagram that shows just specific parts coming from several Packages to clarify some bit of your system/business/whatsoever. This is also absolutely fine. Again a benefit of CASE tool here is that it keeps consistency in your model.
I am trying to represent the following situation in a UML Class Diagram.
We have a class named Selection where the user select how will the
next screen be.
The selection class has a property screen: Screen, where screen is an interface.
There are multiple implementations of the interface screen. ex. SimpleScreen, SuperScreen, etc.
The screen property in selection class should be able to contain an instance of any implementation of screen depending on user choice.
My questions are:
Is it possible to do this in OO?
How would the Class Diagram representation look like for this case?
Right now I have a diagram like this: http://yuml.me/1dcb2f2f
If you want to modify the diagram I used yuml.me this is the link http://yuml.me/edit/1dcb2f2f
Thank you for your help
Yes it is possible to do it in OO. The correct UML notation is:
http://app.genmymodel.com/engine/xaelis/nextScreen.jpg
In order to act upon an abstract 'screen' polymorphically the implementations would have to adhere to a common interface or inherit from a common base class.
I'm not sure of the proper way to UML this, I think you've got the diagram about right.
Get acquainted with design patterns.
Use factory method (produce instance based on the user choice) +
singleton (makes factory easily accessible and ensures that only one factory exists) for producing instance of needed class +
object composition with bridge pattern(allows to decouple interface from implementation and allows to switch implementation in a run-time/)
Before I jump into the meat of the question, let me note that this is a purely theoretical query. I'm not interested in this for practical reasons, I'm interested in the underlying OOP theory on how to handle this type of situation.
In a project I'm working on, I have two closely related classes. One is the generic 'user' class. The other is subclassed, and adds additional features used by certain users -- for a generic example, think a 'moderator' class.
How do I handle public methods that are available on the user class that don't make sense for the child to have called?
For example, it makes perfect sense to call User::getUserWithId(id) (this method retrieves data from the DB and initializes and returns the user class with that data); it doesn't make as much sense (if any) to use that method with the moderator class.
Should I just ignore it -- if a user calls moderator::getUserWithId(id), they're still getting a user, exactly what they asked for. Should I override it to return a moderator, despite the method name? Or is there something in OOP land I'm not familiar with that lets me 'block' the call?
If you have methods in your base class that don't make sense in your subclass, then I think you need to re-evaluate if you should model these classes via an inheritance relationship. Needing to hide members of a base class in a subclass is a red flag that indicates modeling this via an inheritance relationship is problematic.
An inheritance relationship should indicate an "is a" relationship. For your example, a moderator object "is a" user object and thus should have the same methods and properties as the user object. If it does not, then it would appear that it does not have a true inheritance relationship with its base user class.
In this case, you might want to consider using interfaces instead of inheritance. You can factor the common functionality between the User and Moderator classes into an interface. If there is common code that they can share, then you can use composition to achieve this, by creating a common implementation of the interface and then passing it to the classes that need to reuse this code. For further information, see here and here.
As the author in the second link above puts it:
Does TypeB want to expose the complete interface (all public methods no less) of TypeA such that TypeB can be used where TypeA is expected? Indicates Inheritance.
Does TypeB only want only some/part of the behavior exposed by TypeA? Indicates need for Composition.
From your need to hide a member of the base class, it seems that you are in the second category, and might want to explore using composition and an interface.
Yesterday I left a response, that somehow got lost. I think, #Joe Alfano has a very good explanation that addresses your "theoretical" and also particular questions.
Beside that, In my opinion, one source of your problem might be that you are doing database access in your Domain Object. In general, unless there is a compelling reason, this is not a good practice. If you remove that database access into a separate layer like Data Access Layer (DAL) this problem goes away. You won't have User::getUserWithId(id) things in your classes, they will be handled in DAL. Like
class UserDao {
User getById(id)
}
Class ModeratorDao {
Moderator getById(id)
}
If you go with DAL-like approach, then you will also find ways to re-factoring code, which is a separate thing.
Suppose I have such requirement:
The objects in the system all derive from a base class named IObject, and it may have objects with color, objects with transformations, and both.
Now there are 2 approach to design the class hierarchy.
The first one is:
just let concrete class derived from
IObject, and also select "capability"
interfaces as its base class to
indicate it support such behavior,
like interface: IHasColor,
IHasTransformation
The second one is:
Organize the base classes, and let
concrete classes derived from one of
them: IObject, IColorObject,
ITransfromationObject ,
IColorAndTransformationObject
I prefer the first one (Does it have a formal name? ) as it is more flexible, and as you can see the second one may have class combination explosion problem when there are many attributes like color, transformation...
I would like to know your ideas and suggestions.
Thanks.
Classes abstract the real concept of types of objects.
Interfaces abstract the real concept of behaviors or abilities for an object.
So the questions becomes, is the "color" a property of the object or is it a capability of the object?
When you design a hierarchy you are constraining the world into a narrower space. If you take the color as a property of the object then you will have two kind of objects, the ones that have colors and the ones that do not. Does that fit your "world"?
If you model it as a capability (Interface) then you'll have objects that are able to provide, lets say cast, colors to the world.
For the transformation the same logic applies. You can either split the world into two kind of objects, the ones who can transform and the ones who can not, or you can view it as a capability, an object may have the ability to transform itself into another thing.
For me, from that point of view, what would make sense would be:
Color is a property of the object. In fact every object should have a color, even if its transparent, even if is reflection, even if its "none" (good luck figuring out what an object with color = none means in the real world, still it might make sense in your program logic).
Transformation is a capability, that is, an interface, something the object is capable of doing, among other things the object may or may not be able of doing.
I'm working on classes hierarchy in my project and basically I have similar situation like you described in your question.
Let's say I have base type Object which is absolute root of all other classes in my toolkit. So naturally everything derives from it directly or through it's subclasses. There is a common functionality that every Object-derived class has to provide but in some leaf classes effects are little different than in others. For example every object have size and position which can be changed with properties or methods like Position = new Point(10, 10), Width = 15, etc. But there are classes that should ignore setting of a property or modify it according to self inner state. Think about control docked to left side of parent window. You can set Height property all you like but it will be generally ignored because this property really depend on Height of parent container control (or it's ClientArea height or sth like that).
So having Object abstract class implementing basic common functionality is ok until you reach a point of where you need "customize" behavior. If Object provides protected virtual SetHeight method that is called in setter of Height property you can override it in you DockedControl class and allow change of height only if docking is None, in other cases you limit it or ignore completely.
So we are happy but now we have requirement for object that react on mouse events like Click or Hover. So we derive MouseAwareObject from abstract Object class and implement events and stuff.
And now client want dockable, mouse aware objects. So we derive from DockableObject and... hmm, what now? If we can do multiple inheritance we can do it but we hit diamond problem with ambiguity of duplicated interface and we need to deal with it. We can have two memeber of Dockable and MouseAware types in new class and proxy external calls to them to provide functionality.
And last thing that comes to mind is to make IDockable and IMouseAware interfaces and let them define functionality and add them freely only to objects that need to deliver concrete behaviors/implementations.
I think I will split my base class into parts and leave my Object with very limited "core" set of properties and methods and rest of functionality that is in fact optional to Objects as a type but needed in concrete cases move to interfaces like IResizable, IDockable, IMakeAWorldABetterPlaceAble, etc. With this solution it is possible to "attach" behaviors to Object-derived classes without need for draggin virtual or pure virtual (abstract) methods from root base class all the way down to leaf class.
There is of course inconvenience of implementing interfaces in all affected classes but you can always implement some "adapters" and just forward calls to them. That way you don't have duplicated implementation (to some extend of course) and have decoupling between realization of task (Resize can mean different things for different classes) and expectation of client code.
Probably this is not ideal answer for your question but maybe it will hint you to your own solution.
I think you jump directly into interfaces, skipping classes. Is it required for you app. to have a "IObject" interface ? Maybe a "CObject" root class for your class hierarchy, may help you.
It think the winner is No. 1 solution, you may have a "MyObject", whether is an implementation of an interface, or direct class. Later you can add additional classes or interfaces in your class hierarchy, as you need.
After seeing several applications (some mine, some others), I think there should be a "My Custom Application Class Hierarchy Root Object" or "My Custom Application Class Hierarchy Root Interface" Design Pattern.
I've had trouble finding a clear, concise laymans definition of a class. Usually, they give general ideas without specifically spelling it out, and I'm wondering if I'm understanding this correctly. As I understand it, a class is the set of code that controls an object. For example, in an app that has a button for 'Yes' and a button for 'No', and a text box for output, the code that tells the computer what to do when the user uses the Yes button is one class, the code for hitting No is another class, and an object is the two buttons and what they do together to influence the output box. Am I right, or am I confusing terms here?
Thanks
A class is a kind of thing, an object is an actual thing. So, in the real world, "person" is a class, you and I are objects (or instances) of that class. "Car" is a class, my 1996 beater Volvo station wagon is an object.
Objects all have certain similarities in form and function because of the class they belong to. When I say my station wagon is a "car", you have a pretty good idea of what it looks like, what it's used for, and what it can do. But objects of a class can also differ from each other. Just because something's a car doesn't tell you exactly what shape it is or how many seats it has or what color it is.
In the example you gave, it's likely that the yes and no buttons are both objects of the class "button" (or some similar name) and that the differences in their behavior are due to changes added by the programmer without his or her bothering to create a new class. However, it is possible that the programmer made the decision to make each type of button a subclass of the original class "button".
What's a subclass? Well, if you think of "car" as a class, it is obvious that there are several intermediate "kinds" of things between "car" and "Larry's 1996 beater Volvo station wagon". These could be "station wagon" and "Volvo station wagon". So my car would be an instance of "Volvo station wagon" which itself would be subclass of "station wagon" which would be a subclass of "car". From the "car" part, we know a good deal about my object, from the "station wagon" part we learn a little more, and from the "Volvo station wagon" a little more still.
The way in which classes and subclasses are arranged is a decision made by the programmer. In my example above, another programmer might have made the classes "car", "Volvos", "pre-Ford", and "Wagons". It depends on the problem you're trying to solve.
This is going to be a very simplified explanation. A class is a set of functions and variables and is used to create objects. I think it's good to use real examples instead of dog / bark / talk etc.
Class Email
Subject (string)
Message (string)
ToAddress (string)
FromAddress (string)
Send (function)
When you call 'new Email()' it creates a new object with those variables and functions. Then you can populate the variables and send it.
In object-oriented programming, a class is a type for objects. An object is a bundle of data together with functionality that can operate in the context of that data; the definition of what the object is and does when it is first created is determined by its class.
Like a type for data, the class of an object specifies what is common to all instances of that class. Instances, which are the objects themselves, then get to override that common baseline (otherwise there's not much point having distinct instances). In many OO systems, instances may or may not have new members that are not part of the class definition.
What that means in the context of a specific object-oriented language is going to differ from language to language. But if you think of classes as types, and build on that, you won't go far wrong.
A class is basically a way to organize your code.
It allows you to put all of the code related to one abstraction (think "concept" or "idea") in one place.
As an example - in your example of an app, the Window with the two buttons, a text box, and some code for handling what happens when the user types in the information may be organized into a single class: something like "PromptWindow". This class would be made up of multiple classes internally (two buttons, a textbox, etc) This would probably be used by some separate class, which would create an instance of the PromptWindow class, call a method on the class to show the window, then use the results.
At the very basis, there's procedural code:
var a = 4
var b = 5;
print a + b;
… and so on, statements following statements…
To make such pieces of code reusable, you make a function out of them:
function a_plus_b() {
var a = 4
var b = 5;
print a + b;
}
Now you can use that piece of code as often as you want, but you only had to write it once.
Usually an application depends on a certain way of how pieces of code and variables have to work together. This data needs to be processed by that function, but cannot be processed by that other function.
function foo(data) {
…do something…
return data;
}
function bar(data) {
…do something else…
return data;
}
a = "some data";
b = 123456;
a = foo(a);
b = bar(b);
c = bar(a); // ERROR, WRONG DATA FOR FUNCTION
To help group these related parts together, there are classes.
class A {
var data = 'some data';
function foo() {
…do something…
return data;
}
}
The function foo now has a variable data that is "bundled" with it in the same class. It can operate on that variable without having to worry about that it may be the wrong kind of data. Also there's no way that data can accidentally end up in function bar, which is part of another class.
The only problem is, there's only one variable data here. The function is reusable, but it can only operate on one set of data. To solve this, you create objects (also called instances) from the class:
instance1 = new A();
instance2 = new A();
instance1 and instance2 both behave exactly like class A, they both know how to perform function foo (now called an instance method) and they both hold a variable data (now called an instance variable or attribute), but that variable data can hold different data for both instances.
That's the basics of classes and objects. How your particular "OK", "Cancel" dialog box is implemented is a different story. Both buttons could be linked to different methods of different classes, or just to different methods of the same class, or even to the same method of the same class. Classes are just a way to logically group code and data, how that's going to be used is up to you.
In a language agnostic fasion, I would describe a class as being an object that contains related information.
A person class would have methods like Talk(), Walk(), Eat(); and attributes like Height, Color, Language, etc.
A class is like a blueprint of things that you can instantiate, and also procedures that are related to each other.
If you have a Database class, you might have many methods related to databases that do all sorts of voodoo with a database.
A class is a bunch of code that defines an entity in your application. There may be many such entities, but the behaviour of each is the same, as defined by the class. The class will typically define fields, whose contents are local to the instances (or objects) of that class. It is these fields that provide the objects with state and make them distinguishable from one another.
To use your example, there might be a Button class that defines what a button is in your application. This class would then be instantiated twice to provide two objects: one for the "No" button and another for the "Yes" button. The Button class could have a Text field/property that defines what text it contains – this could be set to "No" and "Yes" on the appropriate Button instances to give them their different appearances.
As for the click behaviour of the buttons, this would typically be implemented via the observer pattern, in which the subject class (Button in this case) maintains a list of separate "observer" objects which it notifies whenever some event occurs (i.e. when the button is clicked).
You should look at some sample code, in your language of choice. Just reading about the concept of classes will not answer many questions.
For example, I could tell you that a class is a "blueprint" for an object. Using this class, you can instantiate multiple such objects, each one of them (potentially) having unique attributes.
But you didn't understand a thing, now, did you? Your example with the buttons is very limited. Classes have nothing to do with user interfaces or actions or whatever. They define a way of programming, just like functions/methods/whatever you want to call them do.
So, to give a concrete example, here's a class that defines a ball, written in Python:
class Ball:
color = ''
def __init__(self, color):
self.color = color
def bounce(self):
print "%s ball bounces" % self.color
blueBall = Ball("blue")
redBall = Ball("red")
blueBall.bounce()
redBall.bounce()
Running this produces the expected output:
blue ball bounces
red ball bounces
However, there is much more to classes than I described here. Once you understand what a class is, you go on to learn about constructors, destructors, inheritance and a lot of other good stuff. Break a leg :)
From the definition of Class at Wikipedia:
In object-oriented programming, a
class is a construct that is used as
a blueprint (or template) to create
objects of that class. This blueprint
describes the state and behavior that
the objects of the class all share. An
object of a given class is called an
instance of the class. The class that
contains (and was used to create) that
instance can be considered as the type
of that object, e.g. an object
instance of the "Fruit" class would be
of the type "Fruit".
A class usually represents a noun,
such as a person, place or (possibly
quite abstract) thing - it is a model
of a concept within a computer
program. Fundamentally, it
encapsulates the state and behavior of
the concept it represents. It
encapsulates state through data
placeholders called attributes (or
member variables or instance
variables); it encapsulates behavior
through reusable sections of code
called methods.
Your understanding of a Class isn't at all incorrect but to make things clear consider the following...
The Yes and No buttons plus the TextBox are usually specified within a class taking for example code written in C# (Microsoft .NET Framework). Let's name this class MyClass.
The actions the buttons cause are handled by what are called handlers (methods). You could write your code in such a way that when you click the Yes button something gets written in the TextBox.
To instantiate MyClass you'd do the following:
MyClass myClass = new MyClass();
myClass.ButtonYes += new EventHandler(YourMethodForYes);
myClass.ButtonNo += new EventHandler(YourMethodForNo);
myClass.TextBox.Text = "Yes button was clicked";
Hope you get the idea.
I wrote usually above because this cenario you described could be implemented in a number of ways. OOP gives you plenty of ways to accomplish the same task.
Besides the definition of Class I think that reading about Object Oriented Programming (OOP) can help you a lot to understand it even more. Take a look at Fundamental Concepts.