Ответ
GRASP (General Responsibility Assignment Software Patterns) — это набор принципов для распределения обязанностей между классами и объектами в ООП. Основные паттерны:
- Information Expert — назначать обязанность классу, который владеет необходимой информацией.
- Creator — класс должен создавать объекты, которые он содержит или агрегирует.
- Controller — использовать промежуточный класс для обработки системных событий.
- Low Coupling — минимизировать зависимости между классами.
- High Cohesion — класс должен выполнять одну четкую задачу.
Пример Creator:
class Order {
constructor() {
this.items = [];
}
addItem(product) {
const item = new OrderItem(product); // Order создаёт OrderItem
this.items.push(item);
}
}GRASP помогает проектировать гибкие и поддерживаемые системы.
Ответ 18+ 🔞
Слушай, а есть такая штука — GRASP. Ну, не то чтобы хватать, хотя по сути так и есть. Это типа свод правил, как раздавать обязанности классам в этой вашей объектно-ориентированной хуйне, чтобы потом не было мучительно больно.
Вот смотри, основные принципы, их там дохуя, но главные:
-
Information Expert (Информационный эксперт). Это самый логичный, блядь. Если классу нужно принять решение или что-то посчитать — отдай эту почетную обязанность тому, у кого уже есть для этого все данные. Не заставляй одного лезть в жопу другого, если можно спросить у того, кто в теме. Просто же, ага?
-
Creator (Создатель). Кто должен плодить новые объекты? Да тот, кто их потом использует, содержит или ими рулит! Ну, представь: у тебя есть заказ (
Order). Логично, что он сам и будет создавать позиции в этом заказе (OrderItem), а не какой-то левый менеджер сбоку. Вот как это выглядит, епта:
class Order {
constructor() {
this.items = []; // Заказ содержит массив позиций
}
addItem(product) {
// А вот и Creator в деле: Order создаёт OrderItem, потому что он его потом хранить будет
const item = new OrderItem(product);
this.items.push(item);
}
}-
Controller (Контроллер). Это такой промежуточный мужик, который принимает все системные события (типа запросов от пользователя) и решает, кому их дальше перекинуть. Чтобы не засирать, блядь, интерфейс всей этой бизнес-логикой.
-
Low Coupling (Слабая связанность). Святое правило, ёпта! Классы должны быть по максимуму независимы друг от друга. Меньше знают друг о друге — меньше проблем, когда один нихуя не сработает и потянет за собой всех. Идеал — это как модули в космическом корабле: один ебнулся, а остальные летят дальше.
-
High Cohesion (Высокая связность). А это про то, что каждый класс должен заниматься своим, одним, четким делом. Не надо делать из класса "швейцарский нож", который и заказ обрабатывает, и в базу пишет, и письма шлет. Пусть лучше он один раз, но овердохуища хорошо делает. Иначе получится монстр, в котором через полгода ни черта не разберешь.
Вот эти все паттерны GRASP, они, по сути, и помогают не наделать архитектурного говна, а спроектировать систему, которую потом можно будет расширять, не переписывая всё с нуля и не материясь на предшественников. Хотя последнее, конечно, не гарантировано.