@manhnguyenv

Welcome to my blog!

Background

December 29, 2017 13:18

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
  • 1) Design Principles
    • SOLID principlesThe 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.

 

Ee658124.b8220f0d-f76a-40d6-8b1b-5279f7cdcee9(en-us,PandP.10).png

Frontend

  • HTML
  • CSS
  • JavaScript

Backend

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

Categories

Recent posts