Здравствуйте, Максим Рогожин, Вы писали:
МР>Здравствуйте, ylem, Вы писали:
Y>>Только не со стороны реализации, а со стороны интерфейса. МР>Можете пояснить?
В тех источниках, которые я видел, high cohesion объясняется со стороны реализации. Как, наприме, тут обяснение начинают с того, что
One of the methods, Discharge(), lacks cohesion because it doesn't touch any of the class's private members.
Здравствуйте, Максим Рогожин, Вы писали:
МР>Привет, МР>подскажите, пожалуйста, чем КОНКРЕТНО плохо НЕ следовать этому принципу? Ну вот допустим наш интерфейс содержит две группы методов — каждая группа методов относится к отдельной функциональности. Чем конкретно плох этот интерфейс?
Логично, чтобы был один интерфейс, унаследованный от двух. В каждом интерфейсе содержалась бы своя группа методов. А лучше сразу наследоваться от двух интерфейсов при необходимости, без лишнего 3-го.
МР>Имеет ли это отношение к зацеплению или связности (принципы GRASP)?
МР> интерфейс содержит две группы методов.... Чем конкретно плох этот интерфейс?
Очевидно же, если эти штуки могут реализовываться отдельно, сделать это не получится.
Ну и клинетам, котороым нужна только половина интерфейса, все равно придется реализовывать и предоставлять его весь.
МР>Имеет ли это отношение к зацеплению или связности (принципы GRASP)?
Имхо относится очень. Только не со стороны реализации, а со стороны интерфейса.
Привет,
подскажите, пожалуйста, чем КОНКРЕТНО плохо НЕ следовать этому принципу? Ну вот допустим наш интерфейс содержит две группы методов — каждая группа методов относится к отдельной функциональности. Чем конкретно плох этот интерфейс?
Имеет ли это отношение к зацеплению или связности (принципы GRASP)?
Здравствуйте, Максим Рогожин, Вы писали:
МР>Привет, МР>подскажите, пожалуйста, чем КОНКРЕТНО плохо НЕ следовать этому принципу? Ну вот допустим наш интерфейс содержит две группы методов — каждая группа методов относится к отдельной функциональности. Чем конкретно плох этот интерфейс?
МР>Имеет ли это отношение к зацеплению или связности (принципы GRASP)?
А что хорошего? У нас два разных факта собраны в одном месте. Если нам захотелось изменить логику одной группы методов, то легко можно будет сломать работу другой группы методов, если к одной группе методов нам захотелось добавить еще один метод, то это затронет все классы которые реализуют этот интерфейс, даже если они его не используют, а при реализации оставляют пустое тело метода.
Здравствуйте, Максим Рогожин, Вы писали:
МР>Привет, МР>подскажите, пожалуйста, чем КОНКРЕТНО плохо НЕ следовать этому принципу? Ну вот допустим наш интерфейс содержит две группы методов — каждая группа методов относится к отдельной функциональности. Чем конкретно плох этот интерфейс?
Чем меньше знает клиент о том, кого он вызывает — тем лучше. У программиста клиента не будет соблазна вызвать метод, который ему не нужен, а у программиста сервера будет больше возможностей в расширении функционала двух серверных интерфейсов, чем одного (логично, что вероятность затронуть только один интерфейс выше, соответственно и проще с регрессом).
МР>подскажите, пожалуйста, чем КОНКРЕТНО плохо НЕ следовать этому принципу? Ну вот допустим наш интерфейс содержит две группы методов — каждая группа методов относится к отдельной функциональности. Чем конкретно плох этот интерфейс?
Плох тем, что нельзя реализовать только одну из двух функциональностей.
При использовании могут появиться дополнительные зависимости.
МР>Имеет ли это отношение к зацеплению или связности (принципы GRASP)?
Нужно боле внимательно смотреть, на то, что это за методы.
Скорее всего нарушает принцип Low Coupling.
Точно имеет отношение к принципам SOLID. Нарушает Interface Segregation Principle.
