S>Более того, часто бывает так, что пока архитектор парит в эмпиреях ака "тут одного рефакторинга на пару человеколет", беспринципный внедренец быстренько втыкает очередную палку, обмазывает очередным г., и разблокирует сделку на $300k. S>Я такого навидался.
Вот-вот. И архитектора будут вынуждать поддерживать это способ проектирования.
И если согласится, программисты первыми заголосят "с этим архитектором делаем г., только ажурное. Зачем нам архитектор?".
А поскольку менеджеры легко перекладывает ответственность за свои решения, со временем его уволят за демотивацию команды.
За архитектуру редко увольняют, менеджеры в ней не понимают.
В итоге, как опытный сисадмин, архитектор работает с людьми, а не с компьютерами.
По моему опыту, архитектор может работать долго, если
— он bus-фактор номер один, т.е. только он понимает как оно в целом работает, а все остальные только по кускам. и любые попытки передать знание дипломатично пресекаются
— архитектор скорее хороший менедежер — имеет подход к каждому бегемотику, и хороший скил продаж "г. и палок", который они делают
и то и другое не слишком хорошо для бизнеса, но менеджеров устраивает гораздо больше 2-ой вариант
поэтому "не берите на работу архитектора", крайне практичный совет, как это ни печально
не менее печально то, что все зло в программистах-бегемотиках
Здравствуйте, Current, Вы писали:
C>Ну инкапсуляцию методов и данных, на которую был наезд, используют и хвалят 99.9%
Дело не в этом. Просто раньше это было священной коровой и любая критика этих принципов вызывала у публики нездоровую реакцию.
Сейчас уже не так. Используют, конечно, но без религиозного фанатизма.
C>Хуже, это сейчас тренд у менеджеров — "не берите в команду архитектора, он может демотивировать ребят". C>Что еще хуже, этот совет практичен. Менеджеров "г. и палки" как правило тоже устраивают.
Ты про каких-то конкретных менеджеров говоришь?
Озвучь имена, места работы, не стесняйся.
C>>Ну инкапсуляцию методов и данных, на которую был наезд, используют и хвалят 99.9% 0>Дело не в этом. Просто раньше это было священной коровой и любая критика этих принципов вызывала у публики нездоровую реакцию. 0>Сейчас уже не так. Используют, конечно, но без религиозного фанатизма.
А это здоровая реакция?
C>>Хуже, это сейчас тренд у менеджеров — "не берите в команду архитектора, он может демотивировать ребят". C>>Что еще хуже, этот совет практичен. Менеджеров "г. и палки" как правило тоже устраивают. 0>Ты про каких-то конкретных менеджеров говоришь? 0>Озвучь имена, места работы, не стесняйся.
Здравствуйте, Current, Вы писали:
0>>Сейчас уже не так. Используют, конечно, но без религиозного фанатизма. C>А это здоровая реакция?
Что именно?
0>>Озвучь имена, места работы, не стесняйся. C>нет, спасибо. C>various anonymous managers
Ну а varius other managers так не думают
На таком высоком уровне абстракции продуктивного обсуждения не получится.
Здравствуйте, pestis, Вы писали:
0>>Ты про каких-то конкретных менеджеров говоришь? 0>>Озвучь имена, места работы, не стесняйся. P>Незачем даже далеко ходить, тот же Синклерв соседнем посте не против. Имя, должность и место работы у него в профиле
В каком сообщении он говорит, что вредно брать в команду архитекторов?
0>Ну а varius other managers так не думают 0>На таком высоком уровне абстракции продуктивного обсуждения не получится.
ну и хорошо, на всякий случай уточню, что "без архитектора" не в смысле вообще без руководства
есть тикеты, стэндапы, рука-руку моющий код-ревью друг друга, каждый фигачит тикеты в меру своего восприятия
нет "звезды" что видит архитектуру кода так, и так ее должны видеть все
бизнес интересуют доставка фич и рейтинги отказов
в коде "г. и палки"
в таком режиме комманда может работать долго и стабильно
видел как команды с архитектором переходили к этом варианту
успешных переходов от этого варианта к архитектурному не видел
Здравствуйте, Current, Вы писали:
C>В итоге, как опытный сисадмин, архитектор работает с людьми, а не с компьютерами.
Это всегда так было, есть и будет.
Работа архитектора — строить систему в условиях ограничений. И основной скилл — уметь ограничения выявлять. Чаще всего ограничения не в технологиях, а в сроках, бюджетах, людях и их потребностях, и далёких от технологий вещах. Поэтому архитектор всегда больше работает с людьми. Если это нормальный архитектор.
C>По моему опыту, архитектор может работать долго, если C>- он bus-фактор номер один, т.е. только он понимает как оно в целом работает, а все остальные только по кускам. и любые попытки передать знание дипломатично пресекаются C>- архитектор скорее хороший менедежер — имеет подход к каждому бегемотику, и хороший скил продаж "г. и палок", который они делают C>и то и другое не слишком хорошо для бизнеса, но менеджеров устраивает гораздо больше 2-ой вариант
А чем второй вариант плох для бизнеса?
В советское время был институт ГИПов, на каждом крупном проекте был свой Главный Инженер. Он как раз работал по второй модели и это считалось правильным.
C>поэтому "не берите на работу архитектора", крайне практичный совет, как это ни печально
Я бы сказал, что не надо брать архитектора-теоретика.
C>не менее печально то, что все зло в программистах-бегемотиках
Программисты разные бывают. В изобретательство превышает лень и получается overarchitecture, у других лень оказывается сильнее и получается код из говна и палок.
Держать баланс могут не все. А когда целый коллектив, то это отдельная сложная нелинейная работа. А если добавить нетехнические ограничения — вот и работа для архитектора.
G>Работа архитектора — строить систему в условиях ограничений. И основной скилл — уметь ограничения выявлять. Чаще всего ограничения не в технологиях, а в сроках, бюджетах, людях и их потребностях, и далёких от технологий вещах. Поэтому архитектор всегда больше работает с людьми. Если это нормальный архитектор.
В розовой теории это должен делать бизнес-аналитик, а архитектор спец. именно по компьютерам. На практике, это даже почти так и есть — утверждения бюджета, сроков и бизнес требований делается большей частью менеджментом хотя и в диалоге с архитектором.
Но архитектору все равно достанется работа "с людьми" в том смысле что они — ленятся, врут, завидуют, интригуют, своевольничают и т.д. И под это надо строить всю работу.
G>Это всегда так было, есть и будет.
Да, но учился он на компьютерщика.
C>>- он bus-фактор номер один, т.е. только он понимает как оно в целом работает, а все остальные только по кускам. и любые попытки передать знание дипломатично пресекаются C>>- архитектор скорее хороший менеджер — имеет подход к каждому бегемотику, и хороший скил продаж "г. и палок", который они делают C>>и то и другое не слишком хорошо для бизнеса, но менеджеров устраивает гораздо больше 2-ой вариант G>А чем второй вариант плох для бизнеса?
Я извиняюсь, здесь для бизнеса в смысле "общечеловеческой пользы". Которая не всегда коррелирует с интересами владельцев, которые не всегда коррелируют с интересами менеджмента.
В розовой теории "общечеловеческой пользы", архитектор видит на 2 шага вперед, и разжевывает свои знания всем, добиваясь их реализации. Интриговать ему не нужно, потому что окружающие его люди понимают его ценность для коллектива, и без зависти и бунта, трудолюбиво и честно исполняют его предписания.
С точки зрения карьеры идеальный архитектор это звезда, который тоже видит технологии на 2 шага дальше всех, и который заражает и программистов и менеджеров своим энтузиазмом т.е. оба пункта из предыдущего сообщения — 1) только он знает как это работает в целом, 2) ладит с программистами и успешно продает их "г. и палки" менеджменту. Не в идеале достаточно второго.
G>Программисты разные бывают. В изобретательство превышает лень и получается overarchitecture, у других лень оказывается сильнее и получается код из говна и палок. G>Держать баланс могут не все. А когда целый коллектив, то это отдельная сложная нелинейная работа. А если добавить нетехнические ограничения — вот и работа для архитектора.
Да, причем нетехническая часть полностью преобладает. Так что если архитектор забьет на техническую, проблем в горизонте проекта будет минимум.
Работа по технической части это большей частью дело внутренней честности и амбиций перехода на следующий проект.
Причем все это будет скорее мешать в нетехнической части текущего проекта.
G>>Работа архитектора — строить систему в условиях ограничений. И основной скилл — уметь ограничения выявлять. Чаще всего ограничения не в технологиях, а в сроках, бюджетах, людях и их потребностях, и далёких от технологий вещах. Поэтому архитектор всегда больше работает с людьми. Если это нормальный архитектор.
C>В розовой теории это должен делать бизнес-аналитик, а архитектор спец. именно по компьютерам. На практике, это даже почти так и есть — утверждения бюджета, сроков и бизнес требований делается большей частью менеджментом хотя и в диалоге с архитектором.
Бизнес-аналитик не знает технических ограничений и не является экспертом в построении систем.
"Спец по компьютерам" не знает бизнес-ограничений, поэтому скорее спроектирует розового единорога, чем реальную систему.
Не знаю такой теории, которая говорит нам, что не нужно иметь технического лидера в проекте. Из банальной логики вытекает, что надо, и инженерная практика подсказывает то же самое последние 50 лет.
C>Но архитектору все равно достанется работа "с людьми" в том смысле что они — ленятся, врут, завидуют, интригуют, своевольничают и т.д. И под это надо строить всю работу. G>>Это всегда так было, есть и будет. C>Да, но учился он на компьютерщика.
Поэтому нормальный архитектор — редкость. Зачастую "архитектором" называют самого крутого техспеца, который решений никаких не принимает.
C>>>- он bus-фактор номер один, т.е. только он понимает как оно в целом работает, а все остальные только по кускам. и любые попытки передать знание дипломатично пресекаются C>>>- архитектор скорее хороший менеджер — имеет подход к каждому бегемотику, и хороший скил продаж "г. и палок", который они делают C>>>и то и другое не слишком хорошо для бизнеса, но менеджеров устраивает гораздо больше 2-ой вариант G>>А чем второй вариант плох для бизнеса?
C>Я извиняюсь, здесь для бизнеса в смысле "общечеловеческой пользы". Которая не всегда коррелирует с интересами владельцев, которые не всегда коррелируют с интересами менеджмента.
А чем он плох для "общечеловеческой пользы"?
C>В розовой теории "общечеловеческой пользы", архитектор видит на 2 шага вперед, и разжевывает свои знания всем, добиваясь их реализации. Интриговать ему не нужно, потому что окружающие его люди понимают его ценность для коллектива, и без зависти и бунта, трудолюбиво и честно исполняют его предписания.
То есть второй вариант плох, потому что люди несовершенны? Тогда любой вариант плох.
G>>Программисты разные бывают. В изобретательство превышает лень и получается overarchitecture, у других лень оказывается сильнее и получается код из говна и палок. G>>Держать баланс могут не все. А когда целый коллектив, то это отдельная сложная нелинейная работа. А если добавить нетехнические ограничения — вот и работа для архитектора. C>Да, причем нетехническая часть полностью преобладает. Так что если архитектор забьет на техническую, проблем в горизонте проекта будет минимум.
Если считать технической частью написание кода, то у архитектора она должна быть сведена к минимуму. Не к нулю только для того, чтобы навык не терять.
Здравствуйте, Current, Вы писали:
C>есть тикеты, стэндапы, рука-руку моющий код-ревью друг друга, каждый фигачит тикеты в меру своего восприятия C>нет "звезды" что видит архитектуру кода так, и так ее должны видеть все C>бизнес интересуют доставка фич и рейтинги отказов C>в коде "г. и палки" C>в таком режиме комманда может работать долго и стабильно
Я из чисто идеалистических побуждений, конечно, негодую, но если бизнес доволен результатами проекта, то, может быть, оно и ничего?
G>Бизнес-аналитик не знает технических ограничений и не является экспертом в построении систем. G>"Спец по компьютерам" не знает бизнес-ограничений, поэтому скорее спроектирует розового единорога, чем реальную систему.
да есть такой диалог, но там точность один-два порядка
причем, и уточнение ТЗ, и деление задач и оценки дней можно перекладывать на коллектив — точность не сильно пострадает
G>Не знаю такой теории, которая говорит нам, что не нужно иметь технического лидера в проекте. Из банальной логики вытекает, что надо, и инженерная практика подсказывает то же самое последние 50 лет.
инженерная практика 50 лет и больше — как я ее прочитал, говорит о том что архитектор/главный инженер должен быть примерно второй человек в технологической компании, причем первый это где-то главный акционер
быдло-менедждменнту такие жертвы власти не особо нужны, поэтому у них будет позиция как-бы архитектора с сильно ограниченными правами, который соотвественно закономерно будет слит коллективом. С развитием наглости менеджмента, можно вообще от этой позиции потенциального правдоруба трабл-мейкера отказаться, что и происходит
C>>>>- архитектор скорее хороший менеджер — имеет подход к каждому бегемотику, и хороший скил продаж "г. и палок", который они делают
G>А чем он плох для "общечеловеческой пользы"?
Код который работает отвратно, но успешно втюхан. И стадо бегемотов дружно подпевающее, что лучше кода в этих условиях написать было невозможно.
G>То есть второй вариант плох, потому что люди несовершенны? Тогда любой вариант плох.
Тем что, архитектор по должности должен нести заботу за тех. реализацию, а в этом варианте не берет ее на себя — нафиг нужно, а предпочитает втюхать "г. и палки" под аплодисменты команды.
G>>Не знаю такой теории, которая говорит нам, что не нужно иметь технического лидера в проекте. Из банальной логики вытекает, что надо, и инженерная практика подсказывает то же самое последние 50 лет. C>инженерная практика 50 лет и больше — как я ее прочитал, говорит о том что архитектор/главный инженер должен быть примерно второй человек в технологической компании, причем первый это где-то главный акционер
Кому должен? ГИПы в союзе вообще имели низкие административные должности, но это работало.
C>быдло-менедждменнту такие жертвы власти не особо нужны, поэтому у них будет позиция как-бы архитектора с сильно ограниченными правами, который соотвественно закономерно будет слит коллективом. С развитием наглости менеджмента, можно вообще от этой позиции потенциального правдоруба трабл-мейкера отказаться, что и происходит
В таких случаях проблема не в архитектуре, а в амбициях. В архитектуре скорее всего все в порядке, но амбиции писателя не удовлетворены.
C>>>>>- архитектор скорее хороший менеджер — имеет подход к каждому бегемотику, и хороший скил продаж "г. и палок", который они делают G>>А чем он плох для "общечеловеческой пользы"? C>Код который работает отвратно, но успешно втюхан. И стадо бегемотов дружно подпевающее, что лучше кода в этих условиях написать было невозможно.
И? Чем это плохо?
G>>То есть второй вариант плох, потому что люди несовершенны? Тогда любой вариант плох. C>Тем что, архитектор по должности должен нести заботу за тех. реализацию, а в этом варианте не берет ее на себя — нафиг нужно, а предпочитает втюхать "г. и палки" под аплодисменты команды.
Во-первых архитектор и будет формально нести ответственность. Хотя формальная ответственность ничего не означает, но по факту спрашивать будут с архитектора.
Во-вторых мы еще не выяснили в чем это плохо. Если код решает проблемы, то этого уже достаточно, а если еще и попадает в бизнес-ограничения, то это вообще идеальный код. Если архитектор смог продавать эти ограничения и обозначить проблемы, то он сделал все хорошо. Нет?
В-третьих если команда лучше не может, то это объективное ограничение. В таком случае надо его учитывать при проектировании, что нормальный архитектор и сделает (см во-вторых).
А если команда может, то нормальный архитектор запинает всех кого надо, ибо все равно спрашивать будут с архитектора (см во-первых).
G>Кому должен? ГИПы в союзе вообще имели низкие административные должности, но это работало.
Про ГИПы не знаю. Но вот Дмитрий Федорович Устинов был примерно 2-ой человек в СССР что касалось ВПК и связанных с ним отраслей. Причем 2-ой после главы государства.
из интернета, вторая ссылка по ГИП
Объясните мне пожалуйста, кто такой главный инженер проекта?...
— Это козел отпущения, которому платят бабки и мерещится решетка.
G>А если команда может, то нормальный архитектор запинает всех кого надо, ибо все равно спрашивать будут с архитектора (см во-первых).
Чем он их запинает?
У него нет полномочий. Архитектор может уволить программистов без консультаций? А менеджера проекта?
Здравствуйте, Current, Вы писали:
G>>Кому должен? ГИПы в союзе вообще имели низкие административные должности, но это работало.
C>Про ГИПы не знаю. Но вот Дмитрий Федорович Устинов был примерно 2-ой человек в СССР что касалось ВПК и связанных с ним отраслей. Причем 2-ой после главы государства.
C>из интернета, вторая ссылка по ГИП C>Объясните мне пожалуйста, кто такой главный инженер проекта?... C>- Это козел отпущения, которому платят бабки и мерещится решетка.
Да, есть такая фигня, что в союзе ГИПы несли очень большую ответственность.
G>>А если команда может, то нормальный архитектор запинает всех кого надо, ибо все равно спрашивать будут с архитектора (см во-первых). C>Чем он их запинает? C>У него нет полномочий. Архитектор может уволить программистов без консультаций? А менеджера проекта?
А вот тут интересный вопрос.
Инженеры обычно очень внутренне мотивированные люди. Им не нужна морковка, чтобы эффективно работать. Но их постоянно надо корректировать, чтобы они делали что нужно.
И вот корректировка — по сути убеждение каждого сотрудника, и этим нужно заниматься постоянно.
Если же просто не хотят работать, то сливать менеджеру, пусть разбирается.
Здравствуйте, Current, Вы писали:
C>...
C>Началось все с C>Деструкторы — плохо, используйте явное освобождение ресурсов C>Конструкторы — плохо, используйте фабрики, прячьте конструкторы в private C>Множественное наследование — плохо C>Наследование — всегда плохо, используйте агрегацию и интерфейсы C>Интерфейсы со множеством вызовов — плохо, используйте интерфейсы с одним
C>...
Началось все с того, что Алан Кей ничего не говорил про деструкторы, конструкторы, наследование (тем более про множественное) и интерфейсы.
Основным в его идее были "сообщения". Даже не объект. Эти сообщения можно группировать (похоже на инкапсуляцию и интерфейсы). Как-то навернуть на эти сообщения мат.теорию, вроде всяких алгебр. Чем то напоминает теорию категорий с его стрелками.
И как всегда псевдо-парадигма-архитекторы взяли самое незначительное в идее и развили до того что сейчас есть.
Здравствуйте, Current, Вы писали:
C>... — плохо ... C>... — плохо ... C>... — плохо ...
"Хорошо" и "плохо" — это слова-маркеры оценочных суждений, к которым, как известно, понятие "истинность" неприменимо.
Впрочем, это не столь важно. Важно, что такая на первый взгляд стройная и естественная технология, как ООП, почему-то иногда бывает полезна, а иногда даёт такую "побочку", что хоть вешайся.
Мне кажется, косяк в самой основе. В глубинном принципе, который для ООП можно сформулировать примерно так: "Если реальный мир состоит из объектов, то если и наши программы будут состоять из объектов, то моделировать ими реальный мир будет надёжнее, естественнее и результативнее".
В таком (и всех подобных ему) рассуждении есть сразу два косяка:
1. Реальный мир ни из каких объектов не состоит. Он, гад такой, вообще хрен знает из чего сам по себе состоит. Мировая теоретико-физическая мысль корчится в конвульсиях, пытаясь представить себе реальность в виде струн, стремящихся минимизировать покрываемую ими по десятимерному пространству-времени площадь, но всё глубже и глубже запутывается в измышлятине и поправочных коэффициентах. О каком стопудово объективном существовании таких вещей, как камни, деревья, люди и т.п. можно говорить в таких непотребных обстоятельствах? Любое разбиение реального мира на объекты (любое!!!) — результат волюнтаризма субъекта и особенностей тех обстоятельств, в которые в данный конкретный момент его, субъекта, занесло. Чуть изменились обстоятельства, и всё, капец. У нас уже на том же материале уже другие объекты. Будем в тысяче первый раз перетряхивать объектную модель нашей ООПшной проги. Или лепить очередную систему костылей, которая нам позволит классом "Собака" описывать не только собак и кошек (это было костылём в прошлый раз), но и аквариумных рыбок.
2. "Моделирование" — зачётная тема, но её ценность слегка (на самом деле не слегка, а очень сильно) преувеличена. Можно всю жизнь протрудиться программером и накодить гигабайты кода, но ни разу не написать ничего, что можно было бы назвать моделью чего-то. Веб-сервер не моделирует выдачу веб-страниц клиентам, а выдаёт их. Браузер не моделирует прорисовку страниц, а прорисовывает их. Даже позорный сумматор не моделирует суммирование, а делает его. И кошка не моделирует охоту на мышку. Автомобиль не моделирует перевозку пассажиров и грузов. И мы сами пишем комменты в кывт, а не моделируем это самое написание. Моделирование — узкая нишевая задача, почти совсем не встречающаяся в реальной промышленной практике. Ну и какого хрена мы должны решающим преимуществом инструмента считать его способность решать те задачи, решение которых нам заведомо не нужно? (В скобках замечу, что даже для моделирования ООП подходит не для всякого, а только для имитации взаимодействия небольших количеств дискретных сущностей)
Как-то так получается, что реально вкусными и повсеместно полезными у нас оказываются чисто служебные классы. Такие, как String, Array, HashTable и т.п. А все многочисленные ООА и ООД оказываются весьма опасным с точки зрения проектных рисков ментальным мусором.
Здравствуйте, Miroff, Вы писали:
M>Еще один прозрел. Все умные люди давно перелезли с C++ на связку C + python/java/ruby/whatever.
А самые продвинутые пошли дальше, и используют ассемблер + ОК, гугл.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Voblin, Вы писали:
V>2. "Моделирование" — зачётная тема, но её ценность слегка (на самом деле не слегка, а очень сильно) преувеличена. Можно всю жизнь протрудиться программером и накодить гигабайты кода, но ни разу не написать ничего, что можно было бы назвать моделью чего-то. Веб-сервер не моделирует выдачу веб-страниц клиентам, а выдаёт их. Браузер не моделирует прорисовку страниц, а прорисовывает их. Даже позорный сумматор не моделирует суммирование, а делает его. И кошка не моделирует охоту на мышку. Автомобиль не моделирует перевозку пассажиров и грузов. И мы сами пишем комменты в кывт, а не моделируем это самое написание. Моделирование — узкая нишевая задача, почти совсем не встречающаяся в реальной промышленной практике. Ну и какого хрена мы должны решающим преимуществом инструмента считать его способность решать те задачи, решение которых нам заведомо не нужно? (В скобках замечу, что даже для моделирования ООП подходит не для всякого, а только для имитации взаимодействия небольших количеств дискретных сущностей)
Как я уже неоднократно говорил, всё это "моделирование" существует исключительно в хреновых учебниках ООП.
В реальном программировании, где применяется реальное ООП, моделирование совсем другое.
Например, когда мы пишем программу, которая рисует геометрические фигуры, то мы в качестве основной сущности выделяем "рисователя", а вовсе не "фигуру". Потому что у фигуры поведения нет, а у "рисователя" — есть.
Это как раз и есть то, что вы называете "не моделировать, а делать".
Я это называю "модель решения, а не задачи". То есть если нам ставят задачу "напишите программу по расчёту параметров запуска баллистической ракеты", то даже при выборе ООП для реализации у нас не будет классов вроде Missile, Target, и интерфейсов типа ILauncheable.
Очень хорошо про это написано у Липперта в его серии про RPG: несмотря на наличие в игре таких сущностей, как Wizard, Warrior, Staff, Sword, и прочего, моделировать их поведение при помощи ООП лишено смысла. То есть одноимённых классов — не будет. Зато будет иерархия классов-наследников GameRule, которые описывают все вот эти ограничения типа "сила вампира снижается на 98% днём" или "Wizard не может использовать колюще-режущее оружие".
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S> [...] несмотря на наличие в игре таких сущностей, как Wizard, Warrior, Staff, Sword, и прочего, моделировать их поведение при помощи ООП лишено смысла. [...] Зато будет иерархия классов-наследников GameRule, [...]
Вооот. Это уже здравая мысль. Моделировать не предметную область, а структуру задач, которые нужно выполнить программе.
Ещё выкинуть иерархию классов-наследников GameRule (не факт, что правила вписываются в иерархическую структуру), и заменить её композицией объектов, реализующих нужные аспекты правил игры. Потом рассмотреть возможность замены объектов с мутабельным состоянием на функции, преобразующие неизменяемые данные (сильно упрощается распараллеливание). И получится нормальное ООП (или уже не ООП?).
