MiK
И это важно, потому как иначе нарушаются принципы ООП.

Какие это? Просветите.

Вы строите неверную архитектуру. Вам уже об этом написали. Смотрите как можно поправить свою систему с этой стороны. Класс с избытком атрибутов или с наличием неизвестных атрибутов, которые появляются в процессе выполнения операций над ним самим или над его экземплярами - это архитектурный косяк, т.е. неверное проектирование. И обижаться на то, что в языке нет механизмов для поддержания этого бесчинства все же не стоит. Существуют такие задачи, но пока они вне Вас. Да и вне меня, если честно Просто пересмотрите конкретно Вашу задачу. Есть механизм описания объекта с точки зрения ООП. Можно попробовать UML диаграммы. Об этом хорошо написано в книге Г. Буч. Объектно-ориентированное проектирование с примерами приложений. Можно пойти от сложного к простому: диаграмму пакетов или компонентов - диаграммы классов - …

MiK
Если класс дорос до 1000 имён, это значит, что будет не только много имён, но и много списков, и они опять же будут принадлежать разным переменным, а это значит, что снова возникнет вопрос, который я поднял в шапке темы.

Срочно к чтению:
“Рефакторинг” - Мартина Фаулера.
“Чистый код” - Боба Мартина.
и т.п.

Одна из основных ошибок начинающих программистов - попытка написания с первого раза идеального кода подходящего на 100% под некую задачу и учитывающего все варианты развития событий. Причем код по их мнению должен быть написан таким образом чтобы в дальнейшем его ни за что не менять, прямо высечь его на каменных скрижалях.

Реальность же имеет изменчивую природу, а код как и всё в нашем бренном мире, имеет свойство устаревать, и ваш только что готовый идеальный код может внезапно стать совершено не годным после первых двух фраз при общении с заказчиком. Вы можете не правильно понять задачу, заказчик может её неправильно понять, не учесть каких-то моментов, мелочей, не продумать до конца задачу, да к тому же внешние условия постоянно меняются - это нормальное развитие событий. В методике управления проектами, например, нет понятия длительности проекта, есть понятие длительности этапа проекта, проект же сам по себе имеет начало и бесконечную длительность во времени.

Вы всегда должны быть готовы к изменению кода, а для этого код должен быть понятен, если вы через неделю открываете свой код и пытаетесь понять что он делает - этот код хреновый! Если вы работаете в команде это усугубляется. Не пишите хреновый код, никогда не решайте виртуальных задач. Пишите понятный код.

Если задача требует изменения архитектуры приложения - меняйте архитектуру, даже не пытайтесь сделать хак, и прилепить какую-нибудь несуразицу, которая будет выдавать временно нужный результат. Потому как вслед за одним изменением последует другое, за ним третье - так и получается говнокод, с которым уже ничего нельзя сделать, только переписать всё заново. Чем раньше вы делаете изменение архитектуры - тем оно дешевле в конечном счете.

4kpt_III

Какие это? Просветите.

Принцип построения ассоциаций. ООП ведь предполагает иметь точкой опоры ассоциативное мышление, на котором кстати строится не только логика, но и память?


Alen

Вы всегда должны быть готовы к изменению кода, а для этого код должен быть понятен, если вы через неделю открываете свой код и пытаетесь понять что он делает - этот код хреновый! Если вы работаете в команде это усугубляется. Не пишите хреновый код, никогда не решайте виртуальных задач. Пишите понятный код.

Теоретически, я именно это и пытался сделать.


Я исхожу из того, что функции позволяют принимать хоть миллион разных имён, тут без ограничений. И, возможно я удивлён, что в классовый методах немного по другому. Думал, что просто не знаю нужного способа выкручиваясь статическим методом. Но я наверно ещё не дорос до нирваны.

MiK
Принцип построения ассоциаций. ООП ведь предполагает иметь точкой опоры ассоциативное мышление, на котором кстати строится не только логика, но и память?

Иметь точкой опоры? Строится не только логика но и память? Память чего? Я вообще запутался…
Т.е. Вы считаете, что при структурно-алгоритмическом подходе ассоциативное мышление будет лишним или при функциональном. Вам необходимо почитать хоть что-то серьезное по ООП. У Вас в голове каша.

4kpt_III
Ты уже троллишь. В структурном программировании много абстрактного мышления, но память - это всегда ассоциации.

Я мог бы дать и много больше информации об этом, но боюсь ты её не сможешь принять, или мне придётся писать книгу. Лучше покопайся с инете.

Во-первых на Вы. Тыкать будете своей кошке.
Во-вторых не Вам решать, что и как я смогу принять. Никто Вас не троллит. Вы мелете чушь… Причем полную (если Вы про память человека, то она строится не только на ассоциациях). Не разобравшись в общих подходах ООП начинаете задавать глупые вопросы и создавать тупые темы. Я лишь Вам пытаюсь подсказать, что необходимо сначала понять основы ООП и уж потом писать в этом стиле. Возможно жизнь вы и знаете, но до нормального кода Вам как до Киева рачки… А с таким подходом Вы его, возможно, вообще никогда написать не сможете.

P.S. И книгу Вы написать просто не в состоянии. Если бы были в состоянии - уже бы написали. А языком молоть, как говориться, - не дрова рубать.

P.S.S. В интернете не копаюсь. Читаю книги.

MiK
но боюсь ты её не сможешь принять

Креститься надо, когда страшно…

4kpt_III

Тыкать будете своей кошке.

С троллями только так.

Книгу тоже не смогу - это было образное выражение.

MiK
Я исхожу из того, что функции позволяют принимать хоть миллион разных имён, тут без ограничений. И, возможно я удивлён, что в классовый методах немного по другому.

Это как это?

Alen
Ну это статический метод, я так понял. А в чём пример?