Object-Oriented Analysis And Design — Structural Models (Part 3)
Modeling the organization of the system.
This is a series of articles on Object-Oriented Analysis And Design. The full series of articles can be found here.
Structural models of software display the organization of a system in terms of the components that make up that system and their relationships.
We’re going to focus on class diagram for modeling the structure of the classes in a software system.
Class Diagram
We will use the information we have from the conceptual model about our objects to create the class diagram.
Naming Convention
You start by using a way for naming your classes. Usually, the class name is in the singular, and uppercase first later, like “BankAccount”.
For the attributes, and methods, they are in camel case; lower case first letter, and all other words begins with upper case letter, like “getProductDetails”.
Some people prefer to use uppercase first letter for private attributes and methods, but it doesn’t matter, unless you’re using one way for naming, and your code is clear, easy to read and maintain.
Attributes
We then write the attributes, their data types and their default value if exist.
Methods
Write the methods, their parameter if exist inside a parentheses, and their return type.
Public, Private and Protected
They are called the access modifiers. They are used to control the access to object’s members.
Now, a good case practice is to keep all you members (attributes and methods) private unless it needs to be exposed.
So, we use signs to denote the access modifier of each member in the class.
- Public (‘+’): It says that it can be seen and triggered at any part of the application
- Private (‘-’): It says that it can be only triggered inside it’s class only
- Protected (‘#’): It says that it can be only triggered inside it’s class and also inside the child classes.
Some developers tend to keep their attributes private even if they know some other class need to trigger them. They allow getting and setting the value of these attributes through what’s called Getters and Setters. These are methods to get and set the attributes without allowing any external code to have a direct effect on them.
Constructor and Destructor
Whenever you create an object, you need to construct that object, meaning you assign all the instance variables to their correct values. This makes sure the object will be in a valid state once it’s created.
The constructor is method has the same name of the class. It’s called as soon as you created an object. You can have multiple constructors.
Having two or more methods with the same name, but with different parameters, either in the number of the parameters, their sequence, or their data type, is called “method overloading”.
The same idea as having a method that will be called as soon as the object is created, there is another one whenever the object goes out of the scope.
In Java, there is no destructor since it’s garbage collected language, hence you can’t know when the object will be destroyed by the garbage collected. While in C++, this concept applies, and we do have a destructor.
Instance Members Vs Static Members
Maybe we need to have a member that will be the same for across all instantiated objects.
If that’s the case, we can create a static member that’s shared across all the class. So, there will be one and only one copy of this member.
Static members are shown with underline to differentiate between them and the instance members.
You access a static member through the class name, not the object instantiated, and also you can access it even if there is no objects have been instantiated yet.
Now, one important thing to know, you can’t trigger an instance methods or attributes inside a static method.
This should make sense for you, because, static methods aren’t tied to any object, so, these instance methods or attributes don’t belong to any object when we are trying to trigger them from inside a static method.
public class Product {
private double price;
private static double taxRate = 0.1; // 10% tax rate on price
public static double getTaxRate() {
// this.price = 5123.0; // WRONG!
return taxRate;
}
public double calculatePrice() {
return this.price + (this.price * Product.taxRate);
}
}Types of Relationships
Inheritance
When we say, “a student IS-A person”, “an employee IS-A person” “a car IS-A vehicle”, “a bus IS-A vehicle”, etc. This indicates that student and employee share some common attributes and behaviors, the same for car and bus.
Inheritance provides a generic super class, an abstract class, that has the common attributes and methods between all sub classes.
This way, we avoid duplicates, as we don’t have to write the common attributes or methods. You only write them once in the super class, and they automatically will have all the attributes and methods from their super class.
We may add some methods, or attributes that are specific to the sub class.
Something to watch out for, if you want to re-write the inherited methods in the sub class, we’re doing what’s called overriding.
Overriding is replacing or adding additional behavior to the inherited one.
This is a not good case practice here, unless you have an abstract method in the super class. The abstract methods will be explained later.
Another thing is, try to avoid the situation where you have many level of inheritance — Depth of Inheritance (DIT). Don’t look for inheritance, inheritance announces for it self.
Association, Aggregation and Composition
We have been identifying relationships between objects by drawing a line between any two objects in our conceptual model.
This may indicates an association relationship. It means that an object has to know about, or, interact with another object(s). It might be for example, a customer object needs to call a method of shopping cart.
In other words, take a look at the following code snippet.
It shows that customer object uses a shopping cart object to get the number of items in the customer’s cart, and the shopping cart object needs to use an item object to add items to the cart.
public class Customer {
private ShoppingCart myCart;
// ...
public int items(){
return myCart.getItemCount();
}
}public class ShoppingCart {
private ArrayList items;
// ...
public void addItem(Item t) {
items.add(t);
}
public int getItemCount() {
return items.size();
}
}
Aggregation relationship is also association. But, it describes that an object can be made of, or built from some other objects.
For example, “a car HAS-A engine”, “a classroom HAS-A student(s)”, etc. It refers to the “HAS-A” relationship rather than the “IS-A” relationship as in inheritance. So, we can’t say “a car IS-A seat”.
Composition is the same as aggregation, but it implies the concept of ownership. Thus, it’s a more specific form of aggregation.
For example, if we have a document class and page class, and, the document object is composed of, made of page object(s).
If at anytime the document object hasn’t been instantiated yet; it doesn’t exist, the page object shouldn’t also be exist.
Similarly, If we destroyed the document object, then the associated page object(s) should be destroyed too. It can’t exist logically unless the document object exists.
Now, when to use aggregation vs composition?. Use aggregation when the objects can exist independently, and use composition if these objects can’t logically exist without that object that’s made of them.
Abstract Class
An abstract class is a class that can’t be instantiated; can’t create objects from it. It exists only for being inherited.
It exists to provide a generic class, that has some common attributes, and methods shared across all inherited classes, and you will never instantiate an object from that class. On the other side, a concrete class can be instantiated.
We mark a class to be abstract by using the keyword “abstract” in the class declaration.
abstract public class BankAccount {
// your code goes here
}In abstract class, methods and attributes don’t have to be static, so that they can be accessible by any object of a class that inherit from that abstract class.
Abstract Methods
An abstract method is a method that is declared without an implementation, and it must be inside an abstract class.
All sub classes must override the abstract methods. This is the case where overriding the inherited methods is not only allowed, but it’s mandatory.
abstract public class BankAccount {
abstract public void withdraw();
}In the abstract class, we can also have non-abstract methods that are shared across all the sub classes.
Interfaces
It’s an abstract class implicitly (you don’t write the keyword “abstract)”, but, it consists of a list of methods.
It exists also for being inherited, and overridden by the sub classes.
public interface Shape {
public void setColor(Color color);
public void draw();
}An important question that must be raised here, what should we use when we have an inheritance situation, a concrete class or an interface?. Well, It depends on what you want to do:
- If the common methods and attributes shared between all sub classes, you need a concrete class, so you write the code only once, and the sub classes will have it by default.
- If, and on the other hand, there are common methods between sub classes, but, each sub class has it’s own different implementation, we need an interface.
It’s true that many developer’s prefer using interface is to provide formal list of methods to support rather than inheriting from a concrete class and dealing with lots of pre-provided functionality that may or may not be correct.
Final Project
Here is a complete project that shows a real example combining all what we have practiced so far. It includes a simple code snippet using Java along with the class diagrams.
