Программирование, т. 3

не logined, а loggedin

разницы нет

 

десу~~~~

синтаксической нет, а грамматическая есть

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

Изменено 21 февраля 2013 пользователем firelord

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

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

А я люблю статические методы. Часто они пиздаче обычных методов. Когда пишешь обычные классы+ методы, то как правило в класс добавляется состояние, и класс становится statefull. В большинстве случаев это усложнение вообще не оправдано, и лучше заменить эту порожнину статик методами. У меня есть товарищи, которые на все операции любят придумывать различные классы с состоянием, а потом мучаются, создавая объекты и отслеживая ссылки на них, используют инжект зависимостей там, где можно просто передать аргумент в метод. В итоге 5 функций распухают до нескольких классов с неочевидным жизненным циклом. А еще много любителей из всего выделять интерфейсы, даже если реализация одна и больше не планируется. Подводя итог, хочу отметить, что категоричные утверждения о вреде статик методов не имеют под собой основания. Как проще поступить в конкретной ситуации - так и следует поступать. В данном случае набор статик методов в классе типа CompanyDao вполне приемлем, правда сигнатуры я бы поменял на более информативные, например GetById(id), DeleteById(id). Не обзывать метод наподобие GetCompanyById, потому что и так ясно, что этот класс содержит методы для работы с сущностью "компания".

так мы тут обсуждаем как ты любишь или как правильно?

А я люблю статические методы. Часто они пиздаче обычных методов. Когда пишешь обычные классы+ методы, то как правило в класс добавляется состояние, и класс становится statefull. В большинстве случаев это усложнение вообще не оправдано, и лучше заменить эту порожнину статик методами. У меня есть товарищи, которые на все операции любят придумывать различные классы с состоянием, а потом мучаются, создавая объекты и отслеживая ссылки на них, используют инжект зависимостей там, где можно просто передать аргумент в метод. В итоге 5 функций распухают до нескольких классов с неочевидным жизненным циклом. А еще много любителей из всего выделять интерфейсы, даже если реализация одна и больше не планируется. Подводя итог, хочу отметить, что категоричные утверждения о вреде статик методов не имеют под собой основания. Как проще поступить в конкретной ситуации - так и следует поступать. В данном случае набор статик методов в классе типа CompanyDao вполне приемлем, правда сигнатуры я бы поменял на более информативные, например GetById(id), DeleteById(id). Не обзывать метод наподобие GetCompanyById, потому что и так ясно, что этот класс содержит методы для работы с сущностью "компания".

Если мыслить со стороны что "ничего никогда не будет расширяться" можно охуенно напороться на нехуёвые грабли. К утилитным классам вопросов нет, но многие другие вещи, особенно такие как получение данных и бизнес логику делать статическими по меньшей мере недальновидно. Все эти статические методы хуй протестируешь, а код превращается в лапшу.

так мы тут обсуждаем как ты любишь или как правильно?

правильно так как ты любишь, или как любит твоя фирма

 

Если мыслить со стороны что "ничего никогда не будет расширяться" можно охуенно напороться на нехуёвые грабли. К утилитным классам вопросов нет, но многие другие вещи, особенно такие как получение данных и бизнес логику делать статическими по меньшей мере недальновидно. Все эти статические методы хуй протестируешь, а код превращается в лапшу.

у меня метод работы с базой не статичный, а как раз таки объект

и раньше я создавал сингелтоном все эти объекты, таскал их в функции и методы (ебанный пхп блять global $Company)

 

потом решил - а нахуй оно надо, когда можно просто делать статику местами?

так мы тут обсуждаем как ты любишь или как правильно?

Так как я люблю и есть правильно. велкам.

А я люблю статические методы. Часто они пиздаче обычных методов. Когда пишешь обычные классы+ методы, то как правило в класс добавляется состояние, и класс становится statefull. В большинстве случаев это усложнение вообще не оправдано, и лучше заменить эту порожнину статик методами. У меня есть товарищи, которые на все операции любят придумывать различные классы с состоянием, а потом мучаются, создавая объекты и отслеживая ссылки на них, используют инжект зависимостей там, где можно просто передать аргумент в метод. В итоге 5 функций распухают до нескольких классов с неочевидным жизненным циклом. А еще много любителей из всего выделять интерфейсы, даже если реализация одна и больше не планируется. Подводя итог, хочу отметить, что категоричные утверждения о вреде статик методов не имеют под собой основания. Как проще поступить в конкретной ситуации - так и следует поступать. В данном случае набор статик методов в классе типа CompanyDao вполне приемлем, правда сигнатуры я бы поменял на более информативные, например GetById(id), DeleteById(id). Не обзывать метод наподобие GetCompanyById, потому что и так ясно, что этот класс содержит методы для работы с сущностью "компания".

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

Кто говорит, что именно статические методы отвечают за хранение?

У меня они всего лишь абстрагированный слой над классом отвечающим за бд.

Кто говорит, что именно статические методы отвечают за хранение?

У меня они всего лишь абстрагированный слой над классом отвечающим за бд.

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

А я люблю статические методы. Часто они пиздаче обычных методов. Когда пишешь обычные классы+ методы, то как правило в класс добавляется состояние, и класс становится statefull. В большинстве случаев это усложнение вообще не оправдано, и лучше заменить эту порожнину статик методами. У меня есть товарищи, которые на все операции любят придумывать различные классы с состоянием, а потом мучаются, создавая объекты и отслеживая ссылки на них, используют инжект зависимостей там, где можно просто передать аргумент в метод. В итоге 5 функций распухают до нескольких классов с неочевидным жизненным циклом. А еще много любителей из всего выделять интерфейсы, даже если реализация одна и больше не планируется. Подводя итог, хочу отметить, что категоричные утверждения о вреде статик методов не имеют под собой основания. Как проще поступить в конкретной ситуации - так и следует поступать. В данном случае набор статик методов в классе типа CompanyDao вполне приемлем, правда сигнатуры я бы поменял на более информативные, например GetById(id), DeleteById(id). Не обзывать метод наподобие GetCompanyById, потому что и так ясно, что этот класс содержит методы для работы с сущностью "компания".

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

ты как год назад не умел читать, так и сейчас не научился.

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

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

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

ты как год назад не умел читать, так и сейчас не научился.

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

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

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

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

вы тут все сектанты какие-то е-мое

ты как год назад не умел читать, так и сейчас не научился.

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

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

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

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

хахаха, ты пиздец ))) ООП головного мозга. ну ничего, это проходит со временем.

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

хахаха, ты пиздец ))) ООП головного мозга. ну ничего, это проходит со временем.

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

как ты базу замокаешь в своем статическом методе, дебил?

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

хахаха, ты пиздец ))) ООП головного мозга. ну ничего, это проходит со временем.

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

как ты базу замокаешь в своем статическом методе, дебил?

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

ебать ты блядь вообще что ли неадекват ?

какую базу мокать ? ты че несешь ? хахаха пиздец просто

 

вот метод

static int someFunc(SomeArgument arg) {

}

 

вот юнит-тест к нему

Assert.That(5 == someFunc(argToHave5));

просто изначально речь шла о том, что у 2поя были статические методы для работы с БД, насколько я понял из его кода

class Company
{
public static function get_company($id)
{}
public static function get_all_company()
{}
public static function create_company()
{}
public static function update_company()
{}
public static function delete_company($id)
{}
public static function get_stuff($id)
{}
}

поправьте если не прав

 

вот юнит-тест к нему

Assert.That(5 == someFunc(argToHave5));

ну ты реально дебил.

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

вот юнит-тест к нему

Assert.That(5 == someFunc(argToHave5));

ну ты реально дебил.

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

ебать ты придурок бляя

при чем тут контекст ? ты путаешь статические МЕТОДЫ и статические ПЕРЕМЕННЫЕ.

статические МЕТОДЫ тестировать - одно удовольствие.

статические ПЕРЕМЕННЫЕ - не тестируемы.

 

дак вот я говорил про МЕТОДЫ.