Object-Oriented Modelling - PDF

Lecture 1 - W1 Friday, March 8, 2024 12:55 AM Introduction to Object-Oriented Modelling The paradox of simple rules and complex outcomes Simple computational rules lead to complex software behavior(imagine a game of chess) This complexity is due to the interactions between simple steps, which be...

Lecture 1 - W1 Friday, March 8, 2024 12:55 AM Introduction to Object-Oriented Modelling The paradox of simple rules and complex outcomes Simple computational rules lead to complex software behavior(imagine a game of chess) This complexity is due to the interactions between simple steps, which become upredictable as the software scales You create software for a purpose (Requirements) The challenge of evolving software requirements: software dev is a dynamic process with evolving software requirements. An app might need new features to keep up with the demands of the market, therefore this evolution necessitates flexible, adaptable designs that can accommodate such changes without major overhauls. Design for Complexity and Change Design principles are essential to manage software complexity and changing requirements. Object-oriented design offers techniques like information hiding, interfaces, and polymorphism to promote loose coupling. Good software is not just about being correct! Designing so"ware involves making choices in the face of competing concerns like efficiency and maintainability. (Granny's Groovy Tunes). How to design good software? Software Engineering -> the application of engineering principles to software development in a systematic way. Goal: To produce reliable, efficient, maintainable, and usable software Software Engineering is not just about coding. It’s about: 1)Understanding user needs and translating them into software solutions: Requirements Engineering 2)Designing systems that are robust, scalable, and secure [Quality Attributes]. 3)Managing the software development process efficiently. Software Development Lifecycle -> process used to develop software The waterfall model is a sequential software dev process, having 6 phases: Requirements, Design, Implementation, Verification, Deployment, Maintenance Requirements Phase ---provide a clear, detailed foundation for the project Example->Gathering detailed needs and specifications for the grocery app Start---Identify Stakeholders---Gather Requirements---Analyze Requirements---Requirements Specification---Validate Requirements---End Two types: Functional and Non-Functional Requirements Functional Requirements: Define what the software must do — such as user authentication, payment processing, and shopping list management for the grocery app. Non-Functional Requirements: Specify how the software performs certain operations — including usability, performance, security, and compliance standards. Design Phase---outlines how the app will look and function. Example: Creating detailed designs for the app’s Object-Oriented Modelling Page 1 Example: Creating detailed designs for the app’s interface and system architecture. Requirements Specification---Design---UI/UX Design---System Architecture---Design Document Implementation Phase---turns design documents into a working application. Example Activity: Writing and compiling code based on the design documents. Design Document---Code Development---Compile & Build Verification Phase---confirms that the app is built correctly and is ready for deployment Verification: “Are we building the product right?” Validation: “Are we building the right product?” Testing: Testing is the act of executing a program with selected data to uncover bugs. Example : Systematic testing to ensure the app meets all requirements and design specifications. Built Product---Verification---Validation---Testing Deployment Phase ---the phase where the software becomes available to end-users and is critical for the operational success of the app. Example: Releasing the app on various platforms and monitoring initial performance. Verification---Prepare Release---Launch on Platforms---Monitor Performance Maintenance Phase---ensures the app remains functional and up-to-date over time. Example Activity: Providing ongoing support, bug fixes, and updates based on user feedback. Deployment---Provide Support---Implement Updates---Fix Bugs Introduction to Object-Oriented Analysis and Design (OOA/OOD) Object-Oriented Analysis (OOA): - This is the process of looking at a problem, system, or situation, and identifying the objects and interactions between those objects. Object-Oriented Design (OOD) is a conceptual solution that meets the requirements – how can we solve the problem. Unified Modeling Language (UML) UML is a graphical language used for specifying, visualizing, constructing, and documenting so"ware systems. It offers a standardized approach to so"ware design, bridging the gap between concept and implementation. Advantages of Using UML Benefits: Provides a universal language for so"ware engineers. Enhances understanding, reduces ambiguity, and aids in the documentation of systems. Facilitates communication among stakeholders, including developers, clients, and managers. A Design Patterns Design Patterns: Reusable solutions to common so"ware design problems. Object-Oriented Modelling Page 2 Design Patterns: Reusable solutions to common so"ware design problems. They provide proven techniques for solving problems in so"ware architecture and design. Characteristics of Design Patterns Defines a language for discussing and documenting design. Not specific to a particular problem, but applicable in various situations. Encourages best practices like modularity and separation of concerns. Code Smells What Are Code Smells? Code smells are patterns in so"ware that indicate potential flaws. They suggest weaknesses in design that may slow down development or increase the risk of bugs or failures in the future. Examples of Code Smells Long Method: A method containing too many lines of code, making it hard to understand. Large Class: A class that tries to do too much and holds too many responsibilities. Duplicate Code: Identical or very similar code exists in more than one location. Introduction to Code Refactoring Code refactoring is the process of restructuring existing computer code without changing its external behavior. It’s about improving the internal structure of the so"ware, making it easier to understand and modify. Goals of Refactoring Enhance code readability and maintainability. Reduce complexity and improve code performance. Principles of Code Refactoring Keep changes small and incremental. Ensure each refactoring step preserves the so"ware’s functionality. Test continuously to ensure no new bugs are introduced. Object-Oriented Modelling Page 3 Lecture 3 - W2 Friday, March 8, 2024 12:56 AM Object-Oriented Analysis and Design What is OOA and OOD? -Analyze the system, model it and design the software Analysis: what are we trying to do? Design: how are we going to do it? OOA: The process of looking at a problem, system or situation and analysing the objects and the interactions between them. OOD: Conceptual solution that meets the requirements - how can we solve the problem? We take the analysis results and mold them into a design that can be implemented in a specific programming language such as Java Why does it matter? In the real world, complex systems are often best understood through the interactions of simpler parts. OOA&D leverages this principle to create modular, reusable and flexible software. Benefits of OOA&D Modularity: the degree of which a system is composed of components such that a change in one of them has minimal impact on the other components Reusability: Objects and classes created for one project can be used in another, reducing development time and increasing productivity. Degree to which an asset can be used in more than one system, or in building other assets. (ISO 25010) EX: Payment processing for different services (e-commerce, in-app purchases) Flexibility: Systems designed with OOA&D can be easily adapted to meet changing requirements. OO Analysis in software development OOA is the investigative phase where you dive deep into the problem domain.Ask the right questions and identify the objects and interactions. Goal: Create a model of the real world that can be translated into a software system. EASIER TO CHANGE A DESIGN RATHER THAN A BUILT SYSTEM OO Design in software development Turn the conceptual model (from OOA) into a blueprint for building the system. What is Good Software? ISO 25010 1 defines software quality with a comprehensive set of attributes: - Functionality - Reliability - Usability - Efficiency - Maintainability - Portability - Compatibility - Security Functionality:The degree to which a product or system provides functions that meet stated and implied needs when used under specified conditions (Completeness, Correctness & Appropriateness) Reliability: the software’s capacity to maintain its performance level under stated conditions for a specified period. (Maturity, Fault Tolerance and Recoverability) Usability:how well a product or system can be used to achieve specified goals effectively, efficiently, and satisfactorily. Object-Oriented Modelling Page 4 Usability:how well a product or system can be used to achieve specified goals effectively, efficiently, and satisfactorily. (Understandability, Learnability and Operability) Efficiency:the relationship between the performance level of the software and the amount of resources used, under stated conditions. (Time Behavior, Resource Utilization and Capacity) Maintainability:the ease with which the software can be modified to correct faults, improve performance, adapt to a changed environment, or enhance the product. (Modularity, Reusability and Analyzability) HOW TO DESIGN GOOD OO SOFTWARE? 1) Understand the requirements 2) Analyze them in an OO context(OOA) 3) Design the software using OO Design Principles Gathering requirements Req-descriptions of the sys features and constraints - Essential for guiding development and testing. - Help in setting customer expectations. - Basis for project planning and design decisions. 3 types of software requirements: - functional - non-funcitonal - domain FUNCTIONAL REQ describe: The services the sys must prrovide, how it should react to certain inputs and how to behave in certain situations Characteristics: Clearly state what the sys should do; include techincal details, calculations, data manipulation etc. Examples: “The system shall allow users to enter their credentials to log in.” “Upon receiving a user’s input, the system shall calculate and display the results within 2 seconds.” NON-FUNCT REQ: Set criteria to judge the operation of a system, rather than specific behaviors, including constraints on the system and standards. -Performance: Speed, responsiveness, consumption. -Reliability: Frequency of failure, recoverability. -Usability: Understandability, learnability, operability. -Security: Access control, integrity, confidentiality Examples: “The system should load the homepage in under 3 seconds when accessed from a standard broadband connection.” “User data should be encrypted using industry-standard encryption algorithms." DOMAIN REQ: reflect domain-specific knowledge, standards, or regulations that the software must comply with. Key Aspects: Reflect application domain behavior. Influence system functionality and performance. Include legal and regulatory requirements. Example: “The software must store medical data in compliance with healthcare regulations.” “The system must perform currency conversion according to international financial standards.” Object-Oriented Modelling Page 5 Gathering Requirements: the process of collecting the needs and specifications from stakeholders to design a system that meets their expectations. Understand stakeholder needs, and translate those into technical specifications. - Stakeholders -> Individuals or groups with an interest in the success of the project (Clients, end-users, project managers, developers or your examiner) You can gather req by brainstorming sessions, surveys, interviews, workshops etc. USE CASES: detailed description of how users perform tasks, outlining a system’s behavior from a user’s perspective. Starts with a user’s goal and ends when that goal is fulfilled, providing a sequence of steps and interactions. Elements of a use case: Actor: The user performing the behavior. Stakeholder: Individuals with interests in the system. Preconditions: States that must be true before the use case runs. Triggers: Events that initiate the use case. Main Success Scenarios (Basic Flow): The expected successful path. Alternative Paths (Alternative Flows): Variations when deviations occur. Writing a use case: 1. Identify users: Determine who will be using the system. 2. Define actions: Each action becomes a use case. 3. Describe normal and alternate courses: Outline the basic and alternative flows. 4. Note commonalities: Identify similar patterns across use cases. 5. Repeat for all users: Ensure comprehensive coverage. EASY EXAMPLE FOR USE CASE - LAUNDRY Simple Laundry Use Case Actor: Housekeeper Basic Flow: Sorting, washing, drying, folding, ironing, and discarding items. Preconditions: It’s Wednesday, and there is laundry. Trigger: Dirty laundry is present. Post Conditions: All laundry is clean and either folded or hung up. Alternative Flows in Laundry Use Case Alternative Flow 1: If items are wrinkled, they are ironed and hung. Alternative Flow 2: If items are still dirty, they are rewashed. Alternative Flow 3: If items have shrunk, they are discarded. CHECK THE OTHER EXAMPLE ON CANVAS!!! (PLACE ORDER EXAMPLE) Use Cases: Key Takeaways User-Centric Design: Focus on user actions and system responses. Detailing Flows: Clear definition of basic, alternate, and exception flows. Supplemental Requirements: Address additional user experience enhancements. Adaptability: The use case’s structure allows for easy updates and modifications. From the example on Canvas: First, identify the description of the system that is required to be built. Then, identify the actors, preconditions and postconditions. After: Basic Flow, Alternate Flow(caused by Basic Flow), Exception Flow(happens rarely, like sys down or unavailable), Supplemental Requirements (an extra) CHECK STARBUCKS EXAMPLE ON CANVAS Requirements Prioritization: not all req are of equal importance, we need to evaluate the urgency, feasability, and value of each (prioritization). Techniques for this: MoSCoW (Must have, Should have, Could have, Won't have this time) MoSCoW Technique prioritization tool used to reach a common understanding on the importance of various requirements. Object-Oriented Modelling Page 6 MoSCoW Technique prioritization tool used to reach a common understanding on the importance of various requirements. Components: Must have (M): Essential features, required for successful and functional project. Should have (S): Important but not vital features. Could have (C): Desirable features that are beneficial but not crucial. Won’t have this time (W): Features that, may be useful, are not a priority for this iteration. Analysis OOA - What is it? Methodical approach to understanding a system by viewing it through the lens of the ‘objects’ (real-world entities) it involves. Key aspects -Understanding the Domain: Examining the problem or system from an object-centric perspective. - Capturing Requirements: Identifying what the system must do from the viewpoint of the objects. - Defining the System: Creating a model that effectively addresses and fulfills the identified needs. Identifying Objects and Classes - Objects: Instances from the problem domain represented in the system. - Classes: Blueprints defining attributes and behaviors of objects. Process: 1. Examine the Domain: Analyze the real-world scenario to model. 2. Spot Key Entities: Identify significant entities that play vital roles. 3. Define Nature and Functionality: Determine attributes and operations for each entity. Example: - Library System: Key objects like books, members, and loans with specific attributes and behaviors. Identify Relationships and Actions: Objects don't exist in isolation! Types of Relationships: Associations: Simple connections between objects. Aggregations: Whole-part relationships indicating a collective. Compositions: Strong whole-part relationships with dependency. Example: - E-commerce Platform: ‘Customer’ places an ‘Order’ containing ‘Products’. Associations: Represents a “use-a” or “has-a” relationship where one object uses or interacts with another. Can be one-to-one, one-to-many, many-to-one, or many-to-many. Aggregations: A specialized form of association representing a “whole-part” relationship, with objects having their own life cycle but forming a whole. Denotes a ‘has-a’ relationship. The part can exist independently of the whole. Compositions: A strong form of aggregation implying ownership. When the whole is destroyed, so are the parts. Represents a strong ‘contains-a’ relationship. The life cycle of the part is tied to the whole. Object Interaction Analysis Object Interaction Analysis is a technique used to understand how objects in the system will communicate and collaborate. Interaction diagrams are used to visualize these interactions. Assigning Responsibilities with CRC Cards Class-Responsibility-Collaborator (CRC) Cards: CRC cards is a simple tool used to define the behaviors and interactions of classes. Components of a CRC Card: Class Name: The entity or concept being modeled. Responsibilities: What the class should know or do (its behavior). Collaborators: Other classes this class interacts with or uses. Example: CRC Card Example - ShoppingCart Class Name: ShoppingCart Responsibilities: Add Item: Include a new product in the cart. Calculate Total: Compute the total cost of items in the cart. Object-Oriented Modelling Page 7  Calculate Total: Compute the total cost of items in the cart. Remove Item: Take out a product from the cart. Checkout: Initiate the purchasing process. Collaborators: Product: Items that can be added to the shopping cart. User: The customer who owns the shopping cart. Class Diagrams: The Static Blueprint Class diagrams show the classes, along with their attributes and operations, and the relationships between them. Object-Oriented Modelling Page 8 Lecture 4 - W2 Friday, March 8, 2024 3:36 PM Learning how to design OO software Object Interaction Analysis - a technique used to understand how objects in the system will communicate and collaborate. We use interaction diagrams to visualize these interactions. For example, in an airline reservation system, understanding how a "Passenger" object interacts with "Flights" and "Tickets" is crucial for designing a functional system. We assign these responsibilities with CRC Cards. Design - Good Design in Software - Beyond aesthetics, good software design is about crafting solutions that are effective, efficient ad maintainable - Simplicity, Consistency, Modularity, Usability, Maintainalbility, Robustness - core principles ----> SCMUMR Simplicity - focusing on essential elements, making software more understandable and less error-prone In practice: a Java method that performs a single, well-defined function is a good example. Easy to understand, test and maintain. Consistency - uniformity in visual elements, terminology, and behavior In practice: all variables, methods, and classes strictly adhere to CamelCase naming conventions Modularity - designing systems as separate, interchangeable components In practice: packages organizing classes by functionality, allowing independent development and testing. Usability - making software intuitive and accessible based on users' needs and limitations In practice: web app with a straightforward, well-organized layout, clear instructions, and responsive feedback. Makes software easy and pleasant to use, enhancing user satisfaction. Maintainability - allows for easy understanding, correction, adaption, and enhancement. In practice: writing clean, well-documented java code and adhering to architectural patterns Robustness - the sys ability to handle errors and unexpected situations gracefully In practice: implementing error handling and validation to manage unexpected inputs or disrupts. OO DESIGN PRINCIPLES Fundamental Design Principles DRY(Don't Repeat Yourself): Avoid duplication KISS(Keep it simple, stupid): Keep the design simple and straightforward YAGNI(You aren't gonna need it): Don't implement something until it is necessary DRY PRINCIPLE: Avoid duplication in code. Every piece of knowledge should have a single, unambiguous representation in the system. Impact: Reduces redundancy, making code easier to maintain and modify. KISS PRINCIPLE: Simplicity in design. Avoid unnecessary complexity and keep things straightforward. Impact: Enhances understandability and reduces the chance of errors. Simplified code is often more reliable and easier to debug. YAGNI PRINCIPLE: Implement only those features that are necessary. Avoid adding functionality until it is required. Impact: Prevents over-engineering and keeps the codebase lean and focused. Ensures resources are used effectively on what’s truly needed. Object-Oriented Modelling Page 9 More Design Principles Separation of Concerns: Different functionality managed by separate code. Principle of Least Astonishment: Software behaves how users will expect it to. Law of Demeter: Object should assume as little as possible about the structure or properties of anything else. SEPARATION OF CONCERNS Divide a program into distinct sections, each handling a specific aspect of the application’s functionality. Impact: Helps in isolating issues, streamlining updates, and collaborate more effectively. PRINCIPLE OF LEAST ASTONISHMENT Software should behave in a way that users predictably expect. The design should match common user expectations to prevent confusion and errors. Impact: Enhances user satisfaction and system intuitiveness. LAW OF DEMETER Minimal knowledge between objects. An object should only interact with its direct components and not concern itself with the internal details of other objects. Impact: Reduces the dependencies between components of a system, leading to a looser coupling and more modular architecture. GRASP PRINCIPLES What is GRASP? - General Responsibility Assignment Software Patterns (GRASP) are guidelines for assigning responsibilities in object-oriented design to improve robustness and maintainability. Principles Overview: Information Expert: Responsibilities go to the class with the most related information. Creator: The class that needs an object or has initializing data should create it. Controller: Designate a class to handle system events and user input. Low Coupling: Minimize class interdependencies for flexibility. High Cohesion: Keep related functions together for focused class design. Polymorphism: Handle alternatives based on object types dynamically. Pure Fabrication: Create classes for better design, even if they don’t represent real-world entities. ICCLHPP Information Expert Principle: Assign responsibility to the class that has the necessary information to fulfill it. Classes should be assigned responsibilities based on the data they hold or the information they can access. Benefits: Reduces redundancy and complexity. Enhances maintainability and cohesion. Makes the system more modular and easier to navigate. Application: Typically applied during the design phase to ensure that each class has a clear and focused role, handling operations that are directly related to its information. Object-Oriented Modelling Page 10 Creator - Overview Principle: Assign class B the responsibility to create an instance of class A if B closely uses A or holds the data that will initialize A. Ensure that objects are created by the classes that use them most or have the necessary data to initialize them. Benefits: Enhances encapsulation and clarity. Reduces dependencies and coupling between classes. Simplifies the system’s structure. Application: Useful in deciding where to put creation logic, especially in complex systems where the right placement of object creation can significantly affect the design’s clarity and maintainability. Controller - Overview Principle: Assign the responsibility of handling a system event to a class representing the overall system, a root object, or a subsystem. Think of it as having a dedicated barista (controller) who takes your order (input) and communicates it to the kitchen (system logic), instead of you shouting your order directly at the chefs. Benefits: Centralizes control logic. Decouples the UI from the underlying business logic. Simplifies maintenance and enhances scalability. Application: Typically used to define how the system will respond to user actions or other events, ensuring there’s a clear and consistent way to manage these interactions. LOW COUPLING Understanding Coupling: Coupling is the measure of how interdependent classes or modules are. Low coupling means that a change in one class has minimal impact on other classes. Low Coupling Principle: Design to minimize the dependencies between classes to reduce the impact of changes and improve reusability. Low Coupling involves reducing the interconnectedness of classes so that changes in one class have minimal impacts on others. Benefits: Increases the flexibility of the system. Makes the codebase more resilient to changes. Facilitates easier testing and maintenance. Application: Critical in designing systems where change is anticipated, ensuring that modifications in one part of the system don’t cause widespread issues. HIGH COHESION: Cohesion refers to the degree to which elements of a module or class belong together. A class with high cohesion performs a small range of tasks related to a particular purpose or concept. Principle: Keep related and similar functionalities together in a class, ensuring that each class has a clear, narrowly focused role. Classes should not take on responsibilities that could be better handled by others. Benefits: Simplifies understanding of the system. Enhances the ability to manage and modify code. Promotes single responsibility and focused class design. Application: - Essential in ensuring that the system remains organized and each part is as independent and focused as possible, promoting better design and easier future changes. Object-Oriented Modelling Page 11 possible, promoting better design and easier future changes. POLYMORPHISM: Use polymorphism to handle alternatives based on object type, where the behavior varies depending on the class of the object. Polymorphism in object-oriented programming allows objects of different classes to be treated as objects of a common superclass. It’s a way to use a single interface to represent different underlying forms (data types). Benefits: Enhances flexibility and reusability by allowing different classes to be used interchangeably. Simplifies code by eliminating the need for multiple conditional statements. Application: Commonly used when implementing system behaviors that can vary across different classes but are accessed through a common interface. SOLID PRINCIPLES What is SOLID? - SOLID represents five fundamental principles in object-oriented programming and design that promote software maintainability and extensibility. Key Objectives: Single Responsibility: Encourage classes to have one reason to change. Open/Closed: Design modules that are open for extension but closed for modification. Liskov Substitution: Ensure subclasses can replace their superclasses without altering the program’s correctness. Interface Segregation: Favor client-specific interfaces over general-purpose ones. Dependency Inversion: Depend on abstractions rather than concrete implementations. Single Responsibility Principle (SRP) Definition: A class should have one, and only one, reason to change, promoting modularity and separation of concerns. Importance: Simplifies understanding and modification of classes. Enhances cohesion and reduces the impact of changes. Open/Closed Principle (OCP) Definition: Software entities should be open for extension but closed for modification, promoting flexible and scalable systems. Use abstraction and polymorphism to extend behavior without altering existing code. How?: Designing a class hierarchy where new functionality can be added through subclasses or implementing interfaces without changing existing code. Liskov Substitution Principle (LSP) Definition: Subclasses should be substitutable for their base classes without affecting the program’s correctness. Ensures that a subclass can stand in for its parent class without causing unexpected behavior. Interface Segregation Principle (ISP) Definition: Clients should not be forced to depend on interfaces they do not use, encouraging fine-grained interfaces over general-purpose ones. Designing small, focused interfaces that classes can implement without being forced to include unnecessary methods. Dependency Inversion Principle (DIP) Definition: High-level modules should not depend on low-level modules; both should depend on abstractions. Abstractions should not depend on details; details should depend on abstractions. Using interfaces or abstract classes to define high- level policies, which are then implemented by concrete classes without the high-level modules knowing the details of the Object-Oriented Modelling Page 12 level policies, which are then implemented by concrete classes without the high-level modules knowing the details of the implementation. Object-Oriented Modelling Page 13 Lecture 5 - W3 Friday, March 15, 2024 8:44 PM Refactoring and code smells Mads, here is what you'll learn about: -Intro to refactoring -Example for refactoring -Intro to code smells -Bloaters -OO Abusers -Change Preventers -Dispensables -Couplers Intro to Refactoring The process of improving internal structure of the code without changing the external behavior. Why do this? : Enhance code clarity, mitigate technical debt(implied cost of additional rework caused by choosing an easy solution now instead of using a better approach that would take longer), ease future modifications and spot and resolve defects Challenges of refactoring: -Legacy code: Navigating complex, undocumented systems. -Time Management: Juggling refactoring and new features. -Bug Risk: Ensuring thorough testing. -Stakeholder Buy-In: Advocating the benefits of refactoring. When to refactor? Before Adding a New Feature: Tidy code before adding new features. When Fixing a Bug: Simplify surrounding code for clarity and easier bug resolution. During Code Review: Implement identified enhancements. As You Go: Continually refine code during development. Example Small, Behavior-Preserving Transformations: Minor yet cumulative modifications for major restructuring. Systematic Process: Ensures the external behavior remains consistent while improving internal architecture. Refactoring Step by Step 1. Identify a section to extract: Target a self-contained code chunk. 2. Create a new method: Move the code into a new method in the appropriate class. 3. Replace old code: Substitute the original code with the new method call. 4. Test: Ensure behavior remains consistent. Benefits of Extract Method: Improved Readability: The main method becomes concise. Reusability: Other system parts can now use the new method. Separation of Concerns: Enhances encapsulation. Continuing the magical process: Look for opportunities to: Object-Oriented Modelling Page 14 Look for opportunities to: Break down long methods. Move operations closer to data. Replace conditionals with polymorphism. POLYMORPHISM OVER CONDITIONALS FOR THE WINNNN!!!! Before: Switch statements based on movie type. After: Use polymorphism with subclasses like RegularMovie, NewReleaseMovie, and ChildrensMovie. Implementing Polymorphism 1. Define a common interface: All movie types should respond to getCharge. 2. Create subclasses: Each represents a different movie type. 3. Move the logic: Shift charge calculation to the respective subclass. Benefits of Polymorphism Flexibility: Adding a new movie type is straightforward. Adherence to Open/Closed Principle: System is open for extension but closed for modification. ENCAPSULATION ACHIEVED!!!!! Main principles of refactoring: -Don't change the observable behavior of the code, make small and incremental changes, test after each change and focus on simplicity and clarity. INTRO TO CODE SMELLS Code smells? Wtf?: Indicators of potential issues of the code that may require refactoring. It is important in recognizing the smells first as it's nr 1 step in improving your code quality. COMMON SMELLS: -Duplicated code -Long method -Large class !!!!!!!!!Smells are a guide, not a strict rule, so you can identify areas for improvement!!!!!!!!!! Types of code smells (stinky shit): Bloaters: Oversized constructs that complicate code management. Object-Orientation Abusers: Poor OOP design choices. Change Preventers: Structures that make changes difficult and widespread. Dispensables: Redundant elements that reduce clarity and efficiency. Couplers: Excessive class coupling or delegation issues. Bloaters: Oversized code(like your fucking clothes, you dyke), methods and classes, becoming difficult to manage. They grow gradually over time, making the program become complicated in terms of evolution. The cause for this is the lack of effort to refine or reduce code complexity. Long Method: Methods with too many fucking lines of code! It's hard to understand and maintain + you might have hidden bugs What can you do about this?: Bitch, just break down your fucking ugly ass long shitty method into smaller method shit with clear names and indicating their purpose. Replace Temp with Query -> replace temporary variables with queies to the method itself (basically give your method its desired clout, unlike those Spotify rappers). Introduce Parameter Object or Preserve Whole Object: Group parameters into objects (you're learning OOP so it makes fucking sense, bitch) Object-Oriented Modelling Page 15 Benefits of replacing temp with query? -> reduces the clutter of temporary variables and ensures that the calculation is always up to date (unlike your romantic life, get better standards) Benefits of Parameter or Whole Object? ->Simplifies method signatures and makes the code more readable, as you group your fucking related data toghether, better than those DSAI kiddos. Large Class(it thicc as fuck) Classes with too many responsibilities, being difficult to understand, maintain and modify, like your fucking mental health, get some help girly offers proven solutions for common problems, improving problem-solving skills - Design vocabulary -> creates a common language for developers, enhancing communication and collaboration - Best practices -> promotes best practices in software design for maintainable and scalable code Design patterns have limitations and appropriate use, understanding these is crucial. Misapplying them can lead to complex, inefficient solutions. Inexperienced use can lead to overcomplicated code when simpler options exist. Classifying Design Patterns: XXX By complexity and detail XXX: - idioms: specific to a programming language, addressing low-level issues and specifics - architectural patterns: high-level patterns that guide the overall structure and organization of software systems XXX By purpose XXX: - creational patterns: object creation mechanisms - structural patterns: deal with object composition and the formation of larger structures - behavioral patterns: communication between objects and responsibilities CREATIONAL DESIGN PATTERNS Fundamental for object creation in software design. They provide mechanisms that increase flexibility and reuse of existing code. We have Factory, Abstract Factory and Singleton Factory Method Pattern: - essential design pattern in OOP - focuses on object creation mechanisms - aims to create objects in a manner suitable to the situation Types: Simple Factory, Factory Method, Abstract Factory; Simple Factory is not a true design pattern Crossy Road example: Product is Animal; ConcreteProduct is Cat, Dog, Duck; Factory is AnimalFactory; Object-Oriented Modelling Page 24 Crossy Road example: Product is Animal; ConcreteProduct is Cat, Dog, Duck; Factory is AnimalFactory; ConcreteFactory is BalancedAnimalFactory and RandomAnimalFactory Factory Method is a creational design pattern that provides an interface/contract for creating objects in a superclass but allows subclases to alter the type of objects that will be created. It's also known as Virtual Constructor. - Defines an interface/contract for creating objects - Delegates instantiation to subclasses It's Intent: - Provide an interface for object creation in a superclass - Allow subclasses to change the type of objects created - Promote loose coupling and scalability in the codebase Use the Factory Method when: 1. The exact types and dependencies of objects are not known beforehand 2. You want to provide users with a way to extend internal components of a library or framework 3. You want to save system resources by reusing existing objects instead of rebuilding them Pros and Cons: Pros: Avoids thight coupling between creator and concrete products, adheres to the SRP and Open/Clpsed Principles, simplifies code maintenance and extension Cons: can lead to an increase in the nr of classes due to the need for numerous subclasses Abstract Factory Pattern: You may need to create products that are related or dependent. Ensuring that MacOS Alert Dialogues use MacOS Buttons, not Windows Buttons Class Factory --- Class Concrete Factory extends Factory Interface Product --- Class Concrete Product implements Product ***Abstract Factory*** is a creational design pattern that lets you produce families of related objects without specifying their concrete classes. When to use? - When sys needs to be independent of how its objects are created - When the family of related objects is designed to be used together Example: C Factory - C Concrete Factory 1 - C Concrete Factory 2 I ProductA - C Concrete Product A1 - C Concrete Product A2 I ProductB - C Concrete Product B1 - C Concrete Product B2 Abstract Products declare interfaces for a set of distinct but related products forming a product family. Good practices of polymorphism.The classes, for ex Interface Chair and classes ModernChair, Victorian Chair implement Chair. Abstract Factory Interface declares a set of creation methods for all abstract products. Each Concrete Factory corresponds to a specific variant of products and creates only those product variants. Ex. class ModernFurnitureFactory implements FurnitureFactory and has 3 functions, for Chair, Sofa and CoffeeTable; each return ModernChair, ModernSofa and ModernCoffeeTable. Abstract Factory step-by-step: 1. Interfaces for each product and making all vaiants follow these interfaces 2. Factories for each variant then produce these objects without exposing the concrete classes Clients interact with factories and products through abstract types, allowing the flexibility to change factory and product types dynamically. Object-Oriented Modelling Page 25 Pros and Cons: Pros: Ensures products are compatible with each other, decouples client code from concrete product classes, adheres to SRP and Open/Closed Principles Cons: Can become complex due to many new interfaces and classes SIMPLE FACTORY PATTERN A creation method within a class is responsible for creating instances. This term generally refers to any method whose primary purpose is to create and return a new object Static Creation Method: allow calling a method on the class itself to create an instance, often providing clarity and control over the instantiation process. Simple Factory encapsulates object creation for a specific type, often based on given parameters. Centralizes and simplifies object creation. SINGLETON PATTERN You need a database object, how to make it easy? Singleton is a design pattern that: - Ensures a class has only one instance - Provides a global point of access to that instance Useful for coordinating actions across a system. Addresses 2 primary issues: - ensuring a single instance and providing a global access point These are vital for controlling access to shared resources and preventing inconsistencies in the application state. Singleton implementation involves making the constructor private and providing a static method that returnes the same instance. public class Singleton{ private static Singleton instance; private Singleton(){ public static Singleton getInstance(){ if (instance == null){ instance = new Singleton(); } } } Implementation Steps: 1. Private Instance: Add a private static field to store the singleton instance 2. Public Creation Method: Implement a public static method for retrieving the singleton instance 3. Lazy Initialization: Initialize the singleton lazily to ensure it's created only when needed Implementing a lazy initialization ensures the Singleton instance is created only when it's first requested, optimizing resource usage and application performance. Prons and Cons: Pros: Global access point, lazy initialization Cons: SRP Violation; Can mask bad design, Requires special handling in multithread scenarios. Commonly used for database connections, a common use case in many applications. Object-Oriented Modelling Page 26 Lecture 9 - W5 Saturday, March 23, 2024 10:32 PM Design Pattern Structural Design Patterns - focus on assembling objects and classes into larger structures while maintaining efficiency and flexibility. Adapter, Decorator, Facade, Proxy Decorator Pattern You want to offer an option of add-ons. - The need to extend the functionality of objects dinamically - Avoiding "class explosion" for similar yet distinct objects - Example: Different types of coffee in a coffee house application Class Explosion Problem - multiple classes for combinations of coffee and add-ons, results in a large, unmanageable number of subclasses How to solve this? Intro to decorator pattern Purpose: Dinamically adds behaviors to objects without modifying their structure Key Concept: Wraps additional behaviors around objects to enhance or modify their functionality Intent: Attach new behaviors to objects dinamically, Provide a flexible alternative to subclassing for extending functionality Issues with Subclassing: explosion of subclasses, inflexibility to combine multiple behaviors dynamically How it works: wraps the original object inside objects containing new behaviors; each wrapper(decorator) adds its behavior either before or after delegating to the wrapped object Pattern Structure: - Component: common interface for both wrappers and wrapped objects - Concrete comp: the object being wrapped - Decorator: base class for all decorators with a reference to a component - Concrete Decorators: classes that add new behaviors Implementing Decorator: 1. Define the component interface 2. Create a concrete component class 3. Develop a base decorator class 4. Implement concrete decorators Key Considerations: - Ensure all comp and dec implement the component interface - Dec should delegate to the wrapped object and add their behavior Another Problem: - You have different types of data soruces, txt files, database, etc - You want to encrypt the data you store or compress it - The base decorator delegates all work to the wrapped component - Each decorator adds its behavior either before or after calling the wrapped object - This pattern allows stacking multiple decorators to add several behaviors Benefits of Decorator Pattern Flexibility in adding new functionality, avoids class explosion by using composition over inheritance, easier to maintain Object-Oriented Modelling Page 27  Flexibility in adding new functionality, avoids class explosion by using composition over inheritance, easier to maintain and extend Limitations Can lead to complex code structures Difficulty in debugging, as it introduces layers of abstraction Potential performance issues due to increased object creation Decorator vs Subclassing: Decorator allows more flexibility than subclassing, avoids rigid class hierarchy and promotes loose coupling + adherence to the Open/Closed Principle ADAPTER DESIGN PATTERN Purpose: make 2 incompatible interfaces compatible; also known as wrapper, connecting new code to legacy code or third- party libraries. Intent: allows objects with incompatible interfaces to work together acts as a bridge between 2 incompatible interfaces, effectively allowing them to communicate Example: stock market monitoring app downloads data in XML, needs integration with a 3-rd party analytics library requiring JSON, but incompatibility between data formats (XML vs JSON). Solution: adapter pattern -> enables collaboration by converting XML interface for Analytics Library compatibility [XML - ADAPTER- JSON] Purpose: use an existing class whose interface is incompatible with your code; ideal for integrating new classes with old ones and working with 3-rd party libraries Prons and Cons: Pros: -> SRP -> separates the interface conversion code from the primary business logic -> Open/Closed Principle -> allows introducing new types of adapters without breaking existing client code Cons: increases overall complexity due to the introduction of new interfaces and classes FACADE PATTERN Simplifies complex system interactions Provides a unified interface to a set of interfaces in a subsystem High-level abstraction over complex subsystems The challenge: managing complex dependencies and interactions. The client needs to interact with complex subsystems. Simplify interaction using a facade. Advantages: Simplicity (simple interface to complex subsystems) Decoupling (clients interact with facade rather than direct subsystem) Maintainability (changes in subsystems less likely to affect clients) Relations with other patterns: Adapter vs Facade -> adapter wraps one object, facade works with an entire subsystem of objects Facade and Singleton -> often, a single facade object is sufficient, making it a good candidate for a Singleton PROXY PATTERN - Provides a surrogate or placeholder for another object - Controls access to the original object - Use cases: Security, Remote Object Access Intent: acts as a substitute to control access to another object Object-Oriented Modelling Page 28 Intent: acts as a substitute to control access to another object Use cases: ideal for scenarios needing object access management without changing the object's behavior Example: A credit card acting as a proxy for a bank account, which in turn is a proxy for a bundle of cash. Both provide a means for payment but with additional layers of control and convenience. Types of Proxy Patterns: 1. Remote Proxy: access to objects located in different address spaces 2. Virtual Proxy: delays the creation and initialization of expensive objects until needed 3. Protection Proxy: controls access to an object based on access rights The Problem: Access management for resource-intensive objects or services, security assurance complexities, simplification of remote service access The Solution: Act as an intermediary for controlling access, provides a layer to handle security, manage initialization, and simplify remote access Applicability of Proxy Pattern: - It is highly versatile, apply in situations requiring: Lazy initialization (Virtual Proxy) Access control (Protection Proxy) Remote object access (Remote Proxy) Other use cases like logging, caching, or auditing access Pros and Cons: Pros: Control the service object indirectly, manage the lifecycle and initialization of the service, introduce new proxies without changing the service or clients Cons: Can complicate the code structure with additional classes, may introduce latency in the response from the service Object-Oriented Modelling Page 29 Lecture 10 - W5 Sunday, March 24, 2024 5:16 PM Continuation of Design Pattern Behavioral Design Patterns - Focus on effective communication and the assignment of responsibilities among objects Observer and Strategy STRATEGY PATTERN --------- Composition over Inheritance! - Defining a family of algorithms - Encapsulating each algorithm - Making them interchangeable Inheritance vs Composition - Inheritance is not always intended for code reuse - Composition offers greater flexibility in many scenarios - Strategy Pattern focuses on using composition over inheritance Duck example: Strategy Pattern allows the duck's behaviors to vary independently, encapsulating quaking and flying behaviors Intend: define a set of interchangable algorithms or strategies that can be selected at runtime according to the needs of the context or client Problem: need for a flexible way to incorporate different behaviors or algorithms within a class and the ability to change them at runtime Solution: separating the behavior into different strategy classes and using a reference to these strategies in the context class Advantages: promotes flexible code structure, allows behaviors to change dynamically, reduces dependency on inheritance Define interfaces for each behavior; Implement different flying and quacking behaviors; subclasses of Duck can choose different behaviors, making it easier to add new behaviors without modifying existing classes Inheritence can lead to duplicated code across subclasses; Strategy Pattern avoids duplication by sharing behavior implementations, allows ducks to have various combinations of behaviors, easy to maintain and extend Structure: - Context --- Maintains a reference to a Strategy object and delegates it the algorithm execution - Strategy --- Common interface for all strategies defining the algorithm execution method - ConcreteStrategy --- Implements the algorithm using the Strategy Interface Use Strategy when: - different variations of an algorithm and want to switch between them at runtime - avoid exposing complex, alg-specific data structures - replace inheritance with composition for behavioral variations Object-Oriented Modelling Page 30  - replace inheritance with composition for behavioral variations Pros and Cons: Pros: Open/Closed Principle by allowing the introduction of new strategies without changing the context; Simplifies unit testing by isolating algorithms Cons; Increases the nr. of objects in the application, Clients must be aware of the differences OBSERVER PATTERN Scenario: When an object changes its state, other objects need to be notified Challenge: Continuously checking the state of an object is inefficient Definition: A design pattern where an object, known as the subject, notifies a list of observers about its state changes Push vs Pull notification Intent: establishment of a subscription mechanism to notify multiple objects about any events that happen to the object they're observing Problem: managing knowledge about changes in a system's state can be complex when multiple entities need updates Solution: This pattern offers a subscription model where subjects notify observers about changes, promoting decoupling and efficient data distribution Example: Weather Station Observable: Weather Station measuring and updating weather data Observers: Displays showing updated weather Advantages: - Reduces Coupling: Observers are loosely coupled with the subject - Real-time Update: Efficient update mechanism for state changes Push vs Pull: - Push Model: Subject sends detailed data to observers - Pull Model: Observers request data from the subject Registerning Observers: Observers must register themselves to the subject Allows dynamic addition and removal of observers Benefits of Observer Pattern: Scalability: Easily add new observers without modifying the subject Flexibility: Supports both push and pull data models Limitations: Potential for Memory Leaks: Observers need to be explicitly removed Unexpected Updates: Observers might receive updates at unpredictable times Summary and Conclusion: - Observer Pattern is crucial for state change notification in software design Object-Oriented Modelling Page 31 - Observer Pattern is crucial for state change notification in software design - Offers a robust, scalable, and flexible solution for maintaining consistency across different parts of a system - Suitable for various applications like UI, weather monitoring, and more Object-Oriented Modelling Page 32 Design Patterns - useful, additional information Thursday, April 4, 2024 3:52 PM Here are some very helpful screenshots regarding design patterns from RefactoringGuru. Most stuff are repetitive for the design patterns, that's why I didn't add them, because they are covered here anyway. Facade Adapter Decorator Object-Oriented Modelling Page 33 Singleton Object-Oriented Modelling Page 34