Go, расширение DTO класса для принимающего аргумента метода интерфейса?

Question

[P747]

Подскажите, можно ли в Go реализовать аналог следующего кода на PHP?

<?php

declare(strict_types=1)

interface ActivationRepository
{
    public function tariffActivation(TariffActivationDto $dto): TariffActivationResponseDto;
}

class TariffActivationDto
{
	public string $id = '';
}

final class TariffActivation2Dto extends TariffActivationDto
{
	public string $code = '';
}

class TariffActivationResponseDto
{
}

final class TariffActivationResponse2Dto extends TariffActivationResponseDto
{
}

class TestRepository implements ActivationRepository
{
	public function tariffActivation(TariffActivationDto $dto): TariffActivationResponse2Dto
	{
		var_dump($dto);
		
		return new TariffActivationResponse2Dto();
	}
}

(new TestRepository())->tariffActivation((new TariffActivation2Dto()));

Суть в том, чтобы можно было подавать в метод tariffActivation, расширенные DTO, удовлетворяя интерфейсу, который используется между слоями.

Comments

[Александр Павлюк]

Можете пояснить, что этот код на пхп делает?

[P747]

Александр Павлюк, Пример наследования, нашел для Go https://github.com/MaksimDzhangirov/oop-go/blob/ma... как это можно реализовать

[Александр Павлюк]

P747, в Го нет наследования, есть только композиция (встраивание) и она работает несколько по-другому. Не советую пытаться нести паттерны других языков в Го. Лучше всего писать так, как среди гошников принято.

Считаю, что в приведенной статье показан антипаттерн (включая способ именования интерфейсов, в Го так не делают). Интерфейсы в Го следует использовать только для устранения связанности кода и ограниченно — для полиморфизма. Не пытайтесь через них костылить наследование, получится не очень и другим людям будет сложнее понимать код.

[P747]

Не советую пытаться нести паттерны других языков в Го

И как тогда достигать необходимого уровня абстракции, в той же самой чистой архитектуре и т.д.? Ведь это все уже обкатаные решения в enteprise, и если их не применять те же паттерны корпоративные, GoF и т.д. будет кучу зависимостей и проект не будет гибкий

Answer 1

[P747]

https://github.com/MaksimDzhangirov/oop-go/blob/ma...

Answer 2

[dmitriy]

Здравствуйте. Параметры которые присущи каждому сервису стоит использовать в конструкторе репозитория, например на php это выглядит так:

class OzonEntityRepository impliments EntityRepositoryInterface{

public function __construct(private string $secretKey, private string $idClient)

}

public function userActivation(UserActivationDto $object){
//.........
}

Comments

[P747]

Добрый день, спасибо за ответ. Я имел ввиду другое, поля DTO. Забыл про extends в PHP, поправил вопрос, теперь интересно можно ли аналог такого кода реализовать в Go.

[dmitriy]

Я бы пересмотрел арх.решение для задачи потому что не совсем верно менять дто под разные репозитории, вот почему:
1. Репозиторий это реализация работы с хранилищем для доменной модели, в идеале вы должны откинуть всю инфраструктуру и реализовать поставленную задачу. Например активация пользователя: действие активировать, объект пользователь. Реализуете поведение используя ArrayRepository для теста например.
2. Далее подключаете инфраструктуру и реализуете уже работу репозитория с внешним хранилищем , поведение при этом не должно меняться.

3. Возможно вам нужно использовать TariffActivationDtoInterface вместо UserActivationDto
тогда public function tariffActivation(TariffActivationDtoInterface $dto): TariffActivationResponse2Dto
то есть поведение будет соблюдено + $dto может иметь свой функционал