здрасти Сега продължаваме да се задълбочаваме в една обширна и изключително важна полезна тема: модели на проектиране. Днес нека поговорим за модела на моста. Подобно на други модели, мостовият модел служи за решаване на типични проблеми, които разработчикът среща при проектирането на софтуерна архитектура. Днес нека проучим характеристиките на този модел и да разберем How да го използваме.
Какъв е моделът на моста?
Моделът на моста е модел на структурно проектиране. С други думи, основната му работа е да създаде пълноценна структура от класове и обекти. Мостът прави това, като разделя един or повече класове на отделни йерархии: абстракция и реализация . Промяна във функционалността в една йерархия не води до промяна в другата. Всичко това е добре, но тази дефиниция е много широка и не отговаря на най-важния въпрос: "Какъв е моделът на моста?" Мисля, че ще ви бъде по-лесно да разберете практическото му приложение. Така че веднага, нека създадем класически сценарий за модела на моста. Имаме абстрактен Shapeклас, който представлява обща геометрична фигура:
Shape.java
public abstract class Shape {
public abstract void draw();
}
Когато решим да добавим форми като триъгълници и правоъгълници, ще ги накараме да наследят Shapeкласа:
Rectangle.java:
public class Rectangle extends Shape {
@Override
public void draw() {
System.out.println("Drawing rectangle");
}
}
Triangle.java:
public class Triangle extends Shape {
@Override
public void draw() {
System.out.println("Drawing triangle");
}
}
Всичко изглежда просто до момента, в който въвеждаме понятието цвят. Тоест всяка фигура ще има свой собствен цвят и от този цвят ще зависи функционалността на draw()метода. За да имаме различни реализации на draw()метода, трябва да създадем клас за всяка комбинация форма-цвят. Ако имаме три цвята, тогава имаме нужда от шест класа : TriangleBlack, TriangleGreen, TriangleRed, и . Шест класа не са толкова голям проблем. Но! Ако трябва да добавим нова форма or цвят, тогава броят на класовете нараства експоненциално. Как да излезем от тази ситуация? Съхраняването на цвят в поле и изброяването на всички опции с помощта на условни изрази не е най-доброто решение. Добро решение е да преместите цвета в отделен интерфейсRectangleBlackRectangleGreenRectangleRed. Едва казано, така напequalsо: нека създадем Colorинтерфейс с три реализации: BlackColor, GreenColorи RedColor:
Color.java:
public interface Color {
void fillColor();
}
BlackColor.java:
public class BlackColor implements Color {
@Override
public void fillColor() {
System.out.println("Filling in black color");
}
}
GreenColor.java
public class GreenColor implements Color {
@Override
public void fillColor() {
System.out.println("Filling in green color");
}
}
RedColor.java
public class RedColor implements Color {
@Override
public void fillColor() {
System.out.println("Filling in red color");
}
}
Сега добавяме Colorполе към Shapeкласа. Ще получим стойността му в конструктора.
Shape.java:
public abstract class Shape {
protected Color color;
public Shape(Color color) {
this.color = color;
}
public abstract void draw();
}
Ще използваме colorпроменливата в Shapeреализациите. Това означава, че формите вече могат да използват функционалността на Colorинтерфейса.
Правоъгълник.java
public class Rectangle extends Shape {
public Rectangle(Color color) {
super(color);
}
@Override
public void draw() {
System.out.println("Drawing rectangle");
color.fillColor();
}
}
Та-да! Сега можем да създаваме различни цветове и форми ad infinitum, а броят на класовете ще нараства само линейно. Полето Color colorе мост, който свързва две отделни класови йерархии.
Как да изградим мост: абстракция и реализация
Нека да разгледаме диаграма на класове, която изобразява модела на моста: Тук можете да видите две независими структури, които могат да бъдат модифицирани, без да засягат функционалността една на друга. В нашия случай:
Абстракцията е Shapeкласът
RefinedAbstraction е класовете TriangleandRectangle
Implementor е Colorинтерфейсът
ConcreteImplementor е BlackColorкласовете GreenColorи RedColor.
Класът Shapeе абстракция — механизъм за управление на запълването на форми с различни цветове, който делегира на интерфейса Color(Implementor). Класовете Triangleи Rectangleса конкретни класове, които използват механизма, предоставен от Shapeкласа. BlackColorи са конкретни реализации в йерархията на изпълнението GreenColor.RedColor
Къде да използвате модела на моста
Огромна полза от използването на този модел е, че можете да правите промени във функционалните класове в една йерархия, без да нарушавате логиката на другата. Освен това този подход помага да се намали свързването между класовете. Основното изискване при използването на този модел е „следвайте инструкциите“ — не пренебрегвайте нито една от тях! За тази цел, нека да разберем ситуациите, когато определено трябва да използвате модела на моста:
Ако трябва да разширите броя на обектите въз основа на комбинации от две концепции (напр. форми и цветове).
Ако искате да разделите голям клас, който не отговаря на принципа за единична отговорност, на по-малки класове, които имат тясна функционалност.
Ако е необходимо да се направят промени в логиката на определени обекти, докато програмата работи.
Ако е необходимо да се скрие изпълнение от клиентите на класа or библиотеката.
Когато използвате този модел, винаги помнете, че той добавя допълнителни обекти към вашия code - може да няма смисъл да го използвате в проект, където има само една форма и един or два възможни цвята.
Плюсове и минуси на модела
Подобно на други модели, мостът има Howто предимства, така и недостатъци. Предимства на модела на моста:
Той подобрява скалируемостта на codeа — можете да добавите функционалност, без да се страхувате, че ще счупите нещо в друга част на програмата.
Той намалява броя на подкласовете, когато броят на обектите иначе би се основавал на комбинации от две концепции (например форми и цветове).
Това дава възможност да се работи отделно върху две отделни йерархии — абстракция и имплементация. Двама различни разработчици могат да правят промени, без да навлизат в детайлите на codeа на другия.
Той намалява свързването между класовете — единственото място, където двата класа са свързани, е мостът (т.е. полето Color color).
Недостатъци на модела на моста:
В зависимост от конкретната ситуация и цялостната структура на даден проект, това може да повлияе отрицателно на производителността на програмата (например, ако трябва да инициализирате повече обекти).
Това прави codeа по-малко четлив поради необходимостта от превключване между двата класа.
Разлика от модела на стратегията
Моделът на моста често се бърка с друг модел на проектиране - стратегия. И двата използват композиция (въпреки че използвахме агрегиране в примера с фигури и цветове, моделът Bridge също може да използва композиция), делегирайки работа на други обекти. Но между тях има разлика и тя е огромна. Стратегическият модел е поведенчески модел: той решава напълно различни проблеми. Стратегията позволява размяната на алгоритми, докато мостът разделя абстракцията от имплементациите, за да избира между различни имплементации. С други думи, за разлика от стратегията, мостът се прилага към цели обекти or йерархични структури. Моделът на мост може да бъде добро оръжие в арсенала на разработчика. Основното нещо е да идентифицирате ситуациите, в които си струва да го използвате, и да разпознаете кога е подходящ друг модел.
Тук можете да видите две независими структури, които могат да бъдат модифицирани, без да засягат функционалността една на друга. В нашия случай:
GO TO FULL VERSION