3D.ru

Собственно сабж, я знаю в общих чертах зачем - но обычно формулировка в требованиях звучит как: "Отличное знание ООП и паттернов программирования".
При том, что используется в разработке что одно, что другое не сказал бы что и часто, или как-то заметно.
Может это я что-то не то делаю? Или люди составляют требования слишком шаблонно, как для любой другой сферы программирования?
Я один, такой, кто практические не использует наследование, а из паттернов юзает только несколько основных?

Пост создан отчасти от любопытства, отчасти от грусти-печали, что "то ли лыжи не едут, то ли я того самого"...

Я не знаю, что такое паттерны. ООП знаю -- это вроде бы форма организации предприятия.

ООП - объектно-ориентированное программирование.

При том, что используется в разработке что одно, что другое не сказал бы что и часто, или как-то заметно.

То, что вы это не используете часто или заметно, говорит лишь о вашем уровне, как программиста. Потому и требуют, что для работы в команде без ООП нонче никуда.

Woolf писал(а):То, что вы это не используете часто или заметно, говорит лишь о вашем уровне, как программиста. Потому и требуют, что для работы в команде без ООП нонче никуда.

Я могу написать отдельный модуль игры, который будет встроен в систему и не будет трогать других программистов. Насколько я понял в этом основное назначение "отличного знания ООП".
Если я не прав - объясните как это еще может пригодиться в среднестатистической разработке игры.

Насколько я понял в этом основное назначение "отличного знания ООП".

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

вопрос дня!

Да чет наболело. Сижу теперь и думаю.

Знание паттернов и ООП необходимо не только для эффективной работы в команде, но и для построения качественной расширяемой архитектуры. Я бы даже сказал, что архитектура на первом месте, команда уже как следствие. Если в команде все разработчики имеют вышеуказанные знания, то и работа в команде будет куда эффективней. Да и в проекте порядок и гармония.

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

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


Или вот еще пример..
У меня в гуе есть листбокс и treebox, где в лист пихаются объекты. Как добиться универсальности, чтобы этот листбокс отображал что угодно - предметы, достижения, список игроков?
Элементарно.. Листбокс хранит объекты моего класса GuiItem, у которого есть метод render. Теперь, наследуем предмет от GuiItem, оверридим метод render и вуаля, мы можем пихать предметы в листбокс. Теперь для предмета будем выводиться его картинка, название и краткое описание, что это. То же и с другими сущностями.

про sql и мешанину на чистом C, обсалютно тоже самое в ООП без паттернов. повсеместное наследование классов ухудшает понятность кода, приходится лазить по куче интерфейсов и абстрактных классов override-нутых непонятно где, чтоб потом выясинть, что ошибка в другом месте.
nile правильно написал, паттерны нужны для масштабирования системы.
НО. юнити то основана на компонентной модели, и во многих случаях лучшее ее и придерживаться, писать независимые объекты компоненты.
вобщем паттерны - это хорошо. но как и топикстартер, в плане юнити я использую всего от силы 3 паттерна (singleton, mvvm, strategy может еще что то)

кстати.. давайте кто паттерны использует - пишите какой.

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

Синглтон, стейт машину, фабрику, стратегию, иногда цепочку обязанностей при разборе респонсов сервера.

ascilograf писал(а):Собственно сабж, я знаю в общих чертах зачем - но обычно формулировка в требованиях звучит как: "Отличное знание ООП и паттернов программирования".

А еще иногда требуют TDD с покрытием тестами близкому к 100%.

ascilograf писал(а):Я один, такой, кто практические не использует наследование, а из паттернов юзает только несколько основных?

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

А еще иногда требуют TDD с покрытием тестами близкому к 100%.

Не умею писать тесты.