GAMEDEV_ARCHITECTURE Telegram 31
Ранее я писал о том как полезно знание шаблонов проектирования, и как оно все может поменять.

Один из ключевых шаблонов, которые изменили мое мировоззрение в ООП мире был Dependency Injection. И это поистине великолепное решение.

Если вы не знаете что это за шаблон, то самое время это исправить.

Конечно же это не панацея. И многие из разработчиков думают, что если мы заинжектили зависимость, то этого достаточно, чтобы снизить зацепление (coupling) кода. Но это не совсем так. Нужно хорошо понимать мотивацию данного подхода и проблемы которые он решает.

Стандартный подход для устранения зависимостей — использование интерфейсов. Интерфейс позволяет отвязаться от конкретной реализации. А это дает свободу дейсвий и гибкость. Но подход должен быть конзистентным на всех слоях архитектуры.

Представьте, что мы заинжектили интерфейс для взаимодействия с базой данных


void PerformSomeQuery(IDb db)
{
db.Exec("INSERT INTO blabla VALUES('bla', 'bla')");
}


Но что если метод Exec этого интерфейса выглядит следующим образом:


interface IDb
{
void Exec(SQLString query);
}


Проблема данного кода в том, что интерфейс вводит новую зависимость: SQLString — некий внутренний тип для IDb. Это большая проблема, так как имплементировать интерфейс IDb, не привязываясь к внутренним типам, не представляется возможным. Что, по сути, делает данный интерфейс практически бесполезным.

В статье DIP in the Wild Мартин говорит о том, что

Высокоуровневый код не должен зависеть от низкоуровневых деталей

Чтобы избавить пользователя от головной боли, автор интерфейса должен так же использовать интерфейс


interface IDb
{
void Exec(ISQLString query);
}


А SQLString, в свою очередь, должен имплементировать ISQLString. Тогда пользователь класса сможет реализовать удобные для него имплементации, и не привносить никаких дополнительных зависимостей.

Если это возможно, то лучше ограничиваться стандартными типами, и, например, заменить ISQLString на стандартный string.

В статье Мартина вы сможете найти много других интересных примеров и решений распространенных проблем.

Если вас интересуют подобные проблемы и тема проектирования архитектуры приложения, то очень советую книгу Clean Architecture



tgoop.com/gamedev_architecture/31
Create:
Last Update:

Ранее я писал о том как полезно знание шаблонов проектирования, и как оно все может поменять.

Один из ключевых шаблонов, которые изменили мое мировоззрение в ООП мире был Dependency Injection. И это поистине великолепное решение.

Если вы не знаете что это за шаблон, то самое время это исправить.

Конечно же это не панацея. И многие из разработчиков думают, что если мы заинжектили зависимость, то этого достаточно, чтобы снизить зацепление (coupling) кода. Но это не совсем так. Нужно хорошо понимать мотивацию данного подхода и проблемы которые он решает.

Стандартный подход для устранения зависимостей — использование интерфейсов. Интерфейс позволяет отвязаться от конкретной реализации. А это дает свободу дейсвий и гибкость. Но подход должен быть конзистентным на всех слоях архитектуры.

Представьте, что мы заинжектили интерфейс для взаимодействия с базой данных


void PerformSomeQuery(IDb db)
{
db.Exec("INSERT INTO blabla VALUES('bla', 'bla')");
}


Но что если метод Exec этого интерфейса выглядит следующим образом:


interface IDb
{
void Exec(SQLString query);
}


Проблема данного кода в том, что интерфейс вводит новую зависимость: SQLString — некий внутренний тип для IDb. Это большая проблема, так как имплементировать интерфейс IDb, не привязываясь к внутренним типам, не представляется возможным. Что, по сути, делает данный интерфейс практически бесполезным.

В статье DIP in the Wild Мартин говорит о том, что

Высокоуровневый код не должен зависеть от низкоуровневых деталей

Чтобы избавить пользователя от головной боли, автор интерфейса должен так же использовать интерфейс


interface IDb
{
void Exec(ISQLString query);
}


А SQLString, в свою очередь, должен имплементировать ISQLString. Тогда пользователь класса сможет реализовать удобные для него имплементации, и не привносить никаких дополнительных зависимостей.

Если это возможно, то лучше ограничиваться стандартными типами, и, например, заменить ISQLString на стандартный string.

В статье Мартина вы сможете найти много других интересных примеров и решений распространенных проблем.

Если вас интересуют подобные проблемы и тема проектирования архитектуры приложения, то очень советую книгу Clean Architecture

BY GameDev Architecture


Share with your friend now:
tgoop.com/gamedev_architecture/31

View MORE
Open in Telegram


Telegram News

Date: |

Your posting frequency depends on the topic of your channel. If you have a news channel, it’s OK to publish new content every day (or even every hour). For other industries, stick with 2-3 large posts a week. But a Telegram statement also said: "Any requests related to political censorship or limiting human rights such as the rights to free speech or assembly are not and will not be considered." The SUCK Channel on Telegram, with a message saying some content has been removed by the police. Photo: Telegram screenshot. During the meeting with TSE Minister Edson Fachin, Perekopsky also mentioned the TSE channel on the platform as one of the firm's key success stories. Launched as part of the company's commitments to tackle the spread of fake news in Brazil, the verified channel has attracted more than 184,000 members in less than a month.
from us


Telegram GameDev Architecture
FROM American