«phpClub» — архив тем ("тредов"), посвящённых изучению PHP и веб-технологий.
Аноним 2019/03/03 09:52:51  №1358262 1
Ответы: >>1358320 >>1369058
Аноним 2019/03/03 11:20:39  №1358320 2
>>1358262
Чому тайп хинтинг не используешь? Захардкоженные названия профессий тоже не оч хорошо
Ответы: >>1358386
Аноним 2019/03/03 13:01:30  №1358386 3
>>1358320
по поводу тайп хинта понял, а что с названиями не так?
Ответы: >>1358490
Аноним 2019/03/03 14:07:05  №1358490 4
>>1358386
Я бы добавил константы и в свитчах использовал бы их
switch($this->profession) {
case self::MANAGER итд
Аноним 2019/03/23 20:15:46  №1369058 5
>>1358262

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

>>1358554

> https://3v4l.org/NSVsb - задача про зарплату
overtime должен вычисляться автоматически. Все, что больше 40 часов в неделю - переработка.

> https://3v4l.org/4GGth - задача про вопросы
Тут можно было ставить тайп-хинт на возвращаемое значение:

> public function checkAnswer($answer): bool

А так, все верно.

> https://3v4l.org/3avqA - задача про Вектор

В качестве названий профессий можно было использовать константы-имена классов вроде Manager::class: http://php.net/manual/en/language.oop5.constants.php

addEmployees лучше бы вынести наружу из Департамента, так как это не позволяет создавать новые профессии, не трогая существующий код. Ну например, если твои классы будут оформлены в виде библиотеки, которую делает один человек, то другой человек, который ей пользуется, не сможет добавлять свои профессии. Случай, конечно, немного придуманный, но надеюсь, смысл передает. У тебя класс Department сейчас по сути содержит захардкоженный список возможных профессиий. А это не его зона ответственности - знать, какие профессии есть.

> public function getInformation(): array {
Мне кажется, было бы удобнее сделать несколько отдельных методов, но можно и так. Но name и employeesCount точно надо вынести отдельно. Так как неудобно будет их получать и никакой экономии от помещения их в этот метод мы не получаем.

Если доводить до абсурда, то мы тогда можем сделать в любом классе 2 метода setInformation и getInformation и работать со старыми добрыми массивами. Это не очень удобно, и в плане получения данных (надо извлекать их из массива), и в плане кода (все собрано в одном огромном методе).

Класс Table правильнее назвать TablePrinter, TableFormatter, так как он не представляет информацию о таблице.

А вообще хорошо, меня радует, что и у нас в треде, да и вообще в программистском сообществе стали лучше понимать ООП. А не как раньше, когда все сидели на CMS и городили жуткие конструкции на многомерных массивах.