вы не конструктивно ведете беседу. Я не буду разводить демагогию. Хотите продолжить, перестаньте игнорировать факты и цепляться за аналогии, не относящиеся к сути вопроса. Докажите мне на примере известных принципов проектирования свою правоту, или я просто буду игнорировать вас, как некомпетентного в данном вопросе. (Я вам привел конкретику на примере SOLID, вы же просто вертите словами)
«В чертежах написано „самолет может летать“» != «чертеж умеет летать». Чертеж не отвечает и не должен отвечать за сам процесс полета, это не его функция, а значит этого метода в этом классе вообще быть не должно.
«Если более точно аналогию проводить, то чертеж это переменные класса, его состав, а методы это проектная документация.» Ну и как эта аналогия помогает понять, что вообще такое ООП. Я вот ход ваших мыслей совсем не улавливаю. А если у нас не самолеты, а люди. Что для людей такое: «проектная документация».
Примеры автора не проходят, к примеру, принципы SOLID, это довольно весомый аргумент в пользу того, что его архитектура неверная. Если вы хотите защитить его подход, то давайте не будем размышлять о том, как это сделано в мире реальном (это ни к чему не приводит), а ближе к программированию, плз.
мир сотворения кода резко отличается от мира реального. Дело не в том, что там где-то в реальности в характеристиках прописывается, что самолет летает. Дело в том, что летает в коде именно самолет. Это его зона ответственности. А вот чертеж летать не может, потому что это чертеж. С такими подменами понятий, ничего яснее не станет, тем более для студентов. Видите, вы ведь поддались, хотя пример автора статьи некорректен.
При прочтении возникают следующие вопросы:
1. Почему чертеж умеет летать
2. Почему чертеж располагает информацией о количестве пассажиров (ок, если это опечатка: что если несколько мест сломается? Нужно будет наследоваться?)
3. Какой практический толк от абстрактного класса ЧертежСамолета, если, очевидно, что «полет» будет принципиально разным не только для различных моделей, но и для различных объектов. Или мы все сводим к write(«самолет летит»);? Тогда не вижу разницы между этим и животными.
4. Не очень понятна зона ответственности класса: пассажирский самолет умеет здороваться с пассажирами. Это как? Может, все таки, этим занимается не самолет, а ответственный за это модуль (человек).
5. Странно, что это никто не заметил, но статическая переменная «аварийность»? Вы же в курсе должны быть, что статик переменные имеют одно значение для всех объектов класса. Плюс ко всему статик-методы и наследование работает не так, как вы ожидаете. Не знаю, как в жаве, вы на ней код приводите, но в C# нельзя вызывать статик метод у объекта, что очень логично, так как смысла в этом нет.
6. Ваше объяснение полиморфизма сможет понять только тот, кто уже прокрутил в голове, как это будет выглядеть в коде. Но проблема даже не в этом, как вы будете определять: может ли самолет сесть на данную полосу? Пытаться кастовать вниз по иерархии? Тогда в чем полиморфизм?
7. Просто наблюдение: студенты в университете очень ленивые и большинство вообще не знает, зачем учится. У них даже склад ума не у всех технический. Ваш пример пока от кошек и собак ушел не очень далеко, тогда вопрос: чем же он лучше, если априори более сложный для восприятия.
если про код с else, то это же не оптимизированный код. В Си мы не записывает какое-то число в переменную, поэтому компилятор и не делает таких смелых предположений. А вот с включенной оптимизацией вообще переходов не будет =)
В смысле, расчет идет на то, что тело обычно короткое? И то, что при опускании тела вниз, нужен дополнительный переход назад, это вообще не важно? Хммммм
Подозреваю, что автор считает, что для каждого фрагмента кода на Си есть некая «каноническая» трансляция в машкод x86, и с отключённой оптимизацией все компиляторы будут выдавать примерно одну и ту же «каноническую трансляцию».
нет, автор так не считает. Но рассматривать все и со всех сторон, еще и в одной статье, просто перебор.
если вы назовете компилятор, на котором будет принципиальная разница в коде для этих простейших примеров, я с удовольствием опишу эту разницу в следующей статье)
«Если более точно аналогию проводить, то чертеж это переменные класса, его состав, а методы это проектная документация.» Ну и как эта аналогия помогает понять, что вообще такое ООП. Я вот ход ваших мыслей совсем не улавливаю. А если у нас не самолеты, а люди. Что для людей такое: «проектная документация».
Примеры автора не проходят, к примеру, принципы SOLID, это довольно весомый аргумент в пользу того, что его архитектура неверная. Если вы хотите защитить его подход, то давайте не будем размышлять о том, как это сделано в мире реальном (это ни к чему не приводит), а ближе к программированию, плз.
1. Почему чертеж умеет летать
2. Почему чертеж располагает информацией о количестве пассажиров (ок, если это опечатка: что если несколько мест сломается? Нужно будет наследоваться?)
3. Какой практический толк от абстрактного класса ЧертежСамолета, если, очевидно, что «полет» будет принципиально разным не только для различных моделей, но и для различных объектов. Или мы все сводим к write(«самолет летит»);? Тогда не вижу разницы между этим и животными.
4. Не очень понятна зона ответственности класса: пассажирский самолет умеет здороваться с пассажирами. Это как? Может, все таки, этим занимается не самолет, а ответственный за это модуль (человек).
5. Странно, что это никто не заметил, но статическая переменная «аварийность»? Вы же в курсе должны быть, что статик переменные имеют одно значение для всех объектов класса. Плюс ко всему статик-методы и наследование работает не так, как вы ожидаете. Не знаю, как в жаве, вы на ней код приводите, но в C# нельзя вызывать статик метод у объекта, что очень логично, так как смысла в этом нет.
6. Ваше объяснение полиморфизма сможет понять только тот, кто уже прокрутил в голове, как это будет выглядеть в коде. Но проблема даже не в этом, как вы будете определять: может ли самолет сесть на данную полосу? Пытаться кастовать вниз по иерархии? Тогда в чем полиморфизм?
7. Просто наблюдение: студенты в университете очень ленивые и большинство вообще не знает, зачем учится. У них даже склад ума не у всех технический. Ваш пример пока от кошек и собак ушел не очень далеко, тогда вопрос: чем же он лучше, если априори более сложный для восприятия.
нет, автор так не считает. Но рассматривать все и со всех сторон, еще и в одной статье, просто перебор.