Especially for the start of classes in the new stream of the course "Architecture and Design Patterns" I prepared one more author's material.
Introduction
When it comes to classic design patterns, one cannot help but think of object-oriented programming itself. After all, GoF patterns are exactly object-oriented programming patterns. Functional programming has its own patterns.
In general, everything is arranged as follows: there is object-oriented programming itself. He has principles. From the principles of object-oriented programming, the GRASP patterns we parsed follow (as an option - SOLID principles), from which, in turn, the GoF patterns follow. A number of interesting things follow from them, for example, enterprise patterns.
Object Oriented Paradigm
The definition states that "Object-oriented programming is a programming paradigm in which the basic concept is the notion of an object that is identified with a domain."
Thus, the system is represented as a set of objects of the subject area, which interact with each other in some way. Each object has three components: identity, state and behavior.
The state of an object is a collection of all its fields and their values.
An object's behavior is the collection of all methods of an object's class.
Object identity is what distinguishes one class object from another class object. From a Java perspective, it is by identity that the equals method is defined.
Object Oriented Programming Principles
Object-oriented programming has a number of principles. The idea of their number differs. Someone claims that there are three of them (old school of programmers), someone that there are four of them (new school of programmers):
- Abstraction
- Encapsulation
- Inheritance
- Polymorphism
I propose to talk about them in more detail. The only thing is that I suggest not to consider abstraction, because I consider myself to be in the old school of programmers.
Encapsulation
Contrary to the opinion of many interviewees (and sometimes interviewees), encapsulation is not "when all fields are private." Encapsulation is the most fundamental principle of software design, its traces are observed only at the micro-level, but also at the macro-design level.
The scientific definition states that "Encapsulation is the principle that any class and, in a broader sense, any part of the system should be considered as a" black box ": the user of a class or subsystem should only see the interface (i.e. a list of declared properties and methods ) and not delve into the internal implementation. "
Thus, it turns out that if class A accesses the fields of class B directly, this leads not to the fact that "information security is violated", but to the fact that class A is tied to the internal device of class B, and an attempt to change the internal structure of class B will lead to a change of class A. Moreover, class A does not just work with the fields of class B, it works according to some business logic. That is, the logic for working with the state of class B lies in class A, and when we want to reuse class B, this cannot be done, because without a piece of class A, class B may be useless, which will lead to the fact that class B will have to be given along with class A. Extrapolating this to the entire system, it turns out that only the entire system can be reused.
Encapsulation is the most overlooked principle and, unfortunately, few people interpret correctly. It allows you to minimize the number of links between classes and subsystems and, accordingly, to simplify the independent implementation and modification of classes and subsystems.
Inheritance
Inheritance is the ability to derive one class from another while preserving all the properties and methods of the ancestor class (superclass), adding new properties and
methods if necessary .
Inheritance is the most overrated principle. It was once believed that "For an ideal programmer, the inheritance tree goes to infinity and ends with an absolutely empty object", because once people did not understand very well that inheritance is a way to express such a property of the real world as hierarchy, and not a way reuse the code by inheriting the machine from the refrigerator, because both items have a handle. It is advisable to avoid inheritance whenever possible, because inheritance is a very strong relationship. To reduce the number of levels of inheritance, it is recommended to build a tree from the bottom up.
Polymorphism
Polymorphism is the ability to use descendant classes in a context that was intended for the ancestor class.
Behind the most sadistic definition lies the programming language's ability to decompose a task and refactor if's and switches.
