История изменений
Исправление alysnix, (текущая версия) :
Где здесь, собственно, дизайн?
дизайн тут в том, что вы можете вынести работу с базовыми(общими) свойствами объектов в отдельный класс или функцию, инкапсулировать эту обработку там, и не морочится с совместимотью по указателю на эти обьекты. и все это зерокост.
как раз зерокост решения, дающие выразительные возможности для архитектуры софта и есть самые ценные. потому что всякой незерекост фигни можно придумать много.
Если опустить zero CPU cost, то это банальный полиморфизм.
полиморфизм не может быть банальным, иначе банальным можно обьявить все. это просто зерокост полиморфизм, аналогов которому еще поискать.
Аспект наследования реализации оказывает куда большее влияние не дизайн.
у кого как. любую сильную концепцию можно использовать во вред. в том ее сила. используйте на пользу.
критковать наследование за излишнюю зависимость реализаций, это все равно что критиковать вилку за то, что ею можно ткнуть в глаз.
само определение наследования не преполагает, что вы будете его использовать там, где не стоит.
если вам неохота, чтобы у вас наследники тырили реализацию из базового класса - обьявите методы приватными.
Исправление alysnix, :
Где здесь, собственно, дизайн?
дизайн тут в том, что вы можете вынести работу с базовыми(общими) свойствами объектов в отдельный класс или функцию, инкапсулировать эту обработку там, и не морочится с совместимотью по указателю на эти обьекты. и все это зерокост.
как раз зерокост решения, дающие выразительные возможности для архитектуры софта и есть самые ценные. потому что всякой незрекост фигни можно придумать много.
Если опустить zero CPU cost, то это банальный полиморфизм.
полиморфизм не может быть банальным, иначе банальным можно обьявить все. это просто зерокост полиморфизм, аналогов которому еще поискать.
Аспект наследования реализации оказывает куда большее влияние не дизайн.
у кого как. любую сильную концепцию можно использовать во вред. в том ее сила. используйте на пользу.
критковать наследование за излишнею зависимость реализаций, это все равно что критиковать вилку за то, что ею можно ткнуть в глаз.
само определение наследования не преполагает, что вы будете его использовать там, где не стоит.
если вам неохота, чтобы у вас наследники тырили реализацию из базового класса - обьявите методы приватными.
Исправление alysnix, :
Где здесь, собственно, дизайн?
дизайн тут в том, что вы можете вынести работу с базовыми(общими) свойствами объектов в отдельный класс или функцию, инкапсулировать эту обработку там, и не морочится с совместимотью по указателю на эти обьекты. и все это зерокост.
как раз зерокост решения, дающие выразительные возможности для архитектуры софта и есть самые ценные. потому что всякой незрекост фигни можно придумать много.
Если опустить zero CPU cost, то это банальный полиморфизм. полиморфизм не может быть банальным, иначе банальным можно обьявить все. это просто зерокост полиморфизм, аналогов которому еще поискать.
Аспект наследования реализации оказывает куда большее влияние не дизайн.
у кого как. любую сильную концепцию можно использовать во вред. в том ее сила. используйте на пользу.
критковать наследование за излишнею зависимость реализаций, это все равно что критиковать вилку за то, что ею можно ткнуть в глаз.
само определение наследования не преполагает, что вы будете его использовать там, где не стоит.
если вам неохота, чтобы у вас наследники тырили реализацию из базового класса - обьявите методы приватными.
Исходная версия alysnix, :
Где здесь, собственно, дизайн?
дизайн тут в том, что вы можете вынести работу с базовыми(общими) свойствами объектов в отдельный класс или функцию, инкапсулировать эту обработку там, и не морочится с совместимотью по указателю на эти обьекты. и все это зерокост.
как раз зерокост решения, дающие выразительные возможности для архитектуры софта и есть самые ценные. потому что всякой незрекост фигни можно придумать много.
Если опустить zero CPU cost, то это банальный полиморфизм. полиморфизм не может быть банальным, иначе банальным можно обьявить все. это просто зерокост полиморфизм, аналогов которому еще поискать.
Аспект наследования реализации оказывает куда большее влияние не дизайн.
у кого как. любую сильную концепцию можно использовать во вред. в том ее сила. используйте на пользу.
критковать наследование за излишнею зависимость реализаций, это все равно что критиковать вилку за то, что ей можно ткнуть в глаз.
само определение наследования не преполагает, что вы будете его использовать там, где не стоит.
если вам неохота, чтобы у вас наследники тырили реализацию из базового класса - обьявите методы приватными.