Зачем заказчики требуют ООП и знание паттернов?

**Lailore** 21 мар 2015, 03:02

ООП нужен для архитектуры. спагетти код ужасен в плане дебага, расширяемости, доработки, тестируемости, изменения...
И да, я в unity использую: Di, фабрики, адаптеры, прокси, стратегию, комманду, декораты и т.п. И да, работаю через TDD, а для интеграционного тестирования - Unity Test Tools.

Golandez писал(а):Синглтон

Ненавижу это, просто ярость. Ни протестировать нормально, не заменить реализацию. Что бы избавиться от синглтона, присмотритесь к DI http://smarly.net/dependency-injection-in-net , https://github.com/modesttree/Zenject

**gnoblin** 21 мар 2015, 03:18

Lailore писал(а):ООП нужен для архитектуры. спагетти код ужасен в плане дебага, расширяемости, доработки, тестируемости, изменения...
И да, я в unity использую: Di, фабрики, адаптеры, прокси, стратегию, комманду, декораты и т.п. И да, работаю через TDD, а для интеграционного тестирования - Unity Test Tools.
Golandez писал(а):Синглтон

Ненавижу это, просто ярость. Ни протестировать нормально, не заменить реализацию. Что бы избавиться от синглтона, присмотритесь к DI http://smarly.net/dependency-injection-in-net , https://github.com/modesttree/Zenject

хз, синглтон норм. а покажи игрового примеры кода со всеми этими паттернами?

**gnoblin** 21 мар 2015, 03:22

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

лучшее обьяснение!

**Woolf** 21 мар 2015, 03:25

Ненавижу это, просто ярость. Ни протестировать нормально, не заменить реализацию. Что бы избавиться от синглтона, присмотритесь к DI

Т.е. вместо простого и ясного синтаксиса синглтона вы предлагаете использовать громоздкий и тормознутый аппарат? Ну, можно, а зачем?

**Lailore** 21 мар 2015, 03:59

Woolf писал(а):
Ненавижу это, просто ярость. Ни протестировать нормально, не заменить реализацию. Что бы избавиться от синглтона, присмотритесь к DI

Т.е. вместо простого и ясного синтаксиса синглтона вы предлагаете использовать громоздкий и тормознутый аппарат? Ну, можно, а зачем?

хм, вы заблуждаетесь, что он ясный и понятный(глобальные переменные тоже ясны и понятны?), что Di громозкий и тормознутый тоже. Я не учитель, так что если вам и в правду интересно, прочитайте пару первых глав книги, на которую я дал ссылку.

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

лучшее обьяснение!

Это объяснение поъоже на издевку. Причем она противоречет сама себе. Спагетти код - вот что самое сакральное в конторе. По большому счету паттерны, это лучшие практики, которые проверенны временем, но не менее важное то, что это хорошая передача знаний между программистами(да и самому себе через пару месяцев). То есть не надо описывать весь алгоритм, просто говоря, если один программист скажет, что в этом месте используется декоратор, то второй программист уже будет примерно представлять как это работает, без лишнего погружения в код. И да, наш любимый Unity тоже использует паттерн компонент, а в нем update и т.п. И заметте, я не говорю про то, как работает компонент, я просто сказал название паттерна.

gnoblin писал(а):
Lailore писал(а):ООП нужен для архитектуры. спагетти код ужасен в плане дебага, расширяемости, доработки, тестируемости, изменения...
И да, я в unity использую: Di, фабрики, адаптеры, прокси, стратегию, комманду, декораты и т.п. И да, работаю через TDD, а для интеграционного тестирования - Unity Test Tools.
Golandez писал(а):Синглтон

Ненавижу это, просто ярость. Ни протестировать нормально, не заменить реализацию. Что бы избавиться от синглтона, присмотритесь к DI http://smarly.net/dependency-injection-in-net , https://github.com/modesttree/Zenject

хз, синглтон норм. а покажи игрового примеры кода со всеми этими паттернами?

Хм, вот например ваш синглтон

Синтаксис:

Используется csharp

//В Installer

#if UNITY_STANDALONE

Container.Bind<IInputController>().ToSingle<DesktopController>();

#elif UNITY_PS4

Container.Bind<IInputController>().ToSingle<JoystickController>();

#endif

// А уже в компонентак

[Inject] private IInputConroller _inputController;

// И все, компоненту по барабану, какой именно контроллер, и он не задумывается на какой платформе работает, + при написании тестов, можно вообще свой мок запихать, что бы независимо от джостика давать события компоненту

**gnoblin** 21 мар 2015, 05:54

спс, но синглтон он самый простой - покажи плиз остальные

**Lailore** 21 мар 2015, 06:21

gnoblin писал(а):спс, но синглтон он самый простой - покажи плиз остальные

Я думаю лучше подсмотреть здесь http://live13.livejournal.com/462582.html
Например: http://live13.livejournal.com/464691.html , http://live13.livejournal.com/473256.html , http://live13.livejournal.com/473028.html

**Nicloay** 21 мар 2015, 06:53

Lailore писал(а):Хм, вот например ваш синглтон

Синтаксис:
Синтаксис: [ Показать ]
Используется csharp

//В Installer
#if UNITY_STANDALONE
Container.Bind<IInputController>().ToSingle<DesktopController>();
#elif UNITY_PS4
Container.Bind<IInputController>().ToSingle<JoystickController>();
#endif

// А уже в компонентак
[Inject] private IInputConroller _inputController;
// И все, компоненту по барабану, какой именно контроллер, и он не задумывается на какой платформе работает, + при написании тестов, можно вообще свой мок запихать, что бы независимо от джостика давать события компоненту

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

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

Вобщем без фанатизма имхо.

**Lailore** 21 мар 2015, 07:12

Nicloay писал(а):
Lailore писал(а):Хм, вот например ваш синглтон

Синтаксис:
Синтаксис: [ Показать ]
Используется csharp

//В Installer
#if UNITY_STANDALONE
Container.Bind<IInputController>().ToSingle<DesktopController>();
#elif UNITY_PS4
Container.Bind<IInputController>().ToSingle<JoystickController>();
#endif

// А уже в компонентак
[Inject] private IInputConroller _inputController;
// И все, компоненту по барабану, какой именно контроллер, и он не задумывается на какой платформе работает, + при написании тестов, можно вообще свой мок запихать, что бы независимо от джостика давать события компоненту

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

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

Вобщем без фанатизма имхо.

Гейм дизайнер не устанавливает контроллер ввода игрока. Естественно никто компоненты Unity3d не отменяет.

Синтаксис:

Используется csharp

 лапша из классов и файлов ничем не отличается от лапши в одном классе

Что в вашем понимании "лапша из классов"? И да, при использовании DI, лапша более предпочтительно, если я правильно вас понял. Принцип открытости/закрытости. Принци единой обязанности.

если можете использовать функциональщину используйте ее

можете указать место?

Observer и вовсе говорит что он устаревший и лучше вместо горы классов использовать event-ы.

Что то я вас вообще не понял. Если вы про ключевое слово event в c#. То это и есть тот самый паттерн. Или что вы имели ввиду? Можете указать место, где об этом говорится?
Или вы про центральную шину событий? Если да, то это как раз похоже на юнитевское SendMessage. Я все так же ненахожу про устаревшего обсервера. Паттерн observer устареет, когда устареет событийная архитектура. А конкурентов или аналогов я пока не вижу и придумать не могу. Кстати, юнити помоему отходит от SendMessage, в пользу интерфейсов, которые обрабатывают конкретные события(новый GUI). В любом случае центральная шина событий это лишь один из способов бороться со сложностью и повысить гибкость кода. Она не универсальна.

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

**Nicloay** 21 мар 2015, 07:37

Lailore писал(а):Гейм дизайнер не устанавливает контроллер ввода игрока. Естественно никто компоненты Unity3d не отменяет.

Ну дизайнер уровней, перепутал малеха

Lailore писал(а):Что в вашем понимании "лапша из классов"? И да, при использовании DI, лапша более предпочтительно, если я правильно вас понял. Принцип открытости/закрытости. Принци единой обязанности.

На любой класс интерфейс сверху, передача ссылок и параметров исключительно через интерфейсы, множественное наследование и еще в этом же роде. Для корпоративных приложений это хорошо, там данные являются основой, в игре же главное это логика. и как по мне, DI тут явно излишен.
В игре лучше делать по максиому независимый компонент. Типа навесил на game object десяток компонентов, сконвертил в префаб, и расслабился.

Lailore писал(а):
если можете использовать функциональщину используйте ее

можете указать место?

http://gameprogrammingpatterns.com/comm ... functional
Конкретно в C# можно обойтись без классов, и через делегаты добиться того же самого, а при передаче параметров использовать лямбды. Но опять же, это синтетический пример, я бы в большинстве случаев объявил интерфейс и классы как в оригинальном паттерне.

Lailore писал(а):
Observer и вовсе говорит что он устаревший и лучше вместо горы классов использовать event-ы.

Что то я вас вообще не понял. Если вы про ключевое слово event в c#. То это и есть тот самый паттерн. Или что вы имели ввиду? Можете указать место, где об этом говорится?

http://gameprogrammingpatterns.com/obse ... vers-today
more modern approach is for an “observer” to be only a reference to a method or function. In languages with first-class functions, and especially ones with closures, this is a much more common way to do observers.

п.с. Вот еще что меня смутило в вашем предыдущем сообщении, но только сейчас понял что. У вас там разные контроллеры для десктопа и для консоли. И вот мне не понятно, что там действительно разного, в большинстве случаев через Input можно настроить и клаивиши и джойстик в одном месте.. это ж не тач скрин чтоб действительно ввод изменился с кнопок на тач евенты.. или у вас там аналог кинекта? (не знаю как он на ps называется)

**Lailore** 21 мар 2015, 07:51

Конкретно в C# можно обойтись без классов, и через делегаты добиться того же самого, а при передаче параметров использовать лямбды. Но опять же, это синтетический пример, я бы в большинстве случаев объявил интерфейс и классы как в оригинальном паттерне.

Хм. А я использую ключевое слово event. По сути, ничего не меняется, это все тот же observer. Ключевое слово это синтаксический сахар и не более. Как и async/awake в .net 4.5.
Хотя похоже вы не это имеете ввиду. Что бы понять, чем ООП лучше подходит, просто почитайте чем ООП в принципе лучше, чем функциональное программирование. Грубо говоря - все та же борьба со сложностью.

Ну дизайнер уровней, перепутал малеха

Смысл не меняется. И дизайнер уровней так же перетаскивает префабы и т.п.

п.с. Вот еще что меня смутило в вашем предыдущем сообщении, но только сейчас понял что. У вас там разные контроллеры для десктопа и для консоли. И вот мне не понятно, что там действительно разного, в большинстве случаев через Input можно настроить и клаивиши и джойстик в одном месте.. это ж не тач скрин чтоб действительно ввод изменился с кнопок на тач евенты.. или у вас там аналог кинекта? (не знаю как он на ps называется)

Это был придуманный на ходу пример. Можете считать, что там переключение между дескопом и тачем, если вам так приятнее.

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

**Nicloay** 21 мар 2015, 08:01

Lailore писал(а):Что бы понять, чем ООП лучше подходит, просто почитайте чем ООП в принципе лучше, чем функциональное программирование. Грубо говоря - все та же борьба со сложностью.

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

Смысл не меняется. И дизайнер уровней так же перетаскивает префабы и т.п.

Дизайнер сможет сам нужные компоненты в нужной комбинации подобрать, в случае с DI это сможет сделать только программист через код.

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

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

**Lailore** 21 мар 2015, 08:12

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

Принцип открытости/закрытости. Принцип единой обязанности. Сами принципы и для чего они нужны я описывать не буду. Тут вроде неплохо все http://blog.byndyu.ru/2009/10/solid.html

изайнер сможет сам нужные компоненты в нужной комбинации подобрать, в случае с DI это сможет сделать только программист через код.

Еще раз, никто не отменяет компоненты unity. Так что это не правда про случай с Di.

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

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

**Левш@** 26 мар 2015, 01:21

это не значит что не надо стремиться к улучшению своих навыков в проектировании кода

Кто бы спорил, а при чем тут патерны ?

**gnoblin** 26 мар 2015, 02:32

Lailore писал(а):
gnoblin писал(а):спс, но синглтон он самый простой - покажи плиз остальные

Я думаю лучше подсмотреть здесь http://live13.livejournal.com/462582.html
Например: http://live13.livejournal.com/464691.html , http://live13.livejournal.com/473256.html , http://live13.livejournal.com/473028.html

ссылка интересная, но я ж про то как ты применяешь - это любопытно больше всего. спасибо

Зачем заказчики требуют ООП и знание паттернов?

Re: Зачем заказчики требуют ООП и знание паттернов?

Re: Зачем заказчики требуют ООП и знание паттернов?

Re: Зачем заказчики требуют ООП и знание паттернов?

Re: Зачем заказчики требуют ООП и знание паттернов?

Re: Зачем заказчики требуют ООП и знание паттернов?

Re: Зачем заказчики требуют ООП и знание паттернов?

Re: Зачем заказчики требуют ООП и знание паттернов?

Re: Зачем заказчики требуют ООП и знание паттернов?

Re: Зачем заказчики требуют ООП и знание паттернов?

Re: Зачем заказчики требуют ООП и знание паттернов?

Re: Зачем заказчики требуют ООП и знание паттернов?

Re: Зачем заказчики требуют ООП и знание паттернов?

Re: Зачем заказчики требуют ООП и знание паттернов?

Re: Зачем заказчики требуют ООП и знание паттернов?

Re: Зачем заказчики требуют ООП и знание паттернов?

Кто сейчас на конференции