[go: up one dir, main page]
Scribd
Upload
108 views4 pages

Association Using C# and Other OO Concepts

1) The document discusses different ways to associate employees and departments using objects in C#, including having a Department property in the Employee object or a collection of Employee objects in the Department object. 2) It provides code samples for retrieving all employees of a department using LINQ and getting an employee's department. 3) The document recommends having a Department property in the Employee class rather than a collection in the Department class, as it would be easier. 4) It also discusses extracting relationships like inheritance, aggregation, association, and composition from requirements based on real world relationships.

Uploaded by

nad791
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
108 views4 pages

Association Using C# and Other OO Concepts

1) The document discusses different ways to associate employees and departments using objects in C#, including having a Department property in the Employee object or a collection of Employee objects in the Department object. 2) It provides code samples for retrieving all employees of a department using LINQ and getting an employee's department. 3) The document recommends having a Department property in the Employee class rather than a collection in the Department class, as it would be easier. 4) It also discusses extracting relationships like inheritance, aggregation, association, and composition from requirements based on real world relationships.

Uploaded by

nad791
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 4

Association using C#:

We have two possible ways to create association lets you have two tables and want it to make
association using OOP concepts:

Associate Employees and Departments using objects. One easy concept in term of coding is:

One is to have a Department property in the Employee object and the different is to have a collection of Employee objects in
the Department object. You will also, at the minimal have both a series of all Department or all Employee objects.

The way you have it, if you have a series of all Department objects, which incorporate a series Employee objects, you can get all
Employee objects using LINQ.

What is LINQ: LINQ (Language Integrated Query) is uniform query syntax in C# and VB.NET to retrieve data from different
sources and formats. It is integrated in C# or VB, thereby eliminating the mismatch between programming languages and
databases, as well as providing a single querying interface for different types of data sources.

Code sample
var allEmployees = Departments.SelectMany(d => d.EmployeeList);

if you want to get the department of an employee

Code sample
var employeeDepartment = Departments.FirstOrDefault(d => d.Employees.FirstOrDefault(e => e == employee) != null));

However, I think you will find it easier to have a Department property in the Employee class than to have a collection in the
Department class.

Note: Using id's for associations is more of a relational data concept, and you are in the object world with C#.

Extracting real world relationships from a requirement


The whole point of OOP is that your code replicates real world objects, thus making your code readable and maintainable.
When we say real world, the real world has relationships. Let’s consider the simple requirement listed below:

1. Manager is an employee of XYZ limited corporation.


2. Manager uses a swipe card to enter XYZ premises.
3. Manager has workers who work under him.
4. Manager has the responsibility of ensuring that the project is successful.
5. Manager's salary will be judged based on project success.

If you flesh out the above five-point requirement, we can easily visualize four relationships: -
 Inheritance
 Aggregation
 Association
 Composition

Requirement 1: The IS A relationship

If you look at the first requirement (Manager is an worker of XYZ constrained corporation), it’s a Parent child relationship or
inheritance relationship. The sentence above specifies that Manager is a kind of employee, in other phrases we will have two
classes: parent class Employee, and a child class Manager which will inherit from the Employee class.

Note: The scope of this article is only restrained to aggregation, association, and composition.
Requirement 2: The Using relationship: Association

Is an interesting requirement (Manager uses a swipe card to enter XYZ premises)? In this requirement, the manager object and
the swipe card object use each other but they have their own object life time. In other words, they can exist without each
other. The most important point in this relationship is that there is no single owner.

The above design indicates how the SwipeCard classification uses the Manager class and the Manager type makes use of the
SwipeCard class. You can additionally see how we can create objects of the Manager class and SwipeCard type independently
and they can have their very own object lifestyles time and this relationship called the Association relationship

Requirement 3: The Using relationship with Parent: Aggregation


The third requirement from our list (Manager has workers who work under him) denotes the same type of relationship like
association but with a difference that one of them is an owner. So as per the requirement, the Manager object will own Worker
objects.

The child Worker objects can not belong to any other object. For instance, a Worker object cannot belong to a SwipeCard
object.
But… the Worker object can have its own life time which is completely disconnected from the Manager object. Looking from a
different perspective, it means that if the Manager object is deleted, the Worker object does not die.
This relationship is termed as an “Aggregation” relationship.
Requirements 4 and 5: The Death relationship: Composition

The last two requirements are actually logically one. If you read closely, the requirements are as follows:

1. Manager has the responsibility of ensuring that the project is successful.


2. Manager's salary will be judged based on project success.

Below is the conclusion from analyzing the above requirements:

3. Manager and the project objects are dependent on each other.


4. The lifetimes of both the objects are the same. In other words, the project will not be successful if the manager is not
good, and the manager will not get good increments if the project has issues.

Below is how the class formation will look like. You can also see that when I go to create the project object, it needs the
manager object.

This relationship is termed as the composition relationship. In this relationship, each objects are closely established on each
other. In different words, if one goes for garbage collection the different also has to be rubbish collected, or inserting from a
distinctive perspective, the lifetime of the objects are the same. That’s why I have put in the heading “Death” relationship.

This relationship is termed as the composition relationship. In this relationship, each objects are closely established on each
other. In different words, if one goes for garbage collection the different also has to be rubbish collected, or inserting from a
distinctive perspective, the lifetime of the objects are the same. That’s why I have put in the heading “Death” relationship.

Putting concepts together

Below is a visible representation of how the relationships have emerged from the requirements.

You might also like