Фабричный образец по своей сути не является нарушителем OCP .
Это зависит от того, как вы продолжите поведение Complex.
Если для поддержки создания новых типов объекта Complex требуется Complex, и вы решили изменить Complex, добавив новые fromX методы, добавленные для их поддержки, то это означает, что Complex становится нарушителем OCP , потому что Complex должен быть повторно открыт для модификации:
class Complex
{
public static Complex fromCartesian(double real, double imag) {
return new Complex(real, imag);
}
public static Complex fromPolar(double modulus, double angle) {
return new Complex(modulus * cos(angle), modulus * sin(angle));
}
//class opened for modification
public static Complex fromOtherMeans(String x , String y) {
return new Complex(x, y);
}
}
Вы можете перенести эту проблему в какой-нибудь текстовый файл или файл свойств, чтобы избавить себя от необходимости изменять класс Java, но это не мешает вам писать дополнительную логику в этой области решение для поддержки новых типов Complex.
В зависимости от использования Complex в вашем дизайне (как различаются различные типы? Как вы их используете?), Есть несколько альтернативных вариантов, которые могут хорошо подойти.
Одной из таких OCP дружественных альтернатив является подкласс Complex для предоставления дополнительных заводских методов. Подкласс - простейшая иллюстрация того, как Complex расширяется, но не изменяется.
Другой OCP дружественной альтернативой изменению Complex в этом случае является Pattern Decorator . Постоянное украшение Complex возможностью создавать новые варианты Complex соответствует OCP, поскольку Complex не изменяется, а расширяется за счет добавления новых функций.
Третья альтернатива может состоять в изменении структуры Complex, чтобы ее расчет обеспечивался составом. Это откроет вам возможность использовать шаблон стратегии , чтобы различать различные варианты поведения Complex.
Суть шаблона Factory в том, что он помогает контекстному коду уважать OCP . Можно использовать один из методов, описанных выше, чтобы остаться на правой стороне OCP с их классом Factory, но ваши коллеги, вероятно, один раз взглянут на график объектов, поставят под сомнение целесообразность граф объектов на одной фабрике и упрощение обратно на одну фабрику, что возвращает вас к первому примеру.
В таких случаях, вместо того, чтобы пытаться изменить свою реализацию шаблона Factory для соблюдения принципов SOLID , подумайте, почему вы используете его вообще .