SP
Ну часто каплинг/кохижн противопоставляют как плохое/хорошее
Нет, не противопоставляют
Size: a a a
2021 March 13
SP
В том же grasp тебе говорят что кохижен должен быть высокий а каплинг низкий. Ты не можешь их противопоставлять
SP
Это две разные характеристики применимые к модулям которые должны уравновешивать друг друга
ЕР
Вот интересно как ты к этому приходишь, скорее всего тут будет ответ на вопрос где ты чёт напутал
Ну потому что "плохие" виды кохижена повышают каплинг
SP
Каплинг это по сути про вероятность что потрогав зависимость y ты сломаешь зависимый от него x.
Низкий каплинг - низкая вероятность. Или низкие риски.
Низкий каплинг - низкая вероятность. Или низкие риски.
SP
Ну потому что "плохие" виды кохижена повышают каплинг
Да но ты можешь сделать высокий каплинг + высокий кохижен.
SP
Каплинг это по сути про вероятность что потрогав зависимость y ты сломаешь зависимый от него x.
Низкий каплинг - низкая вероятность. Или низкие риски.
Низкий каплинг - низкая вероятность. Или низкие риски.
Виды каплинга по сути про то а что именно между модулями может поменяться
ЕР
Да но ты можешь сделать высокий каплинг + высокий кохижен.
Только если случайный кохижн считать кохиженом кмк
ЕР
На счёт логического не уверен, наверное я сам @GDXbsv запутал, по мне логически объединённые штуки должны быть чем-то универсальным что можно реюзать, иначе получается случайный кохижен
SP
Только если случайный кохижн считать кохиженом кмк
Я повторюсь. Кохижен внутри а каплинг между. Твоя проблема видимо что ты пытаешься это как-то сароецировать на одном уровне
К
На счёт логического не уверен, наверное я сам @GDXbsv запутал, по мне логически объединённые штуки должны быть чем-то универсальным что можно реюзать, иначе получается случайный кохижен
ЕР
Я повторюсь. Кохижен внутри а каплинг между. Твоя проблема видимо что ты пытаешься это как-то сароецировать на одном уровне
Ну если мы логику работы с юзером всю запихнём в класс юзера, она будет объединена просто тем что она в одном классе
SP
На счёт логического не уверен, наверное я сам @GDXbsv запутал, по мне логически объединённые штуки должны быть чем-то универсальным что можно реюзать, иначе получается случайный кохижен
Не, логический кохижен это чуть лучше случайного. Там ещё между ним и функциональным штуки три других видов
ЕР
Она вряд ли друг от друга по факту будет зависеть
SP
Она вряд ли друг от друга по факту будет зависеть
Зато весь остальной код будет зависеть от юзера и ты получишь год обджект
ЕР
Зато весь остальной код будет зависеть от юзера и ты получишь год обджект
Да, и это про высокий каплинг
ЕР
Если считать User модулем то получится что внутри него куча несвязного(low cohesion) функционала, зато много других модулей зависимых от User
SP
Если считать User модулем то получится что внутри него куча несвязного(low cohesion) функционала, зато много других модулей зависимых от User
Да, а теперь попробуй придумать вариант при котором у тебя более высокий уровень кохижена но все так же высокая связанность
SP
Или другой пример - внутри модуля utils у нас низкий каплинг и сам модуль обладает низким кохиженом.
ЕР
Хм. Я подумал что какая-нибудь огромная процедура, но нет, там получается модульности нету просто