Comments 7
Открыть для себя наследование может? В том же примере для картинок просто напрашиваются UserImage и OfferImage отнаследованные от базового Image.
В том-то и дело, что наследование тут не поможет, так как надо положить базовый Image в еще какой-то модуль. Просто в отдельном модуле будет лежать уже базовый класс Image вместо конкретного класса.
В моем примере property только добавлялись, но они могут и удалятся. В таком случае придется удалять или делать nullable property в базовом классе. В итоге объекты вообще могут разойтись и у них не будет ни одного общего property. И это нормально. Так как это изначально по логике - абсолютно разные объекты, предназначенные для разных фичей. Просто в определенный момент они были одинаковы. В итоге базовый Image может быть вообще удален, а вот связи между модулями останутся и с ними придется разбираться. Поэтому проблема и бъёт, по большей части, по многомодульным проектам.
Посыл статьи как раз был в том, что не стоило пытаться их логически объединять. Неважно, просто используя один и тот же объект или прибегая к наследованию. То, что объекты выглядят одинаково вовсе не значит, что этот один и тоже же объект.
Похоже на вариацию принципа Лисковой, не наследовать прямоугольник от квадрата. Задавать вопрос : эти объекты действительно являются одной сущностью или они просто похожи ?
Забавно, джунов на собеседовании обычно такое спрашиваем. Очень надеясь услышать, что наследование нужно «когда есть общая абстракция», а не «когда есть общий код».
Но тут у человека другая проблема, как я понял. Он ставит под сомнение, полезность выделения абстракции, между модулями, аргументируя тем, что сложность архитектуры начинает перевешивать пользу, которую эта абстракция с собой несёт. И в этом даже есть доля здравого смысла.
Но я бы, в таком случае, усомнился в корректности разбиения приложения на модули. Если же архитектура корректна, то предложение автора, выделять некоторую абстракции в отдельный модуль («группировка по общему признаку»), звучит вполне здраво. Такие высокоуровневые абстракции выделять сложно. И заниматься этим должен человек, имеющий соответсвующий уровень, тот кто отвечает за архитектуру проекта, а не просто случайный разработчик. Когда абстракция выделена грамотно, то у других разработчиков не будет сильного желания поломать ее.
Самое простое правило - правило 3. Выносим класс Image в общий, только если у на есть 3 одинаковых требования (2 мало из-за шанса конвергенции). Тут Interface segregation principle из солид как раз подталкивает "ориентироваться в тысяче полупустых модулей". Но это работает только с хорошей автоматизацией процессов.
Тема интересная, именно потому, что универсального решения нет. В разных ситуациях использовали разные методы, основываясь на попытке предугадать куда тот или иной кусок будет расти. Если было подозрение, что дальше различий станет больше, то это просто временная схожесть - нет общей абстракции. Если нет думали, что эволюция сблизит, то создавали базу и переиспользовали.Тут главное не оставлять решения на разработчика. Нужен тот, кто хорошо знает текущую кодовую базу и понимает куда это движется - архитектор или типа того.
Я не совсем понимаю, что у вас включает в себя модульность, но сам процесс переиспользования (code reuse) кода и абстракций можно выстроить по разному. Иногда это просто оффлайн копия (притворимся, что это не наш код и возьмем к себе копию, пусть даже она не будет дальше обновляться - тупо copy/paste), иногда вызов API (нам очень важно, чтоб всё похожее всегда работало одинаково и на одной версии, а время вызова не критично).
Отличная статья. Сам сталкивался с такой проблемой. Но пока не нашёл хорошего решения. Такая проблема возникает уже на большом проекте - у меня пока небольшой опыт работы с большими проектами.
Ситуация с Offer'ом решается новым классом EditOffer, в котором все поля будут nullable и который будет иметь возможность конвертироваться в/из Offer'а. Такими образом получится, что только у экранов создания/редактирования будет доступ к EditOffer'у, а у всего остального приложения только к Offer'у
Конвергенция в многомодульном приложении