Интерфейс - передача класса или интерфейса в параметр в чем разница?

[WMix]

мы еще держим в src второй namespace где аппликацию как программную оболочку рассматриваем (скелет), но хотим тоже отдельной приватной библиотечкой через composer сделать: большого смысла нет правда. если ты про request обьекты, то какая же эта инфраструктура?
у нас фронт тоже на js, поэтому не понял о каких формах ты.

 

[StalkerClasses]

В 8ке они появились, но в типичном для php недоделанном виде и не полностью могли заменить пхпдок со вложенностями. Поэтому лучше сразу начинать с 8.1, там допилили.
Попку Utllits лучше называть Infrastructure и делать её со вложенностями, например элементы для форм, валидаторы, библиотеки для работы с базами и т.д. А не плоскую универсальную мусорницу, как делают в говнопроектах.

А где написано что это должно быть не Utllits? А Infrastructure?
Можно пример как в 8.1 теперь аннотации задаются и что там уже можно использовать вместо /**?

 

[StalkerClasses]

Могу одну идею закинуть в php9

 

[AmdY]

А где написано что это должно быть не Utllits? А Infrastructure?
Можно пример как в 8.1 теперь аннотации задаются и что там уже можно использовать вместо /**?

В большой синей книжке Эванса, которую здесь 100500 раз обсуждали.

User Interface (or Presentation Layer) Responsible for showing information to the user and interpreting the user's commands. The external actor might sometimes be another computer system rather than a human user. Application Layer Defines the jobs the software is supposed to do and directs the expressive domain objects to work out problems. The tasks this layer is responsible for are meaningful to the business or necessary for interaction with the application layers of other systems. This layer is kept thin. It does not contain business rules or knowledge, but only coordinates tasks and delegates work to collaborations of domain objects in the next layer down. It does not have state reflecting the business situation, but it can have state that reflects the progress of a task for the user or the program. Domain Layer (or Model Layer) Responsible for representing concepts of the business, information about the business situation, and business rules. State that reflects the business situation is controlled and used here, even though the technical details of storing it are delegated to the infrastructure. This layer is the heart of business software. Infrastructure Layer Provides generic technical capabilities that support the higher layers: message sending for the application, persistence for the domain, drawing widgets for the UI, and so on. The infrastructure layer may also support the pattern of interactions between the four layers through an architectural framework.

 

[Squats]

StalkerClasses, в ООП количество if должно стремится к нулю.

Ага и напиши костыль, который никому не будет понятен.
Это ты так узнал, про существование FSM ?
Теперь сетуешь не писать if-else ?
Ну тогда зачем нам циклы, если есть map/reduce и т.д. да?

 

[StalkerClasses]

В большой синей книжке Эванса, которую здесь 100500 раз обсуждали.

Сори что за книжечка и есть ли аналог на русском???

 

[StalkerClasses]

В большой синей книжке Эванса, которую здесь 100500 раз обсуждали.

Сгораю от нетерпения что за книга???

 

[fixxxer]

Сори что за книжечка

Domain-Driven Design: Tackling Complexity in the Heart of Software: Evans, Eric: 8601300201665: Amazon.com: Books

Domain-Driven Design: Tackling Complexity in the Heart of Software [Evans, Eric] on Amazon.com. *FREE* shipping on qualifying offers. Domain-Driven Design: Tackling Complexity in the Heart of Software

www.amazon.com

на русском???

Книга

В наличии Книга

www.ozon.ru

 

[StalkerClasses]

Мне ещё очень понравились идёт чистого кола например что лучше без else

 

[Valick]

Странное дело, Зандстру тебе рано читать, а Эванса в самый раз. Возварщяемся ктому с чего начали.
DDD это всего лишь надстройка над ООП (грубо говоря некий свод правил как нужно писать код, что бы использовать такой мощьный инструмент как ООП и не говнокодить), не понимая филосовии объектов, ты и на DDD будешь "процедурить".

 

[grigori]

самое важное, что нигде не написано, но с чего надо начинать:
Ни компьютерам, ни бизнесу низкоуровневая архитектура не нужна вообще.
Приложения не зависят от классов, интерфейсов, аннотаций и исключений. Совсем. Архитектура в коде существует только для самих разработчиков, и ни для кого больше.
Проекту надо, чтобы в момент возникновения важной ошибки уведомление дошло до дежурных и технических руководителей. Это единственное, что надо бизнесу.
Соответственно, напишешь ты с исключениями или с triger_error, по SOLID или лапшой - работать он будет одинаково. А когда код работает, мы, программисты больше не нужны, и платить нам больше не нужно.
Соответственно, вся эта архитектура появляется только там, где есть большая конкуренция, много денег, и планы на 5 лет вперед.

 

[grigori]

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

А зачем же мы так много обсуждаем архитектуру? Есть места, где без нее проекты умирают, и только там за правильную архитектуру платят. Получается, что мы все в этих местах, хоть их и мало.

 

[grigori]

чем аннотации в PHPDoc отличаются от классов - ничем, просто авторы Symfony притащили в язык привычный синтаксис
чем исключения отличаются от ошибок - ничем, просто в PHP добавили синтаксис из java
чем анонимные функции отличаются от анонимных классов - ничем, из них создаются обычные объекты, просто кому-то захотелось, а остальные не против

 

[AmdY]

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

Ай, это как любители писать без фрейворков не догоняют, что они всё равно придут к написанию своего фреймворка, только худшего качества и с кучей набитых шишек.
Если ты не продумываешь заранее архитектуру, то она всё равно появится, только кривая и придётся переписывать когда заходит в тупик.
В своё время ходил и общался с ребятами из стартап тусовок, там у ребят недостаточно опыта и знаний, потому 9 из 10 проектов делаются в хаотическом стиле и почти 100% их прогорает. Но остальные 1 из 10 изначально делают стартап как бизнес, с продуманной архитектурой и поставленными бизнес процессами и почти 100% их взлетает.

 

[c0dex]

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

Штук так овер 10+ было, сейчас смотрю на код и плачу)

 

[grigori]

97% стартапов прогорает именно потому что с кодом успех вообще не связан, и алгоритмов успеха не существует.
Бизнес жив пока ему платят. Когда бизнес смог наладить постоянную продажу чего угодно как угодно - он будет жить, а 97% этого сделать не могут.
Но когда в 3% случаев продажи налажены, и надо добавлять фичи - вот тут начинается архитектура.
С 97% вероятностью совершенно неважно как написан код в стартапе.

 

[MiksIr]

Но когда в 3% случаев продажи налажены, и надо добавлять фичи - вот тут начинается архитектура.
С 97% вероятностью совершенно неважно как написан код в стартапе.

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

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

 

[WMix]

на самом деле, @grigori прав, просто мы работаем в сложившихся startup

 

[c0dex]

на самом деле, @grigori прав, просто мы работаем в сложившихся startup

А в 0.001% - это у нас, дофига задач, и нехватка кадров)

 

[WMix]

0.001%

а че так мало?