Back to Basic

OOP: Object Oriented Programming

UML: Unified Modeling Language

SOLID: S.O.L.I.D. Software Development, One Step at a Time

Object Oriented Analysis & designing

https://www.codeproject.com/Articles/1137299/Object-Oriented-Analysis-and-Design

Background

Microsoft Application Architecture Guide, 2nd Edition

Principles of Object Oriented Design

Architectural Patterns and Styles and here

Enterprise Solution Patterns Using Microsoft .NET

Key Principles of Software Architecture

Khái niệm lập trình hướng đối tượng, các nguyên lý (principle) và các mẫu thiết kế (design pattern) trong lập trình hướng đối tượng (OOP)

Một số khái niệm OOP cơ bản:

• Abstraction (Tính trừu tượng)
• Encapsulation (Tính bao đóng)
• Inheritance (Tính kế thừa)
• Polymophirsm (Tính đa hình)

• OOP: here
• 12 essential software development principles and concepts
• There are five principles of class design call SOLID
  • The first five principles are principles of class design. They are:
    

    SRP	The Single Responsibility Principle	A class should have one, and only one reason to change.
    OCP	The Open Closed Principle	You should be able to extend a classes behavior, without modifying it.
    LSP	The Liskov Substitution Principle	Derived classes must be substitutable for their base classes.
    ISP	The Interface Segregation Principle	Make fine grained interfaces that are client specific.
    DIP	The Dependency Inversion Principle	Depend on abstractions, not on concretions.

    
    The next six principles are about packages. In this context a package is a binary deliverable like a .jar file, or a dll as opposed to a namespace like a java package or a C++ namespace.
    
    
  • The first three package principles are about package cohesion, they tell us what to put inside packages:
    
    

    REP	The Release Reuse Equivalency Principle	The granule of reuse is the granule of release.
    CCP	The Common Closure Principle	Classes that change together are packaged together.
    CRP	The Common Reuse Principle	Classes that are used together are packaged together.

    
    
  • The last three principles are about the couplings between packages, and talk about metrics that evaluate the package structure of a system.
    
    

    ADP	The Acyclic Dependencies Principle	The dependency graph of packages must have no cycles.
    SDP	The Stable Dependencies Principle	Depend in the direction of stability.
    SAP	The Stable Abstractions Principle	Abstractness increases with stability.

• 1) Design Principles
  • SOLID principles: The SOLID principles of Object Oriented Design include these five principles:SOLID-July-2013
    • SRP – Single Responsibility Principle
    • OCP – Open/Closed Principle
    • LSP – Liskov Substitution Principle
    • ISP – Interface Segregation Principle
    • DIP – Dependency Inversion Principle
  • Separation of Concerns (SoC): Concerns are the different aspects of software functionality. For instance, the "business logic" of software is a concern, and the interface through which a person uses this logic is another. The separation of concerns is keeping the code for each of these concerns separate. Changing the interface should not require changing the business logic code, and vice versa.
  • Principle - Don't Repeat Yourself (DRY)
    • A basic strategy for reducing complexity to managable units is to divide a system into pieces.
    • The DRY principle states that these small pieces of knowledge may only occur exactly once in your entire system.
    • Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.
    • Achieving DRYness
    • DRY is a philosophy that packages logic into representations.
    • When you find yourself writing code that is similiar or equal to something you've written before, take a moment to think about what you're doing and don't repeat yourself.
    • Bad code is rarely produced by bad coders.
    • DRYness is achieved by good planning.
  • Principle - Keep it Simple Stupid (KISS)
    • The simplest explanation tends to be the right one.
    • There are many people involved in the conceptual process, who do not have the technical expertise to make a reliable cost-benefit analysis
  • Principle - You Aren't Gonna Need It (YAGNI)
    • Coding is about building things.
    • 80% of the time spent on a software project is invested in 20% of the functionality.

      

    • Bad concepts can often be identified by the lack of non-functional requirements.
    • Last, but not least, remember the 80:20 rule-of-thumb!
    • If you want to be an experienced and business-proofed developer, you have to master the You ain't gonna need it principle. If you want to keep your passion, you have to fight against it every now and then.
• 2) Design Patterns (here)
  • Inversion of Control (IoC): here ~ Service Locator & Dependency Injection (DI) and here
    • The Inversion of Control (IoC) and Dependency Injection (DI) patterns are all about removing dependencies from your code.
  • Model-View-Controller (MVC) design pattern is an excellent example of separating these concerns for better software maintainability.
  • Model-View-Presenter (MVP)
  • Model-View-ViewModel (MVVM)
• Difference between Separation of Concern vs Single Responsibility Principle (SoC vs SRP): here

  • Single Responsibility Principle (SRP) - give each class just one reason to change; and "Reason to change" == "responsibility". In example: Invoice class does not have a responsibility to print itself.

  • Separation of Concerns (since 1974). Concern == feature of system. Taking care of each of the concerns: for each one concern, other concerns are irrelevant. Hiding implementation of behavior.

Frontend

• HTML
• CSS
• JavaScript

Backend

• Microsoft .NET
• C#
• LINQ
• SQL
• ASP.NET
• XML
• JSON
• UML