LINUX.ORG.RU

История изменений

Исправление user_id_68054, (текущая версия) :

Классы в крестах наглядный и стандартизированный инструмент, избегать их использования нет никакого смысла

если в Классах используется наследование — то как мне глядя на код метода класса понять — используется ли именно этот код или же он где-то там перегружен в наследнике? (просматривать каждого наслденика?)

[впрочем, уже чутьли не научно доказано что «наследование» это порочная практика — и об этом много кто говорил.. а в современных языках стараются вообще убрать «наследование» (на крайний случай заменить «наследование» на «примеси»)... так что тут я много говорить не будут и так всё ясно :)]

а если в классе НЕ используется наследование\перегрузка — то вообще какой тогда толк от такого класса? ну засунули группу функций под фигурные скобки и назвали не «функция» а «метод» и типа так стало круче? (в ООП это называется «инкапсуляция»)

а какой толк от инкапсуляции? :-)

как мне определить — должна ли очереная «функция» быть «методом», или же реализовать её обособленно всё-таки как «функцию»?.. где эта грань?

а парить себе мозги на тему protected\public и friend — зачем это было бы нужно, если бы вместо класса у нас просто была бы структура и внешние функции которые с ней работают? :-)

неужали программисту и времени-то своего деть некуда, кроме как думать на тему "как же я организую взаимодействие классов в своём коде?" (ответ: "ды ни как не организлвывай! просто наделай кучу функций и всё! при случае не забудь и передавать указатели на функции, в моменты когда нужно делегировать различные алгоритмы различным частям кода")

то есть я говорю о том что минимазилм в использовании классов — взят не из-за комплексов — а и из-за вполне практичных соображений :-)

ООП это когда данные (объекты) лежат в основе алгоритма (всё вертится вокруг объектив и их состояний).. а мне может быть больше нравится когда в основе алгоритма лежат функции а не данные :-) — психолог лечит такие случаи? :-)

Исправление user_id_68054, :

Классы в крестах наглядный и стандартизированный инструмент, избегать их использования нет никакого смысла

если в Классах используется наследование — то как мне глядя на код метода класса понять — используется ли именно этот код или же он где-то там перегружен в наследнике? (просматривать каждого наслденика?)

[впрочем, уже чутьли не научно доказано что «наследование» это порочная практика — и об этом много кто говорил.. а в современных языках стараются вообще убрать «наследование» (на крайний случай заменить «наследование» на «примеси»)... так что тут я много говорить не будут и так всё ясно :)]

а если в классе НЕ используется наследование\перегрузка — то вообще какой тогда толк от такого класса? ну засунули группу функций под фигурные скобки и назвали не «функция» а «метод» и типа так стало круче? (в ООП это называется «инкапсуляция»)

а какой толк от инкапсуляции? :-)

как мне определить — должна ли очереная «функция» быть «методом», или же реализовать её обособленно всё-таки как «функцию»?.. где эта грань?

а парить себе мозги на тему protected\public и friend — зачем это было бы нужно, если бы вместо класса у нас просто была бы структура и внешние функции которые с ней работают? :-)

неужали программисту и времени-то своего деть некуда, кроме как думать на тему "как же я организую взаимодействие классов в своём коде?" (ответ: "ды ни как не организлвывай! просто наделай кучу функций и всё! при случае не забудь и передавать указатели на функции, в моменты когда нужно делегировать различные алгоритмы различным частям кода")

то есть я говорю о том что минимазилм в использовании классов — взят не из-за комплексов — а и из-за вполне практичных соображений :-)

ООП это когда данные (объекты) лежат в основе алгоритма (всё вертится вокруг объектив и их состояний).. а мне может быть больше нравится когда в основе алгоритма лежат функции а не данные :-)

Исправление user_id_68054, :

Классы в крестах наглядный и стандартизированный инструмент, избегать их использования нет никакого смысла

если в Классах используется наследование — то как мне глядя на код метода класса понять — используется ли именно этот код или же он где-то там перегружен в наследнике? (просматривать каждого наслденика?)

[впрочем, уже чутьли не научно доказано что «наследование» это порочная практика — и об этом много кто говорил.. а в современных языках стараются вообще убрать «наследование» (на крайний случай заменить «наследование» на «примеси»)... так что тут я много говорить не будут и так всё ясно :)]

а если в классе НЕ используется наследование\перегрузка — то вообще какой тогда толк от такого класса? ну засунули группу функций под фигурные скобки и назвали не «функция» а «метод» и типа так стало круче? (в ООП это называется «инкапсуляция»)

а какой толк от инкапсуляции? :-)

как мне определить — должна ли очереная «функция» быть «методом», или же реализовать её обособленно всё-таки как «функцию»?.. где эта грань?

а парить себе мозги на тему protected\public и friend — зачем это было бы нужно, если бы вместо класса у нас просто была бы структура и внешние функции которые с ней работают? :-)

неужали программисту и времени-то своего деть некуда, кроме как думать на тему "как же я организую взаимодействие классов в своём коде?" (ответ: "ды ни как не организлвывай! просто наделай кучу функций и всё! при случае не забудь и передавать указатели на функции, в моменты когда нужно делегировать различные алгоритмы различным частям кода")

то есть я говорю о том что минимазилм в использовании классов — взят не из-за комплексов — а и из-за вполне практичных соображений :-)

ООП это когда данные (объекты) лежат в основе алгоритма.. а мне может быть больше нравится когда в основе алгоритма лежат функции а не данные :-)

Исправление user_id_68054, :

Классы в крестах наглядный и стандартизированный инструмент, избегать их использования нет никакого смысла

если в Классах используется наследование — то как мне глядя на код метода класса понять — используется ли именно этот код или же он где-то там перегружен в наследнике? (просматривать каждого наслденика?)

[впрочем, уже чутьли не научно доказано что «наследование» это порочная практика — и об этом много кто говорил.. а в современных языках стараются вообще убрать «наследование» (на крайний случай заменить «наследование» на «примеси»)... так что тут я много говорить не будут и так всё ясно :)]

а если в классе НЕ используется наследование\перегрузка — то вообще какой тогда толк от такого класса? ну засунули группу функций под фигурные скобки и назвали не «функция» а «метод» и типа так стало круче? (в ООП это называется «инкапсуляция»)

а какой толк от инкапсуляции? :-)

как мне определить — должна ли очереная «функция» быть «методом», или же реализовать её обособленно всё-таки как «функцию»?.. где эта грань?

а парить себе мозги на тему protected\public и friend — зачем это было бы нужно, если бы вместо класса у нас просто была бы структура и внешние функции которые с ней работают? :-)

неужали программисту и времени-то своего деть некуда, кроме как думать на тему "как же я организую взаимодействие классов в своём коде?" (ответ: "ды ни как не организлвывай! просто наделай кучу функций и всё! при случае не забудь и передавать указатели на функции, в моменты когда нужно делегировать различные алгоритмы различным частям кода")

то есть я говорю о том что минимазилм в использовании классов — взят не из-за комплексов — а и из-за вполне практичных соображений :-)

ООП это когда данные (объекты) являются лежат в основе алгоритма.. а мне может быть больше нравится когда в основе алгоритма лежат функции а не данные :-)

Исправление user_id_68054, :

Классы в крестах наглядный и стандартизированный инструмент, избегать их использования нет никакого смысла

если в Классах используется наследование — то как мне глядя на код метода класса понять — используется ли именно этот код или же он где-то там перегружен в наследнике? (просматривать каждого наслденика?)

[впрочем, уже чутьли не научно доказано что «наследование» это порочная практика — и об этом много кто говорил.. а в современных языках стараются вообще убрать «наследование» (на крайний случай заменить «наследование» на «примеси»)... так что тут я много говорить не будут и так всё ясно :)]

а если в классе НЕ используется наследование\перегрузка — то вообще какой тогда толк от такого класса? ну засунули группу функций под фигурные скобки и назвали не «функция» а «метод» и типа так стало круче? (в ООП это называется «инкапсуляция»)

а какой толк от инкапсуляции? :-)

как мне определить — должна ли очереная «функция» быть «методом», или же реализовать её обособленно всё-таки как «функцию»?.. где эта грань?

а парить себе мозги на тему protected\public и friend — зачем это было бы нужно, если бы вместо класса у нас просто была бы структура и внешние функции которые с ней работают? :-)

неужали программисту и времени-то своего деть некуда, кроме как думать на тему "как же я организую взаимодействие классов в своём коде?" (ответ: "ды ни как не организлвывай! просто наделай кучу функций и всё! при случае не забудь и передавать указатели на функции, в моменты когда нужно делегировать различные алгоритмы различным частям кода")

то есть я говорю о том что минимазилм в использовании классов — взят не из-за комплексов — а и из-за вполне практичных соображений :-)

ООП это когда данные (объекты) являются лежат в основе алгоритма.. а мне может быть больше нравится когда основой алгоритма являются функции а не данные :-)

Исправление user_id_68054, :

Классы в крестах наглядный и стандартизированный инструмент, избегать их использования нет никакого смысла

если в Классах используется наследование — то как мне глядя на код метода класса понять — используется ли именно этот код или же он где-то там перегружен в наследнике? (просматривать каждого наслденика?)

[впрочем, уже чутьли не научно доказано что «наследование» это порочная практика — и об этом много кто говорил.. а в современных языках стараются вообще убрать «наследование» (на крайний случай заменить «наследование» на «примеси»)... так что тут я много говорить не будут и так всё ясно :)]

а если в классе НЕ используется наследование\перегрузка — то вообще какой тогда толк от такого класса? ну засунули группу функций под фигурные скобки и назвали не «функция» а «метод» и типа так стало круче? (в ООП это называется «инкапсуляция»)

а какой толк от инкапсуляции? :-)

как мне определить — должна ли очереная «функция» быть «методом», или же реализовать её обособленно всё-таки как «функцию»?.. где эта грань?

а парить себе мозги на тему protected\public и friend — зачем это было бы нужно, если бы вместо класса у нас просто была бы структура и внешние функции которые с ней работают? :-)

неужали программисту и времени-то своего деть некуда, кроме как думать на тему "как же я организую взаимодействие классов в своём коде?" (ответ: "ды ни как не организлвывай! просто наделай кучу функций и всё! при случае не забудь и передавать указатели на функции, в моменты когда нужно делегировать различные алгоритмы различным частям кода")

то есть я говорю о том что минимазилм в использовании классов — взят не из-за комплексов — а и из-за вполне практичных соображений :-)

Исправление user_id_68054, :

Классы в крестах наглядный и стандартизированный инструмент, избегать их использования нет никакого смысла

если в Классах используется наследование — то как мне глядя на код метода класса понять — используется ли именно этот код или же он где-то там перегружен в наследнике? (просматривать каждого наслденика?)

[впрочем, уже чутьли не научно доказано что «наследование» это порочная практика — и об этом много кто говорил.. а в современных языках стараются вообще убрать «наследование»... так что тут я много говорить не будут и так всё ясно :)]

а если в классе НЕ используется наследование\перегрузка — то вообще какой тогда толк от такого класса? ну засунули группу функций под фигурные скобки и назвали не «функция» а «метод» и типа так стало круче? (в ООП это называется «инкапсуляция»)

а какой толк от инкапсуляции? :-)

как мне определить — должна ли очереная «функция» быть «методом», или же реализовать её обособленно всё-таки как «функцию»?.. где эта грань?

а парить себе мозги на тему protected\public и friend — зачем это было бы нужно, если бы вместо класса у нас просто была бы структура и внешние функции которые с ней работают? :-)

неужали программисту и времени-то своего деть некуда, кроме как думать на тему "как же я организую взаимодействие классов в своём коде?" (ответ: "ды ни как не организлвывай! просто наделай кучу функций и всё! при случае не забудь и передавать указатели на функции, в моменты когда нужно делегировать различные алгоритмы различным частям кода")

то есть я говорю о том что минимазилм в использовании классов — взят не из-за комплексов — а и из-за вполне практичных соображений :-)

Исходная версия user_id_68054, :

Классы в крестах наглядный и стандартизированный инструмент, избегать их использования нет никакого смысла

если в Классах используется наследование — то как мне глядя на код метода класса понять — используется ли именно этот код или же он где-то там перегружен в наследнике? (просматривать каждого наслденика?)

а если в классе НЕ используется наследование\перегрузка — то вообще какой тогда толк от такого класса? ну засунули группу функций под фигурные скобки и назвали не «функция» а «метод» и типа так стало круче? (в ООП это называется «инкапсуляция»)

а какой толк от инкапсуляции? :-)

как мне определить — должна ли очереная «функция» быть «методом», или же реализовать её обособленно всё-таки как «функцию»?.. где эта грань?

а парить себе мозги на тему protected\public и friend — зачем это было бы нужно, если бы вместо класса у нас просто была бы структура и внешние функции которые с ней работают? :-)

неужали программисту и времени-то своего деть некуда, кроме как думать на тему "как же я организую взаимодействие классов в своём коде?" (ответ: "ды ни как не организлвывай! просто наделай кучу функций и всё! при случае не забудь и передавать указатели на функции, в моменты когда нужно делегировать различные алгоритмы различным частям кода")

то есть я говорю о том что минимазилм в использовании классов — взят не из-за комплексов — а и из-за вполне практичных соображений :-)