The book “Object-Oriented Approach. 5th int. ed. “

That is why Matt Weissfeld advises developing an object-oriented way of thinking and only then proceed with object-oriented development in a specific programming language.
This book is written by the developer for developers and allows you to choose the best approaches for solving specific problems. You will learn how to correctly apply inheritance and composition, understand the difference between aggregation and association, and stop confusing the interface and implementation.
Programming technologies are constantly changing and developing, but object-oriented concepts are platform independent and remain consistently effective. This publication focuses on the fundamental fundamentals of OOP: design patterns, dependencies, and SOLID principles that will make your code understandable, flexible, and well-maintained.
SOLID Object Oriented Design Principles
1. SRP: sole responsibility principle
The principle of sole responsibility states that only one reason is required to make changes to a class. Each class and program module must have one task in priority. Therefore, you should not introduce methods that can cause changes to the class for more than one reason. If the class description contains the word “and,” then the SRP principle may be violated. In other words, each module or class must be responsible for one part of the software functionality, and such responsibility must be fully encapsulated in the class.
Creating a hierarchy of figures is one of the classic examples illustrating inheritance. This example is often found in teaching, and I use it throughout this chapter (as well as throughout the book). In this example, the Circle class inherits attributes from the Shape class. The Shape class provides the abstract calcArea () method as a contract for a subclass. Each class that inherits from Shape must have its own implementation of the calcArea () method:
abstract class Shape{
protected String name;
protected double area;
public abstract double calcArea();
}
In this example, the Circle class, which inherits from the Shape class, provides its implementation of the calcArea () method, if necessary:
class Circle extends Shape{
private double radius;
public Circle(double r) {
radius = r;
}
public double calcArea() {
area = 3.14*(radius*radius) ;
return (area);
};
}
The third class, CalculateAreas, calculates the area of the various shapes contained in the Shape array. The Shape array is unlimited in size and can contain various shapes, such as squares and triangles.
class CalculateAreas {
Shape[] shapes;
double sumTotal=0;
public CalculateAreas(Shape[] sh) {
this.shapes = sh;
}
public double sumAreas() {
sumTotal=0;
for (inti=0; ipublic class TestShape {
public static void main(String args[]) {
System.out.printin("Hello World!");
Circle circle = new Circle(1);
Shape[] shapeArray = new Shape[1];
shapeArray[0] = circle;
CalculateAreas ca = new CalculateAreas(shapeArray) ;
ca.sumAreas() ;
ca.output();
}
}
Now that we have a test application at our disposal, we can focus on the problem of the principle of sole responsibility. Again, the problem is with the CalculateAreas class and the fact that this class contains behaviors for adding up the areas of various shapes, as well as for outputting data.
The fundamental question (and, in fact, the problem) is that if you need to change the functionality of the output () method, you will need to make changes to the CalculateAreas class regardless of whether the method for calculating the area of shapes changes. For example, if we suddenly want to output data to the HTML console, and not to plain text, we will need to re-compile and re-embed code that adds up the area of the shapes. All because liability is related.
In accordance with the principle of sole responsibility, the task is to change one method does not affect the other methods and do not have to re-compile. "The class should have one, only one, reason for change - the only responsibility that needs to be changed."
To solve this issue, you can put two methods in separate classes, one for the original console output, the other for HTML output:
class CaiculateAreas {;
Shape[] shapes;
double sumTotal=0;
public CalculateAreas(Shape[] sh) {
this.shapes = sh;
}
public double sumAreas() {
sumTotal=0;
for (inti=0; i") ;
System.out.printin("Total of all areas = " + areas);
System.out.printin("