Мы разделили наше приложение так, чтобы пакет A обрабатывал данные из одного внешнего источника и пакета B из другого. В обоих случаях нам нужно создать объект домена и для этого сделать "Трансформатор".
Итак, у меня есть com.foo.bar.a.ThingTransformer и com.foo.bar.b.ThingTransformer
Я подозреваю, что это плохая практика, но хочу посмотреть, что думают хорошие люди SO.
Я бы не сказал, что это всегда плохая практика, но это как-то от запах кода.
Если оба класса делают разные вещи, то почему у них нет разных имен?
если оба класса выполняют одно и то же, то почему существуют два класса?
С практической точки зрения он может стать очень раздражающим, если эти два класса когда-либо нуждаются в ссылке в одном классе: вам придется использовать FQN для одного из них (для ясности, вероятно, было бы лучше использовать его для обоих случаев). Если эти два класса находятся в достаточно разных частях кода, на которые они не будут ссылаться из одного и того же кода, тогда практическая проблема не так уж плоха.
Не совсем плохая практика, так как во многих доменах есть аналогичная терминология, поэтому вы будете иметь те же имена. С другой стороны, если оба находятся в одном домене, но просто разные реализации, вы можете (каким-то образом) указать специфику реализации в имени.
Очень уродливым было бы, если бы вы использовали оба в одном исходном файле, в этом случае вы должны использовать полное имя для хотя бы одного.
Примеры:
java.util.List
java.awt.List
указать реализацию в названии: java.util.ArrayList java.util.LinkedList
Это хорошо. Именно поэтому, по дизайну, разные пакеты имеют разные пространства имен.
В этом нет ничего плохого, так как вряд ли вы будете использовать оба класса вместе в одном коде. Дублирование отличия a/b от пакета во всех именах классов было бы хуже.
Вы должны решить, является ли это более полезным или более запутанным. Вы можете получить ту же проблему с использованием похожих имен в том же пакете, где разница неясна.
Примером более запутанного, чем полезного, является что-то вроде
com.sun.corba.se.internal.Interceptors.PIORB extends
com.sun.corba.se.internal.POA.POAORB which extends
com.sun.corba.se.internal.iiop.ORB which extends
com.sun.corba.se.impl.orb.ORBImpl which extends
com.sun.corba.se.spi.orb.ORB which extends
com.sun.corba.se.org.omg.CORBA.ORB which extends
org.omg.CORBA_2_3.ORB which extends
org.omg.CORBA.ORB