Есть порядка 8 классов, у которых 90% логики при сохранении одинаковая и 10% между собой отличается.
Классы: разные типы плав средств. Пвх лодка, катер и т.д.
Класс сохранения выглядит так для всех методов
CheckCondiitons(T item)
{
some code
calculateC(item);
some code
calculateE(item);
some code
}
calculateC, calculateE — специфичины для каждого класса, some code — Одинаковый везде
сейчас получается some code достаточно много кода, там код + вызовы других методов.
Из-за того что 8 классов, то самый простой вариант сделать 8 классов где будет одинаковый по сути код и отличаться просто calculateC, calculateE
Хочется избежать много одинакового кода.
Если это важно то проект .net core.
Смотрел на паттер Спецификация или может можно построить как-то expression tree или другие варианты?
Здравствуйте, busk, Вы писали:
B>Есть порядка 8 классов, у которых 90% логики при сохранении одинаковая и 10% между собой отличается. B>Классы: разные типы плав средств. Пвх лодка, катер и т.д.
B>Класс сохранения выглядит так для всех методов
B>
B>CheckCondiitons(T item)
B>{
B> some code
B> calculateC(item);
B> some code
B> calculateE(item);
B> some code
B>}
B>
B>calculateC, calculateE — специфичины для каждого класса, some code — Одинаковый везде
B>сейчас получается some code достаточно много кода, там код + вызовы других методов. B>Из-за того что 8 классов, то самый простой вариант сделать 8 классов где будет одинаковый по сути код и отличаться просто calculateC, calculateE
B>Хочется избежать много одинакового кода. B>Если это важно то проект .net core. B>Смотрел на паттер Спецификация или может можно построить как-то expression tree или другие варианты?
А так не получится: CheckCondiitons(T1 item), CheckCondiitons(T2 item) и т.д.?
Ну если только калькуляции отличаются, то сделать виртуальный калькулятор, конкретные калькуляторы наследовать от него. А в другом классе (где somecode) уже вызывать методы калькуляции с подсунутым конкретным калькулятором
B>CheckCondiitons(T item)
B>{
B> some code
B> calculateC(item);
B> some code
B> calculateE(item);
B> some code
B>}
B>
B>calculateC, calculateE — специфичины для каждого класса, some code — Одинаковый везде
B>Смотрел на паттер Спецификация или может можно построить как-то expression tree или другие варианты?
Что-то эти методы выглядят как из пушки по воробьям (или я чего-то не понял в условии задачи?)
Просто добавить в класс T виртуальные методы calculateC, calculateЕ — не вариант? Или они зависят не только от данных класса T, но и от каких-то внешних данных?
Или если это не подойдет — создать какой-нибудь базовый класс Calculator и 8 наследников от него со своей реализацией calculateC, calculateЕ?
Здравствуйте, busk, Вы писали:
B>Здравствуйте, BlackEric, Вы писали:
BE>>Здравствуйте, busk, Вы писали:
BE>>Можно в функцию передавать отличающийся метод.
B>поясните пожалуйста как это выглядить будет? не уловил мысль
B>то есть параметром в CheckCondiitons(T item, Func f) передали к примеру B> calculateC(item) а дальше просто внутри
B>
B> calculateC(T item)
B>{
B> if (T is restrictedClas)
B> return;
B> some code
B>}
B>
Здравствуйте, busk, Вы писали:
B>Есть порядка 8 классов, у которых 90% логики при сохранении одинаковая и 10% между собой отличается. B>Классы: разные типы плав средств. Пвх лодка, катер и т.д.
B>Класс сохранения выглядит так для всех методов
Эмм, я читаю эту фразу как "метод сохранения выглядит так для всех классов". B>
B>CheckCondiitons(T item)
B>{
B> some code
B> calculateC(item);
B> some code
B> calculateE(item);
B> some code
B>}
B>
B>calculateC, calculateE — специфичины для каждого класса, some code — Одинаковый везде
Вы описали канонический случай для паттерна Шаблонный метод.
B>сейчас получается some code достаточно много кода, там код + вызовы других методов. B>Из-за того что 8 классов, то самый простой вариант сделать 8 классов где будет одинаковый по сути код и отличаться просто calculateC, calculateE
Непонятно, зачем. B>Хочется избежать много одинакового кода.
Что мешает вам отнаследовать все эти 8 классов от базового класса "Плавсредство", устроенного примерно так:
public abstract class Плавсредство<T>
{
private void CheckConditions(T item)
{
some code
calculateC(item);
some code
calculateE(item);
some code
}
protected abstract void calculateC(T item);
protected abstract void calculateE(T item);
}
Тогда в классах, моделирующих конкретное пласредство, вам будет достаточно отнаследоваться от этого класса, и реализовать только методы calculateC и calculateE.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
А почему просто не передать calculateC, calculateE параметрами?
CheckCondiitons(T item, Action<T> one, Action<T> two)
{
some code
one(item);
some code
two(item);
some code
}
// classs Y
CheckCondiitons(item, CalculateA, calculateE)
// class Z
CheckCondiitons(item, CalculateB, calculateF)
