Есть набор классов-конверторов: они берут объект одного типа, скажем А, и конвертируют его в сторку.
Также они читают строку и конвертируют его в объект другого типа, скажем, B.
К примеру, один из конверторов

public MyConverter implements Converter {
public String convertTo(A obj) {
//implementation
}

public B convertTo(String obj) {
//implementation
}

}

И таких классов много, и все они имеют два таких метода, только конвертируют разные объекты.

Как лучше задизайнить это в рамках ООП? Может разделить по одному методу на класс?

А>Как лучше задизайнить это в рамках ООП? Может разделить по одному методу на класс?

конечно, причем достаточно одного класса, String это тоже класс:
public T convertTo(S obj)

в один класс можно поместить пару типа serialize/deserialize или marshall/unmarshall, но тогда без B: A->String и String->A

Здравствуйте, Аноним, Вы писали:
А>И таких классов много, и все они имеют два таких метода, только конвертируют разные объекты.
А>Как лучше задизайнить это в рамках ООП? Может разделить по одному методу на класс?
я бы оставил как есть, только бы поменял название на Serializer

А>И таких классов много, и все они имеют два таких метода, только конвертируют разные объекты.
А>Как лучше задизайнить это в рамках ООП? Может разделить по одному методу на класс?

А есть ли смысл в этих сериализаторах вообще? Или в них помимо методов convertTo будет еще какая-то функциональность?
Не проще ли просто объявить такие методы (см. ниже) в самих классах A, B и пр.

class A {
   static public A fromString(String s) {}
   public String toString() {}
   static public String toString(A a) {}
}

Здравствуйте, Аноним, Вы писали:

А>Как лучше задизайнить это в рамках ООП? Может разделить по одному методу на класс?

Расскажите побольше как эти оба метода будут использоваться? Для чего надо перегонять объект в строку и обратно? В каком формате будет оно будет хранится в строке?
Хотелось бы чуть лучше понимать контекст, чтобы решение было более взвешенным.

Здравствуйте, Аноним, Вы писали:
А>Как лучше задизайнить это в рамках ООП?

object Main {def main(args: Array[String]): Unit = {
  //...
  val a = new A
  println(a)  ///i object 'a'
  val s = a.serialize
  println(s)  ///i serialize object 'a'
  //...
  val b = new B("i serialize object 'b'")
  println(b)  ///i object 'b'
  //...  
}}

class A {
  def serialize:String = {/*serialization A implementation*/ "i serialize object 'a'"}
  //...
  override def toString:String = "i object 'a'"
}       
       
class B {
  def this(s:String) = {this(); /*deserialization B implementation*/}  //<-- override constructor
  //...
  override def toString:String = "i object 'b'"
}

Здравствуйте, Аноним, Вы писали:

А>Есть набор классов-конверторов: они берут объект одного типа, скажем А, и конвертируют его в сторку.
То есть для одного и того же типа А есть множество разных конверторов в строку?
Почему это классы? Т.е. есть ли какое-то нетривиальное состояние у класса-конвертора, которое он использует или модифицирует в процессе конвертации?
Если нет — то достаточно обходиться статическими методами, не порождая никаких экземпляров.

А>Также они читают строку и конвертируют его в объект другого типа, скажем, B.
Что значит "также"? Есть ли какая-то специфика в конверсии из строки в B, которая связана со спецификой конверсии из А в строку? Есть ли у конверторов в В состояние, которое зависит от результатов конверсии А в строку?

А>К примеру, один из конверторов

А>public MyConverter implements Converter {
А> public String convertTo(A obj) {
А> //implementation
А> }

А> public B convertTo(String obj) {
А> //implementation
А> }

А>}

А>И таких классов много, и все они имеют два таких метода, только конвертируют разные объекты.
Что значит "разные"? У каждого конвертера типы А и В — свои?
А>Как лучше задизайнить это в рамках ООП? Может разделить по одному методу на класс?
Вопросы дизайна классов невозможно решить, не имея на руках сценариев их использования. Нужен код, который будет эти конвертеры использовать.