Design pattern - part 1
0 likes228 views
This document discusses software design patterns and relationships between classes. It defines what a design pattern is - a common solution to a recurring problem in software design. It categorizes design patterns into creational, structural, and behavioral patterns. It also discusses object-oriented programming principles like inheritance, polymorphism, and encapsulation. Additionally, it explains different types of relationships between classes like inheritance, association, aggregation, and composition. It notes that the Unified Modeling Language (UML) is used to visualize and document design patterns and class relationships.
Design pattern - part 1
- 2. Software Architecture Pattern : A common solution and the best practice to solve a reoccurring problem
- 3. Software developers encountered many recurring problems during software development, after enhanced and developed those solutions, they documented the steps and sequence to solve those problems in future, this solution called software design pattern.
- 4. Design pattern is a how we can design relation among classes and objects to solve a general and repeatable problem in specific context .. Design pattern :skip the complex hard work and jump into straight design and plan your work to improve the quality of the software and reduce development time and cost .
- 5. Before start your design pattern you have to know that OOP Basics : Inheritance Polymorphism Encapsulation Abstraction OOP Principles : Favor composition better than inheritance Code in interface not an implementation
- 6. We can classify Design patterns into Structural (the composition of classes or objects): – Adapter, Bridge, Composite, Decorator, Façade, Proxy Behavioral (object interactions): – Interpreter, Iterator, Mediator, Creational (object creation): – Abstract Factory, Builder, Factory Method, Prototype, Singleton
- 7. UNIFIED MODELING LANGUAGE (UML) • Is an application modeling specification • Is a language for specifying , Virtualizing and documenting the artifacts of system. • The primary objective of UML is to simplify the complex software engineering process • UML visualize and create artifacts of systems • Its common language and standard tool to illustrate the design patterns
- 8. UML and Design pattern
- 9. Mark Visibility type + Public # Protected - Private ~ Package Access Modifiers - Visibility
- 12. Use Italic text for the Abstract class and methods Inheritance Generalization UML Conventions
- 14. Methods Throwing Exceptions UML Conventions
- 15. Important definitions •Subclass /child class / derived class: •Super class/ parent class / Base class:
- 16. Relationships between Classes - Inheritance (Generalization) IS A - Association Has A - Aggregation – sharing - Composition – Non sharing
- 17. • Is-A relationship • In Is-A relationship one class is obtaining the features of another class by using inheritance concept with extends keywords. • Man IS A Human (Man is extends for Human) All public and protected Methods and attributes in Human will be in Man • If you change method in Human will effect directly in Man Relationships between Classes
- 18. • Has-A relationship • In Has-A relationship an object of one class is created as data member in another class the relationship between these two classes is Has-A. • Man HAS A Relationships with others. • There is an associations between the Man and the the other could be strong or weak relationship .Maybe peer to peer relationship or Ownership relationship . Relationships between Classes
- 21. Dependency Is a relation between two classes, where one class depends on another class So any change in classes may affect the functionality of the other dependent class. For example Car and Gas Station, we have Car need to fill oil to start Engine , in this case, Car class is dependent on the GasStation class. In the future, if any change are made to the GasStation class, it may result in changes to the Car class. Relationships between Classes
- 22. Association • Association is a structural relationship between two classes where all objects have their own lifecycle and there is no ownership. • Let’s take an example of Car and Passenger relationship Multiple Passengers can associate with a single Car and a single Passenger can associate with multiple Cars , but there is no ownership between the objects and both have their own lifecycle. Both can create and delete independently. • Each Class contains reference to another Class , maybe one-to-one relationship or one-to-many, many to many .. Relationships between Classes
- 23. Aggregation • Aggregation is a specialized form of Association where all objects have their own lifecycle, but there is ownership and a child object cannot belong to another parent object. • Let’s take an example of a Car and Driver Relationship . A single Car cannot belong to multiple Drivers , but if Driver die , Car will not die , object will not be destroyed. • We can sell car to another Driver to use it • We can think of it as a “has-a” relationship or "whole/part" relationship. • Driver can own many cars (Collection of cars). Relationships between Classes
- 24. Composition • Composition is a specialized form of Aggregation • we can call this as a “death” relationship. It is a strong type of Aggregation. Child object does not have their own lifecycle and if parent object deletes all child object will also be deleted. • Let’s take again an example of relationship between Car and Engine. Car HAS A Engine but there is no independent life of a Engine and any Engine cannot belong to two different Cars. If we delete the Car , the Engine will automatically be deleted Relationships between Classes