Пропало желание кодить в ООП

Не пойму почему.
Всегда признавал только его.
Даже библию воспринимал как курс ООП для начинающих "нас создали по образу и подобию Его (Human extends GOD implements Wordable -- человек - это Бог с интерфейсом, разрешающим жить на земле)".
Всегда на все находил описание, широко применял принципы и изучил GOF.

Тем не менее, все к черту улетело. Даже на Java я не могу нормально кодить ( хотя я джавист ). Стало так: Я вижу код на Java и понимаю, что это не то, я вижу код на си и ловлю кайф. Сейчас взглянул на свои старые исходники и на исходники текущего проекта. Будто их писали разные люди. Вместо абстрактного опиания объекта с полями, я какого то фига стараюсь выстроить логическую цепочку из функций, провожу кучу проверок на валидность.
А еще я ввязался в ring0

Очень странно, что со мной будет? Ведь основные заказчики мои - те кто хочет ООП.
Наверное у меня съехала крыша.

 

похоже на то%)

 

doesn
Посоветуй врача тогда

 

четырех бандитов читал? если нет, то эта книжка тебя определенно "вылечит"

 

scf
Говорю же, читал!
И паттерны их применяю всегда

 

Может в этом и проблема? ООП - не панацея, и нужно понимать где не следует увлекаться объектами

 

У меня прямо противоположные "ночные рассуждения"...
вчера лёжа в кровати решал абстрактную задачку...

есть 100 программистов. Пишущих на асме. Скорость написания средней программы у них - одинакова. творческий потенциал, идеи - одинаковы. Кто из них заработает больше денег?
Ответ - одинаково все заработают.

Ну первый фактор - творческие идеи - отбросим... Это от бога...

А вот скорость создания программы... Что может повысить эту скорость? Понятно, большой опыт, коллекция макросов хороших...
Но вот как насчёт связки например делфи+асм?
Отбросим легенды некого адепта асма о вселенском зле...
Реально это может ускорить создание большого интерфейса - связка высокого ЯП-а и асма? Куча всяких комбобоксов, картинки, цвета, флеш на форме?

 

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

 

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

А у нас - взять голый паскаль и там ниче нет. Поэтому пишем на си. Ну Java еще как заменитель C++ работает.

Писать надо на том, на чем наиболее качественно и быстро решается задача

 

Да, и это тоже немаловажный фактор. реклама, общение с людьми... Согласен.

 

Вообще, ты прав.
Я слишком сильно делаю ЭТО.

Прикинь модель:
Есть адрес. У Адреса есть Страна, Город, нас пункт, улица, строение...
Дык я расписал: Страна не Стринг, а объект ( код страны, Имя, еще куча параметров).
У Города есть страна, значит в Адресе поля Страна быть не должно.

City->setCountry ( Country *)

Но если у города есть населенный пункт, то адресу нах не нужен город.
Все поля адреса объединились в AddressBuilder со своей Factory и объектами состояний.
В таком духе получилась целая библиотека классов для заполнения адреса.

 

ахахаа ну это все объясняет

 

Вот оно - слабое место. Идеальная модель данных должна быть иерархическим деревом, а не полным графом, т.е. не нужно увлекаться двухсторонними связями, также модель должна оставаться понятной для человека.
На практике, объект Город будет использоваться в некотором контексте (например адрес), из которого можно уже определить страну.
Поэтому в городе не должно быть поля "Страна", а должен быть Country CityDao.getCountry(City city);
Т.е. нежелательные/редко используемые обратные связи выносятся из объектной модели в DAO.
Либо (противоположный подход) модель содержит ВСЕ связи(например, при использовании Hibernate), но при этом "оптимизировать" модель недопустимо!
В этом случае я бы оставил поле Страна в адресе, то только read-only. Правда, появляется проблема модификации этого графа (нужно обновить обе стороны связи), но это решаемо.
ЗЫ: ИМХО главный критерий качества программы - программа должна быть простой

 

По моему ООП лучше применять для создания GUI и для программирования игр и т.п.
А если сувать ООП везде, то это только увеличит объем кода.

 

Или сделать у Country статические поля:

Country c = Country.getCountryFromCode ( int country_code );
/--/ getByCity ( City c ), причем в России и Штатах есть одинаковые города ( Moscow, например ), и уже City начинает
сборку по id, по указателю на город, или
Enumeration City.matchNames( String name ); ,, getByStrongName () , кстати это у меня есть, но реализовано в фабрике городов.

 

Вводить в программу класс нужно, исходя из необходимости, а не возможности его использования. Объектная модель программы не обязательно должна повторять модель, которой оперирует человек при описании целевой системы. Т.е. необязательно, чтобы в проге фигурировал класс Страна, только потому, что это понятие использовалось при описании задачи заказчиком!

ОО-код должен быть не хуже процедурного по эффективности, и в то же время лучше по масштабируемости, читабельности и т.п. Если это не так, значит код неверно спроектирован. И ООП как парадигма здесь ни при чём.

 

Вчера извращался над примерами из kernel-mode кодинга всю ночь, зато сегодня умудрился в html странице написать:


<script>
function sendText ( char * text ){
... куча кода и sprintf как апогей
}

Наверное просто заезды уже.

 

У меня, например, оно никогда и не появлялось
Считаю, что ООП оправдано только тогда, когда нужны много обьектов одного класса. А не так, как некоторые делают классы где нужно и где не нужно....

 

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

ЗЫ: мы ведь говорим об трехзвенной информационной системе с сервером приложений, который делает запросы в БД за данными?

 

А по мне, так это нормально. Я вот стараюсь избегать ООП везде, где это возможно - не нравится оно мне.