Basics of OOP

Object-Oriented Programming (OOP)

Object-oriented programming (OOP) is a programming paradigm based on the concept of wrapping pieces of data, and behavior related to that data, into special bundles call objects. which are contructed from a set of “blueprints”, defined by programmer, called classes.

Objects, classes

Class hierarchies

Pillars of OOP

Abstraction (Tính trừu tượng)

Encapsulation (Tính đóng gói)

To start a car engine, you only need to turn a key or press a button. You don’t need to connect wires under the hood, rotate the crankshaft and cylinders, and initiate the power cycle of the engine. These details are hidden under the hood of the car. You have only a simple interface: a start switch, a steering wheel and some pedals. This illustrates how each object has an interface—a public part of an object, open to interactions with other objects.

Để khởi động động cơ ô tô, bạn chỉ cần vặn chìa khóa hoặc nhấn nút. Bạn không cần nối dây dưới mui xe, xoay trục khuỷu và xi lanh cũng như bắt đầu chu trình công suất của động cơ. Những chi tiết này được ẩn dưới mui xe. Bạn chỉ có một giao diện đơn giản: nút khởi động, vô lăng và một số bàn đạp. Điều này minh họa cách mỗi object có một interface — một phần công khai của một object, mở ra để tương tác với các object khác.

Encapsulation is the ability of an object to hide parts of its state and behaviors from other objects, exposing only a limited interface to the rest of the program.

Encapsulation là khả năng của một object để ẩn các phần của state và behaviour của nó khỏi các object khác, chỉ tiết lộ một interface giới hạn cho phần còn lại của chương trình.

To encapsulate something means to make it private, and thus accessible only from within of the methods of its own class. There’s little bit less restrictive mode called protected, that makes a member of a class available to subclasses as well.

Để encapsulate một cái gì đó có nghĩa là làm cho nó private, và do đó chỉ có thể truy cập từ bên trong các methods của class của nó. Có một chế độ ít hạn chế hơn gọi là protected, làm cho một member của một class cũng có thể truy cập từ các subclasses.

Interfaces and abstract classes/methods of most programming languages are based on the concepts of abstraction and encapsulation. In modern OOP languages, the interface mechanism (usually declared with the interface or protocol keyword) lets you define contracts of interaction between objects. That’s oen of reasons why you the interfaces only care about behaviours of objects, and why you can’t declare a field in an interface.

Các interfaces và abstract classes/methods của hầu hết các ngôn ngữ lập trình dựa trên các khái niệm của abstraction và encapsulation. Trong các ngôn ngữ OOP hiện đại, cơ chế interface (thường được khai báo với từ khóa interface hoặc protocol) cho phép bạn xác định các ràng buộc tương tác giữa các objects. Đó là một trong những lý do tại sao các interfaces chỉ quan tâm đến các behaviors của các objects, và tại sao bạn không thể khai báo một field trong một interface.

class FlyingTransport {
    public:
        virtual fly(origin, destination, passengers) = 0;
};

class Airport {
    private:
        string name;
        string city;
        string country;
    public:
        AirPort(string name, string city, string country) {
            this->name = name;
            this->city = city;
            this->country = country;
        }
        string getName() {
            return name;
        }
        string getCity() {
            return city;
        }
        string getCountry() {
            return country;
        }
        bool accept(FlyingTransport transport) {
            // some logic
        }
};

class Heliport : public Airport {
    public:
        Heliport(string name, string city, string country) : Airport(name, city, country) {}
        bool accept(Helicopter helicopter) {
            // some logic
        }
};

Inheritance (Tính kế thừa)

Inheritance is the ability to build new classes on top of existing ones. The main benefit of inheritance is code reuse. If you want to create a class that’s slightly different from an existing one, there’s no need to duplicate code. Instead, you extend the existing class and put the extra functionality into a resulting subclass, which inherits fields and methods of the superclass

Inheritance là khả năng xây dựng các classes mới trên cơ sở các classes hiện có. Lợi ích chính của inheritance là tái sử dụng mã. Nếu bạn muốn tạo một class mà khác một chút so với một class hiện có, không cần phải sao chép mã. Thay vào đó, bạn mở rộng class hiện có và đặt chức năng bổ sung vào một subclass kết quả, kế thừa các fields và methods của superclass.

The consequence of using inheritance is that subclasses have the same interface as their parent class. You can’t hide a method in a subclass if it was declared in the superclass. You must also implement all abstract methods, even if they don’t make sense for your subclass

Hậu quả của việc sử dụng inheritance là các subclasses có cùng interface với parent class. Bạn không thể ẩn một method trong một subclass nếu nó được khai báo trong superclass. Bạn cũng phải triển khai tất cả các abstract methods, ngay cả khi chúng không hợp lý cho subclass của bạn.

In most programming languages a subclass can extend only one superclass. On the other hand, any class can implement several interfaces at the same time. But, as I mentioned before, if a superclass implements an interface, all of its subclasses must also implement it.

Trong hầu hết các ngôn ngữ lập trình, một subclass chỉ có thể mở rộng một superclass. Ngược lại, bất kỳ class nào cũng có thể triển khai nhiều interfaces cùng một lúc. Nhưng, như tôi đã đề cập trước đó, nếu một superclass triển khai một interface, tất cả các subclasses của nó cũng phải triển khai nó.

Polymorphism (Tính đa hình)

Let’s look at some animal examples. Most Animals can make sounds. We can anticipate that all subclasses will need to override the base makeSound method so each subclass can emit the correct sound; therefore we can declare it abstract right away. This lets us omit any default implementation of the method in the superclass, but force all subclasses to come up with their own.

Hãy xem một số ví dụ về động vật. Hầu hết các động vật có thể phát ra âm thanh. Chúng ta có thể dự đoán rằng tất cả các subclasses sẽ cần phải ghi đè method makeSound cơ bản để mỗi subclass có thể phát ra âm thanh đúng; do đó chúng ta có thể khai báo nó là abstract ngay lập tức. Điều này cho phép chúng ta bỏ qua bất kỳ triển khai mặc định nào của method trong superclass, nhưng buộc tất cả các subclasses phải tạo ra triển khai của riêng mình.

Imagine that we’ve put several cats and dogs into a large bag. Then, with closed eyes, we take the animals one-by-one out of the bag. After taking an animal from the bag, we don’t know for sure what it is. However, if we cuddle it hard enough, the animal will emit a specific sound of joy, depending on its con- crete class.

Hãy tưởng tượng rằng chúng ta đã đặt một số con mèo và chó vào một chiếc túi lớn. Sau đó, với đôi mắt đóng, chúng ta lấy từng con vật ra một cách tuần tự khỏi túi. Sau khi lấy một con vật ra khỏi túi, chúng ta không chắc chắn nó là gì. Tuy nhiên, nếu chúng ta ôm chặt nó đủ mạnh, con vật sẽ phát ra một âm thanh cụ thể của niềm vui, tùy thuộc vào class cụ thể của nó.

bag = [new Cat(), new Dog()];

foreach (Animal a : bag)3
  a.makeSound()4

// Meow!
// Woof!

The program doesn’t know the concrete type of the object contained inside the a variable; but, thanks to the special mechanism called polymorphism, the program can trace down the subclass of the object whose method is being executed and run the appropriate behavior.

Chương trình không biết loại cụ thể của object chứa bên trong biến a; nhưng, nhờ vào cơ chế đặc biệt gọi là polymorphism, chương trình có thể theo dõi subclass của object mà method đang được thực thi và chạy hành vi phù hợp.

Polymorphism is the ability of a program to detect the real class of an object and call its implementation even when its real type is unknown in the current context.

Polymorphism là khả năng của một chương trình để phát hiện ra class thực sự của một object và gọi triển khai của nó ngay cả khi loại thực sự của nó không biết trong ngữ cảnh hiện tại.

You can also think of polymorphism as the ability of an object to “pretend” to be something else, usually a class it extends or an interface it implements. In our example, the dogs and cats in the bag were pretending to be generic animals

Bạn cũng có thể nghĩ về polymorphism như khả năng của một object để “giả vờ” là một cái gì đó khác, thường là một class mà nó mở rộng hoặc một interface mà nó triển khai. Trong ví dụ của chúng tôi, những con chó và mèo trong túi đang giả vờ là động vật chung.

Relations Between Objects

In addition to inheritance and implementation that we’ve already seen, there are other types of relations between objects that we haven’t talked about yet.

Bên cạnh inheritance và implementation mà chúng ta đã thấy, còn có các loại quan hệ khác giữa các objects mà chúng ta chưa nói đến.

Association

Association is a type of relationship in which one object uses or interacts with another. In UML diagrams the association relationship is shown by a simple arrow drawn from an object and pointing to the object it uses. By the way, having a bidirectional association is a completely normal thing. In this case, the arrow has a point at each end.

Association là một loại quan hệ trong đó một object sử dụng hoặc tương tác với một object khác. Trong các biểu đồ UML, quan hệ association được hiển thị bằng một mũi tên đơn được vẽ từ một object và trỏ đến object mà nó sử dụng. Bằng cách này, có một association hai chiều là một điều hoàn toàn bình thường. Trong trường hợp này, mũi tên có một mũi tên ở mỗi đầu.

In general, you use an association to represent something like a field in a class. The link is always there, in that you can always ask an order for its customer. It need not actually be a field, if you are modeling from a more interface perspective, it can just indicate the presence of a method that will return the order’s customer.

Nói chung, bạn sử dụng một association để đại diện cho một cái gì đó như một field trong một class. Liên kết luôn tồn tại, trong đó bạn luôn có thể yêu cầu một đơn hàng cho khách hàng của mình. Nó không cần phải thực sự là một field, nếu bạn đang mô hình từ một góc nhìn giao diện hơn, nó chỉ có thể chỉ ra sự hiện diện của một method sẽ trả về khách hàng của đơn hàng.

Dependency

Dependency is a weaker variant of association that usually implies that there’s no permanent link between objects. Dependency typically (but not always) implies that an object accepts another object as a method parameter, instantiates, or uses another object. Here’s how you can spot a dependency between classes: a dependency exists between two classes if changes to the definition of one class result in modifications in another class.

Dependency là một biến thể yếu hơn của association mà thường ngụ ý rằng không có liên kết cố định giữa các objects. Dependency thường (nhưng không phải lúc nào cũng) ngụ ý rằng một object chấp nhận một object khác như một tham số method, khởi tạo hoặc sử dụng một object khác. Đây là cách bạn có thể nhận biết một dependency giữa các classes: một dependency tồn tại giữa hai classes nếu các thay đổi trong định nghĩa của một class dẫn đến sự thay đổi trong một class khác.

Composition

Composition is a “whole-part” relationship between two objects, one of which is composed of one or more instances of the other. The distinction between this relation and others is that the component can only exist as a part of the container. In UML the composition relationship is shown by a line with a filled diamond at the container end and an arrow at the end pointing toward the component.

Composition là một mối quan hệ “toàn-phần” giữa hai objects, trong đó một trong số đó được tạo thành từ một hoặc nhiều trường hợp của object kia. Sự phân biệt giữa mối quan hệ này và các mối quan hệ khác là thành phần chỉ có thể tồn tại như một phần của container. Trong UML, mối quan hệ composition được hiển thị bằng một đường thẳng với một hình kim cương được điền ở đầu container và một mũi tên ở cuối trỏ về phần thành phần.

While we talk about relations between objects, keep in mind that UML represents relations between classes. It means that a university object might consist of multiple departments even though you see just one “block” for each entity in the diagram. UML notation can represent quantities on both sides of relationships, but it’s okay to omit them if the quantities are clear from the context

Trong khi chúng ta nói về mối quan hệ giữa các objects, hãy nhớ rằng UML đại diện cho mối quan hệ giữa các classes. Điều đó có nghĩa là một object university có thể bao gồm nhiều departments ngay cả khi bạn chỉ thấy một “block” cho mỗi thực thể trong biểu đồ. Ký hiệu UML có thể đại diện cho các số lượng ở cả hai phía của mối quan hệ, nhưng nếu các số lượng rõ ràng từ ngữ cảnh, bạn có thể bỏ qua chúng.

Aggregation

Aggregation is a less strict variant of composition, where one object merely contains a reference to another. The container doesn’t control the life cycle of the component. The component can exist without the container and can be linked to several containers at the same time. In UML the aggregation relationship is drawn the same as for composition, but with an empty diamond at the arrow’s base.

Aggregation là một biến thể ít nghiêm ngặt hơn của composition, trong đó một object chỉ chứa một tham chiếu đến một object khác. Container không kiểm soát vòng đời của thành phần. Thành phần có thể tồn tại mà không cần container và có thể được liên kết với nhiều container cùng một lúc. Trong UML, mối quan hệ aggregation được vẽ giống như cho composition, nhưng với một hình kim cương trống ở cơ sở của mũi tên.

References

Dive Into Design Partterms - Alexander Shvets

Basics of OOP (Dive Into Design Partterms - Alexander Shvets)

OOP