Understanding Object-Oriented Design in C#: Realizing Object Associations and Interactions

1. Session 04:C# OOP 2 OOP in C#: Object-Oriented Design. Realisation of Object Associations: 1-1, 1-n, n-m. UML Class Diagram. More about Object Interaction. Collections of Objects AK IT: Softwarekonstruktion

2. The Anatomy of a Class Classes are usually written by this pattern: classClassName { declaration of attributes constructors properties methods } AK IT: Softwarekonstruktion

3. The Class BankAccount- attributes and constructor namespace Banking { public class BankAccount { private double balance; private int accNo; private int interestRate; public BankAccount(int no, int ir) { balance = 0; accNo = no; intrestRate = ir; } AK IT: Softwarekonstruktion

4. Methods public bool Withdraw(double amount) public void Deposite(double amout) public void GiveInterest() AK IT: Softwarekonstruktion

5. Properties public intInterestRate { get{return interestRate;} set{if( value>=0) interestRate = value;} } AK IT: Softwarekonstruktion

6. Object Interaction • Objects may be connected in different ways: • Association (“know-of-relation”).One object uses another. • Aggregation (“part-of-relation”).One object is a part of another. • The distinction is not always clear . Means aggregation AK IT: Softwarekonstruktion

7. Cardinality or Multiplicity • Tells how many other objects an object may be associated with: • One customer may have one account, an account must belong to a customer. • One customer may have many accounts, an account must belong to one customer. • A customer may one or more accounts, an account may belong to one or more customers. Goes for aggregation as well. AK IT: Softwarekonstruktion

8. Object Interaction: 1 - 1 • The Banking example shows object interaction: • The classes are connected – in UML: AK IT: Softwarekonstruktion

9. In the Code public class Customer{ //… private BankAccount account; //… account= new BankAccount(no, ir, bal); The association is implemented by an object reference (attribute). Customer is responsible for creating BankAccount objects. AK IT: Softwarekonstruktion

10. In the Code public class Program{ //… Customer c = new Customer(1, "Peter Thomsen"); //… Console.WriteLine("Customer: "+ c.Name +" has DKK “ + c.Account.Balance + " in the bank"); Methods in the other class is called using the reference. AK IT: Softwarekonstruktion

11. Forest Exercise • Solution? AK IT: Softwarekonstruktion

12. Implementing 1 - n • One customer may have many accounts, an account must belong to one customer. • Possible solution: A collection of BankAccounts in Customer (accounts) AK IT: Softwarekonstruktion

13. In the Code public class Customer{ //… private List<BankAccount>accounts; //… public Customer(intcNo, string n){ //… accounts = new List<BankAccount>(); } public void AddAccount(BankAccount acc){ accounts.Add(acc); } //… View Source AK IT: Softwarekonstruktion

14. Pair Programming(an eXtremeProgrammingpractice) • A well known and widely used technique: • Two programmers – one workstation • Programmer one is at the keyboard and have focus on the details that are being typed. • Programmer two supervises programmer one’s work and has the broader perspective and keeps focus on structure and what’s going to happen next. • After a period (10 – 15 min.) programmer one and two swop roles. AK IT: Softwarekonstruktion

15. Exercise • Do the Forest exercise (1 – 3) on Session04.docx. • Use pair programming. AK IT: Softwarekonstruktion

16. Implementing n - m • A customer may have one or more accounts, an account may belong to one or more customers. • Possible solution: A collection of BankAccounts in Customer (accounts) and a collection of Customers (owners) in BankAccount. AK IT: Softwarekonstruktion

17. In the Code public classBankAccount{ //… private List<Customer> owners; //… public BankAccount(int no, double ir, double bal){ //… owners = new List<Customer>(); } public void AddOwner(Customer c) { owners.Add(c); } //… View Source AK IT: Softwarekonstruktion

18. Exercise • Do part 4 and 5 (Banking) of the exercises on Session04.docx • Use pair programming. AK IT: Softwarekonstruktion

19. Implementing Associations Design Choices • Several possibilities for the different cardinalities. • The choice mostly depends on business logic (use cases) AK IT: Softwarekonstruktion

20. 1 – 1: • One of the objects must have a reference to the other. • But which one? • Depends of business logic: • Is access typically from Customer • or • from BankAccount? In Banking1 AK IT: Softwarekonstruktion

21. 1 – n (1..*) • Again – it depends on business logic: • A collection of references on the 1-side? • A single reference on the n-side? In Banking2 AK IT: Softwarekonstruktion

22. n - m (*..*) • Here we have no choice: • There must be a collection in at least one of the classes: In Banking3 • But this is often a problematic solution: • Complicated to maintain. • Lots of coding is required for doing updates, inserts and deletes. AK IT: Softwarekonstruktion

23. n - m (*..*) • But this is often a problematic solution: • Complicated to maintain. • Lots of coding is required for doing updates, inserts and deletes. • Often it is a good design to introduce a connection object: • And replace the n – m association by two 1 – n associations. • The designs for 1 – n may then be applied. • If there are any information on the association, this is necessary: AK IT: Softwarekonstruktion

24. Example: Project Management • Lets look at an other example: • An employee may work on several projects. • A project may have several employees working on it. • We need to record the number of hours a given employee has spent on a given project: Let’s dive into the code AK IT: Softwarekonstruktion

25. Exercises • Do part 6 (EmpProjV1) on Session04.docx • Do part 7 (Banking3) on Exercises03.pdf. • Use pair programming. AK IT: Softwarekonstruktion