Design Principles

A Design principle is a basic tool or technique that can be applied to designing or writing code to make it more maintainable, flexible or extensible.

Some of the design principles are:

• Encapsulate what varies
  
• Code to an interface rather than to an implementation
  
• Each class in your application should have only one reason for change
  
• Classes are about behavior and functionality
  
• Classes should be open for extension and closed for modification - Open Closed Principle
  • It features Inheritance, and composition
    
  • It exhibits abstraction and encapsulation in action
• Avoid duplicate code by abstracting out things that are common and placing those things in a single location - Don't repeat yourself
  • It's really about one requirement at one place
    
  • It's not only about removing duplication; it's also about making good decisions about how to break up your systems functionality.
    
• Every object in your system should have a single responsibility and all its services should be focused on carrying out that single responsibility - The Single Responsibility Principle (SRP)
  
  • Using this principle doesn't essentially make your classes smaller; it makes them larger instead, as all services exposed by the class remains at one point. Also, it will enable you to create fewer classes which mean better maintenance.
    
  • Cohesion is the other name for this principle, if you are writing a highly cohesive class it means that this principle is correctly implemented.
    
• Subtypes must be substitutable for their base types - The Liskov Substitution Principle (LSP)
  
  • The LSP is all about well designed inheritance. When you inherit from your base class you must be able to substitute your subclass for that base class without things going terribly wrong. If it does, then you must have used inheritance incorrectly.
    
  • Violating LSP makes the code confusing. It's hard to understand code that uses inheritance incorrectly.
    
  • Delegation comes to rescue in such circumstances - Delegation is when you hand over the responsibility for a particular task to another class or method.
    
    • If you need to use functionality in another class, but you don't want to change that functionality, consider using delegation over inheritance.
      
  • Composition
    
    • An alternative to
      inheritance just as delegation.
      
    • In composition, your object completely owns the composed objects, and they do not exist outside of their usage in your object.
      
    • E.g. a text file and its contents. If you delete the text file all its contents are gone!
      
  • Aggregation
    
    • Another alternative to inheritance.
      
    • In aggregation, you use another object inside your object. Both can exist outside of each other.
      
    • e.g. if you copy a file inside a folder, the file(s) and the folder continue to exist, even if you delete the folder, the file that's outside the folder will remain as it is.
      
  • If you favor delegation, composition, and aggregation over inheritance, your software will be more flexible, easier to maintain, extend and reuse.
    
    
     

Iterative and Evolutionary development - Heads up

• In this lifecycle approach, the development is organized into a series of short, fixed length mini projects called Iterations.
  
• The resultant of each iteration is a subset of the actual production level software. Its neither a prototype nor an experimental throw away.
  
• The software should grow with each iteration until it unifies with the expected end result and that's why its called Iterative and Incremental Development.
  
• Its called Iterative and Evolutionary because feedbacks and adaptation evolves the specification and design.
  
• Each iteration follows a model of Requirements analysis, followed by Design, followed by Implementation and test and finally complete system Integration test.
  
• How changes are handled in such an iterative approach?
  
  • The only thing that's permanent is Change its inevitable, so there is no point confronting it - embrace change instead.
    
  • Having said that, the iterative development doesn't encourage or invoke sudden changes, it tries to ease the process of change.
    
  • The early iterations can help in getting quick feedback from the business user, developer and tester - this minimizes speculation, and helps reaping the actual requirements and validating the path of development.
    
  • Its easy to understand that work proceeds through a series of build-feedback-adapt cycles. The early iterations will no doubt, have some deviations from the actual requirements or the true path, but it will align itself to the true path later on.
    
• There are multiple benefits of the Iterative Development:
  
  • Projects are less likely to fail.
    
  • Early rather than late mitigation of risks like technical, requirements, objectives, usability etc.,
    
  • Visible progress
    
  • Early feedbacks, user engagement, and adaptation leads to a refined and acceptable system
    
  • Complexity is managed - the team is saved from analysis-paralysis or very long and complex steps - they have portions in their plate that they can eat easily.
    
• The length of an iteration is equally important - it doesn't make sense to have a 6-week iteration in a 2 month long project.
  
  • Short is good
    
  • Small steps, rapid feedback and adaptation are at the core of Iterative development.
    
  • A key idea is that whatever be the best length it has to be timeboxed - fixed. The partial system must be integrated, tested, and stabilized by the scheduled date - no exceptions at that.
    

Analysis and Design - Heads up

• Analysis emphasizes on investigation of the problem and requirements. It's a broad term, so we will elaborate on the key ones:
  
  • Requirements analysis
    
    • Investigates requirements
      
  • Object oriented analysis
    
    • Investigates domain objects
      
• During the analysis of the problem and its requirements when a project is started the points to discuss are:
  
  • How is it going to be used?
    
  • What problems it solves?
    
  • What are its functions?
    
• During an object oriented analysis the focus is on finding and describing the objects or concepts in the problem domain. e.g. Department, Designation and Role in a Payroll system.
  
• Design emphasizes on a conceptual solution that is supposed to fulfill the requirements and doesn't care about implementation yet.
  
  • A description of a database schema and domain objects
    
• During object oriented design the focus is on defining the objects or concepts and figuring out how they collaborate with each other to fulfill a requirement. e.g. a Department may have many designations, and a designation may have different roles.
  
• Object oriented programming follows analysis and design.