https://gist.github.com/fesor/76d39b19b18f7103a7c058301dc6a8fe

например

где я ссылаюсь и на coupling и на coheasion

и ассампшен что человек который читает этот стайлгайд если не знает что это такое спросит

и тогда уже будут ссылки на литературу

в зависимости от того что именно человек не понимает

у нас в конторе все закрыто комерческой лицензией

в личку ща кину кусок

у нас в конторе все закрыто комерческой лицензией

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

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

Project Styleguide ========================+ Делай хорошо

https://gist.github.com/fesor/76d39b19b18f7103a7c058301dc6a8fe

интересно, спасибо)

а по поводу книги - стоит только ради коллекции, емкая выжиска содержится в конце книги - это можно взять и в электроном виде

http://memesmix.net/media/created/ohg1bn.jpg

> Объективно говоря, God Object — это лучший способ начинать проектировать систему.  Есть две альтернативы:  1. Потратить время на разработку true-ООП-архитектуры, при реализации обнаружить проблемы, потратить еще время на разработку true-ООП-архитектуры, в итоге потратить время и не получить результата.  2. Потратить время на разработку God Object'а, изучить его работу в реальной системе, позже — рефакторить и оптимизировать по необходимости. Нетрудно догадаться, что второй вариант на практике предпочтительнее.

https://pp.userapi.com/c636926/v636926730/77dad/wJ3rAEWu05E.jpg

Как было на самом деле:

https://pp.userapi.com/c636926/v636926730/77dad/wJ3rAEWu05E.jpg

шаболны(

https://pp.userapi.com/c636926/v636926730/77db6/71vHhKxNGho.jpg

на последней картинке истинный С++ программист )

> Объективно говоря, God Object — это лучший способ начинать проектировать систему.  Есть две альтернативы:  1. Потратить время на разработку true-ООП-архитектуры, при реализации обнаружить проблемы, потратить еще время на разработку true-ООП-архитектуры, в итоге потратить время и не получить результата.  2. Потратить время на разработку God Object'а, изучить его работу в реальной системе, позже — рефакторить и оптимизировать по необходимости. Нетрудно догадаться, что второй вариант на практике предпочтительнее.

Откуда паста?

> Объективно говоря, God Object — это лучший способ начинать проектировать систему.  Есть две альтернативы:  1. Потратить время на разработку true-ООП-архитектуры, при реализации обнаружить проблемы, потратить еще время на разработку true-ООП-архитектуры, в итоге потратить время и не получить результата.  2. Потратить время на разработку God Object'а, изучить его работу в реальной системе, позже — рефакторить и оптимизировать по необходимости. Нетрудно догадаться, что второй вариант на практике предпочтительнее.

http://s.pikabu.ru/post_img/2013/05/13/4/1368415128_1150133793.jpg

это как рассматривать только две крайности

делать сразу хорошо или сразу очень плохо

есть более предпочтительный вариант - делать посередине

то есть не тратить месяцы на проектирование, па день-два

а потом рефакторинг постоянно

с появлением новой информации о том как все же должно работать

нормально делай нормально будет

+1

есть более предпочтительный вариант - делать посередине

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

делать сразу хорошо или сразу очень плохо

Не, там делать сразу плохо или делать сразу плохо

Так что полностью согласен с теоремой господина с картинки выше

Интересно, а что такое Yii::$app ?

Божественный батя объектов или шо?)

https://github.com/rooby-lang/rooby

Есть же crystal

https://www.exakat.io/moving-from-array-to-class/

это же в php digest была ссылка

да

я все равно по англиски не понимаю))) (сарказм)

https://twitter.com/ircmaxell/status/853997289924431872

повеселил один из коментов

который?

который?

no time to cleanup :D

no time to cleanup :D

а, да норм)

https://m.habrahabr.ru/post/327484/

вот вам хороших песенок про tdd в пятницу вечером https://youtu.be/dJUVNFxrK_4?t=55m54s

"make sure they did not repeat the same year 20 times" - excellent point

"make sure they did not repeat the same year 20 times" - excellent point

ага, но это тебе виднее чем мне на самом деле

да я и сам такой

по цифрам опыта много, а в реальности хрен его знает

Это нормальная практика - делать отдельную модель для БД, отдельную для фронта? По одной сущности

Это нормальная практика - делать отдельную модель для БД, отдельную для фронта? По одной сущности

смотря что ты понимаешь мод "моделью". Модель данных - да. может быть разной.

ну и вообще это как бы весьма абстрактный вопрос

"модель для БД" - это скорее просто модель на запись, а для "фронта" - на чтение. У этих операций как правило разные зоны ответственности а значит им далеко не всегда нужно быть "одинаковыми"

ERROR: S client not available

ну вот да, по факту они разные, просто одна сущность вытекает из другой

есть какое-то правило именования?

есть какое-то правило именования?

называй что бы было понятно тебе и твоей команде. НЕ уверен - предлагай свои варианты

о, вот что посоветовали: User и UserDTO

/stat@combot

combot.org/chat/-1001071233926

о, вот что посоветовали: User и UserDTO

ну так себе

ну мол UserDTO не особо говорит зачем оно надо и что делает

хотя если у тебя есть конвеншен где-то на уровне ридми проекта что мол Something DTO is data model for presentation layer

то тогда ок

ну как же

для дата трансфера

ну мол UserDTO не особо говорит зачем оно надо и что делает

DTO - data transfer object. Что не понятно?

Блин, сейчас убьюсь об стену.

Давно пора.

на сцену вышел мистер остроумие 2017

Появились новые особенности бизнес-логики. Описал её процедурно строк в 50-60. Но вот абсолютно не могу понять как мне её встроить имеющуюся систему. И даже как вообще всё это переделать чтобы сварганить из этого нормальный ооп. И даже не нормлаьный.

Второй или третий день толлько туплю, что-то пишу и удаляю.

Попробую тут это словами описать, может пока описываю сам пойму чего.

Попробуй)

Появились новые особенности бизнес-логики. Описал её процедурно строк в 50-60. Но вот абсолютно не могу понять как мне её встроить имеющуюся систему. И даже как вообще всё это переделать чтобы сварганить из этого нормальный ооп. И даже не нормлаьный.

Ты что, в 20 веке? Ты должен думать о фп.

В самых общих чертах у нас есть товары и услуги. Их заказывают пользователи и оплачивают через платежи.

Это всё как бы готово было до недавнего времени.

Слишком абстрактно

Сейчас всё будет

В плане данных есть следующие модели (в смысле AR, тупо пассивные структуры): Orders OrderGoods Goods PaymentItems Payments User

Goods добавляется в OrderGoods (good_id, count). OrderGoods ссылаются на свой Order (order_id). Order ссылается на своего юзера (user_id). Order добавляется в PaymentItems (туда не только Order добавить можно). PaymentItems ссылаются на свой Payment. Payment нам важен статусом и способом оплаты.