Про ООП долбоебизм 21 |
[Jul. 29th, 2009|07:03 pm] |
$slots=Slot_Collection::loadReadytoFree(); foreach ($slots as $slot) { $slot->setFree(); }
На первый взгляд всё логично. вытащили некую совокупность объектов. прошлись по каждому -- дёрнули метод.
А вот какой секрет кроется под "инкапсуляцией":
function loadReadytoFree() { SELECT * FROM slots WHERE type=4; }
function setFree() { UPDATE slots SET type=0 where id=this->id; }
Ну не шыдевр ли бля!? ИНКАПСУЛЯЦИЯ В ПОЛНЫЙ РОСТ |
|
|
Comments: |
Вспоминается классический алгоритм:
если( в чайнике есть вода ) Вылить воду из чайника; Налить воду в чайник; Поставить чайник на огонь;
И заметьте, никакой инкапсуляции и никакого ООП.
From: | max630 |
Date: | July 30th, 2009 - 03:49 am |
---|
| | | (Link) |
|
А что? Если не критичный по производительности код - самый правильный способ, кто знает, как завтра будут реализованы эти функции.
отвечаю на вопрос "кто знает?".
Знает програмист -- автор программы. ООП обизянка нихуя (естественно) не знает.
Вообще (если серьёзно) эта классическая постановка вопроса про "как эти функции завтра" -- ложная постановка -- её пораждает сам ООП. Убираете ООП и уходит сама проблема.
From: | max630 |
Date: | July 30th, 2009 - 07:02 am |
---|
| | | (Link) |
|
Дада, а потом человек смотрит на, например, исходники gjots2 и видит что там работа с файлами идёт прямо из гуя. Или, наоборот, в mutt все процедцры обработки не парясь сами печатают вопросы пользователу и читают его ответы.
вы хотите сказать (SQL не является удобным, отлаженым и стабильным интерфейсом к безе данных)? смелое утверждение.
или вы считаетео (без ООП невозможны абстракции)? ещё более смелое утверждение.
From: | max630 |
Date: | July 30th, 2009 - 07:31 am |
---|
| | | (Link) |
|
1a. Вопрос про удобство SQL тут офтопичный, но что он может быть изменён на какой-нибудь другой - вполне вероятно. Хотя бы для тестирования. 1b. Кто сказал что в данных реализациях не появится дополнительных действий? Например по логированию.
2. Темой поста является именно абстракция, независимо от способа реализации.
это узкий взгляд не проблему. то, что пишется "на века" - потом очень трудно модернизировать. сталкиваюсь с этим постоянно. обычно стараюсь писать как можно более легко модернизируемый код, если это внутренний проект компании. если что-то "для клиента" - там как правило свои требования. | |