Dive Into Design patterns

Cuốn sách level trung bình.

1. Introduce to OOP

1.1 Basic of OOP

• Objects and classes ?

Class là trừu tượng hóa của objects. Objects là instance of (biểu hiện cụ thể) class.

Chúng ta có một class Cat chưa đựng State, behavior.

Với mỗi loại object thì chúng ta sẽ có State và behavior cụ thể. Nhưng có mẫu chung giống nhau về state và behavior.

• Class hierarchies : cây class

1.2 Pillars of OOP: tính chất của OOP

• Abstraction : là mô hình hóa state and behaviors của đối tượng thực tế trong hoàn cảnh cụ thể.

• Encapsulation: che dấu các chi tiết phức tạp bên trong, cho phép người dùng sử dụng dễ dàng qua interface.

• Inheritance: là reuse lại mã nguồn.

Trong bộ nhớ thì biến B --> reference của nó ở trong Heap. Compile inheritance trong lập trình.

• Polymorphism : một hành động có thể thực hiện nhiều cách khác nhau.

1.3 Relations Between Objects

• Association

• Dependency

• Composition

• Aggregation

2. Introduce to Design patterns

3.Software Design Principles

3.1 Features of Good Design

• Code reuse : cost and time

Three levels of code reuse:

1. Reuse classes

2. Reuse design patterns

3. Reuse frameworks

• Extensibility : mở rộng

Change is the only constant thing in a programmer’s life

3.2 Design Principles

Thế nào là good software design : làm sao để đo lường, và luyện tập.

• Encapsulate What varies: xác định các thành phần có thể thay đổi của software

  • Encapsulate methods

• Encapsulate on a class level

3.3 Program to an interface, not an implementation

3.4 Favor composition over Inheritance

• A subclass can't reduce the interface of the super class.

Interface: declaration

Abstract class : declarations + implementation

Class : implementation

• When overriding methods you need to make sure that new behavior is compatible with the base one.

• Inheritance breaks encapsulation of super class.

• Subclasses are tightly coupled to super classes.

• Trying to reuse code through inheritance can lead to creating parallel inheritance hierachies.

4. SOLID

4.1 Single Responsibility Principle

A class should have just one reason to change.

4.2 Open / Close principle

Classes should be open for extension but closed for modification.

4.3 Liskov Substitution principle

4.4 Interface segregation principle

4.5 Dependency Inversion