Scribd
Upload
2 views

Assignment4 - OOP Project

The document discusses the principle of Separation of Concerns in Object-Oriented Programming (OOP), emphasizing the importance of isolating different responsibilities within an application to facilitate development and testing. It outlines the process of identifying classes and their attributes, as well as defining relationships between classes, including inheritance, association, aggregation, and composition. Understanding these concepts is crucial for effectively modeling real-world objects and their interactions in software design.

Uploaded by

diederick.weger.de
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
2 views

Assignment4 - OOP Project

The document discusses the principle of Separation of Concerns in Object-Oriented Programming (OOP), emphasizing the importance of isolating different responsibilities within an application to facilitate development and testing. It outlines the process of identifying classes and their attributes, as well as defining relationships between classes, including inheritance, association, aggregation, and composition. Understanding these concepts is crucial for effectively modeling real-world objects and their interactions in software design.

Uploaded by

diederick.weger.de
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 1

23

The section below can help you better understand what is important and how to start
designing your application.

Separation of Concerns
One of the core concepts underlying OOP applications is the idea of Separation of Concerns.
According to this principle, the different responsibilities of a program/application should be
isolated from each other. For example, the core logic of an application should be separated
from elements such as the user interface or data storage functionalities. This separation enables
different parts of the code (individual classes or methods) to be developed and tested individu- Separation of Concerns (SoC) is
ally. Moreover, the different elements are independent from each other (e.g., application logic one of the most important princi-
ples in Software Engineering. Ac-
or user interface), modifications in either of them can only introduce localized bugs.
cording to this principle, an appli-
In the context of OOP, the separation of concerns plays a fundamental role in defining the cation can have multiple responsi-
classes of an application and how the real world is modeled. If it is still unclear to you how bilities - reading and writing from
to create classes using the principle of Separation of Concerns, please revisit Part 10-4 of the files, interacting with the user, etc.
- and each of those should be iso-
course material. (You can also read the extra material in the margin note)
lated from each other. That is, han-
dled by a different component (Ex,
Setup 1: Class).

□ Identify the Classes and Objects in your application


What are the ’real-world’ objects involved in your application that could be modeled
with a class? Are there abstract concepts in your application that should also be a
class?

□ List the methods and attributes needed in each class


Which attributes are private, protected or public? Which data type does each
method receive and output?

Class relationships
After defining the classes in your application, it is also important to define what the relationships
are between those classes. For example, are there classes that inherit from other classes? This is
an example of an inheritance relationship. Usually, inheritance can be defined by a relationship
of is a. For example, when implementing the classes Animal and Cat, we can use Animal as a
Example of how to represent differ-
base class for Cat because "Cat is an Animal". ent UML class relationships:
In addition to inheritance, there are other types of relationships between classes. Some
important examples are: association, aggregation, and composition. In the case of association,
you can think of classes that are connected between each other. For example, the class Teacher
can have an association with the class Blackboard. In that case, a Teacher uses the Blackboard,
so this can be viewed as a directional association.
In composition relationships, the association between the two classes is usually much
stronger, with a whole-part relationship between them. For example, a Dog (whole) ’contains’
a Tail (part). Moreover, if the Dog object is deleted, it would not make sense to keep its Tail.
In some specific cases, two classes can have a whole-part relationship, but still exist in-
Figure by Yanpas - Own work,
dependently of each other. For example, a Bookshelf in a library contains many Books, but CC BY-SA 4.0, (link here)
removing a Bookshelf does not imply that its Books do not exist in the library anymore. This
kind of relationship is referred to as aggregation.
Notice that the kind of relationship between two classes depends on the way the application
is implemented. For instance, a programmer could be in a situation in which it makes sense to
have Books and Bookshelf in a composition relationship (instead of aggregation).

You might also like