Сообщение Re[3]: бессмысленные интерфейсы от 18.02.2022 14:10
Изменено 18.02.2022 14:17 AlexGin
Re[3]: бессмысленные интерфейсы
Здравствуйте, Codealot, Вы писали:
C>Публичные методы — вверх. Всё.
C>И это все равно не тот случай.
Различать всё-таки следует понятия: класс и модуль:
Класс — может выступать элементом внутренней структуры.
Его публичные методы — вполне возможно это внутренние шестерёнки,
оставленные открытыми только для работы с объектами этого класса его "начальниками" (клиентами).
Никто другой не работает с этим классом. Большинству окружающих даже не важно, что эти методы public.
В терминологии C++ есть понятие friend. Иногда я даже пользуюсь этим, нарушая принцыпы ООД.
То есть: публичные методы класса — не факт, что являются входами/выходами всго модуля (или даже подсистемы).
Чего уже НЕ СКАЖЕМ об интерфейсе: здесь методы именно определяющие взаимодействие модуля с внешним миром.
Они обязаны быть максимально независимыми от внутренней реализации. Простой "публичностью" здесь уже не обойтись.
C>Публичные методы — вверх. Всё.
C>И это все равно не тот случай.
Различать всё-таки следует понятия: класс и модуль:
Класс — может выступать элементом внутренней структуры.
Его публичные методы — вполне возможно это внутренние шестерёнки,
оставленные открытыми только для работы с объектами этого класса его "начальниками" (клиентами).
Никто другой не работает с этим классом. Большинству окружающих даже не важно, что эти методы public.
В терминологии C++ есть понятие friend. Иногда я даже пользуюсь этим, нарушая принцыпы ООД.
То есть: публичные методы класса — не факт, что являются входами/выходами всго модуля (или даже подсистемы).
Чего уже НЕ СКАЖЕМ об интерфейсе: здесь методы именно определяющие взаимодействие модуля с внешним миром.
Они обязаны быть максимально независимыми от внутренней реализации. Простой "публичностью" здесь уже не обойтись.
Re[3]: бессмысленные интерфейсы
Здравствуйте, Codealot, Вы писали:
C>Публичные методы — вверх. Всё.
C>И это все равно не тот случай.
Различать всё-таки следует понятия: класс и модуль:
Класс — может выступать элементом внутренней структуры.
Его публичные методы — вполне возможно это внутренние шестерёнки,
оставленные открытыми только для работы с объектами этого класса его "начальниками" (клиентами).
Никто другой не работает с этим классом. Большинству окружающих даже не важно, что эти методы public.
В терминологии C++ есть понятие friend. Иногда я даже пользуюсь этим, нарушая принцыпы ООД.
То есть: публичные методы класса — не факт, что являются входами/выходами всго модуля (или даже подсистемы).
Чего уже НЕ СКАЖЕМ об интерфейсе: здесь методы именно определяющие взаимодействие модуля с внешним миром.
Они обязаны быть максимально независимыми от внутренней реализации. Простой "публичностью" здесь уже не обойтись.
P.S. Вот поэтому, реализация (даже если и единичная) нашего модуля ИМХО заслуживает наличия собственного интерфейса.
Это, казалось бы, усложнение — делает понимание кодов проекта проще и быстрее. Оно экономит силы и время (в том числе даже и
самому автору разработки, когда по воле случая он раскроет свои же коды 5-ти летней давности).
C>Публичные методы — вверх. Всё.
C>И это все равно не тот случай.
Различать всё-таки следует понятия: класс и модуль:
Класс — может выступать элементом внутренней структуры.
Его публичные методы — вполне возможно это внутренние шестерёнки,
оставленные открытыми только для работы с объектами этого класса его "начальниками" (клиентами).
Никто другой не работает с этим классом. Большинству окружающих даже не важно, что эти методы public.
В терминологии C++ есть понятие friend. Иногда я даже пользуюсь этим, нарушая принцыпы ООД.
То есть: публичные методы класса — не факт, что являются входами/выходами всго модуля (или даже подсистемы).
Чего уже НЕ СКАЖЕМ об интерфейсе: здесь методы именно определяющие взаимодействие модуля с внешним миром.
Они обязаны быть максимально независимыми от внутренней реализации. Простой "публичностью" здесь уже не обойтись.
P.S. Вот поэтому, реализация (даже если и единичная) нашего модуля ИМХО заслуживает наличия собственного интерфейса.
Это, казалось бы, усложнение — делает понимание кодов проекта проще и быстрее. Оно экономит силы и время (в том числе даже и
самому автору разработки, когда по воле случая он раскроет свои же коды 5-ти летней давности).