Drive your career as React Developer with Symphony Solutions!
×Закрыть
гражданин в Wargaming
  • Delphi мертвый язык?

    Именно! Здесь наследование инкапсулировано от основной системы. Для основной системы класс DB — черный ящик, предоставляющий единые методы доступа к БД, а как именно этот доступ организован, наследованием или как-то ещё от основной системы инкапсулировано.
    Если интересно, рекомендую почитать эту книгу: «Шаллоуей, Алан, Тротт, Джейм, Р. Шаблоны проектирования. Новый подход к объектно-ориентированному анализу и проектированию: Пер. с англ. —М.: Издательский дом „Вильямс“, 2002.»

    Цитата:

    Инкапсуляция — это не просто сокрытие данных. Такое слишком узкое представление ограничивает возможности проектировщика.

    Инкапсуляцию следует понимать как «любой вид сокрытия». Другими словами, это механизм, способный скрывать данные. Но этот же механизм может использоваться для сокрытия реализации, порожденных классов и много другого.

  • Delphi мертвый язык?

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

    Я дал ссылку на пример шаблона проектирования Стратегия. Вообще многие шаблоны проектирования построены на использовании инкапсуляции вместо наследования.

    Если вы понимаете, что требования неизбежно изменчивы, в том числе и на поздних стадиях проекта, то должны понимать, что в ранее написанный код будут вноситься изменения. Есть два способа на этапе проектирования предусмотреть будущие изменения: изменять реализацию классов путём наследования или инкапсулировать изменчивую часть. Конкретный пример для шаблона Адаптер. Абстрактный класс DB не только вводит единую спецификацию доступа к базе данных, но и инкапсулирует изменчивую часть от основной системы — при переходе на новую СУБД основная система не затрагивается вообще.

  • Delphi мертвый язык?

    Штопор лучше отвертки, двери дыр, а в природе всего есть определение ничего? Дайте еще пыхнуть, мистер Андерсон. Вы о чем?

    Я о том, чего катастрофически не хватает многим кодерам — понимания пройденного при обучении или прочтённого в Википедии. При появлении нового функционала они без зазрения совести наследуются, хотя правильно было бы инкапсулировать. Не в узком смысле приведенного определения инкапсуляции в языке программирования, а на уровне анализа и проектирования.
    Для тренировки, попробуйте здесь найти инкапсуляцию и понять чем она лучше наследования (только не ищите в примерах кода!!!).

    Если Вы под инкапсуляцией понимаете только объявление приватных методов, для кодера это не страшно и нормально. Но такое понимание недопустимо для аналитика и архитектора.

  • Delphi мертвый язык?

    А множественное наследование прекрасно заменяется инкапсуляцией вместо неоднозначностей.

    Золотые слова!

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

  • На чем разработка быстрее.NET или Java?

    Угу. Начальник склада с месячным знанием Делфи напишет программу лучше и быстрее чем программист без знания складского учета. Угу.

    Да, угу. Конечно же шарообразную программу в вакууме программист напишет лучше и быстрее начальника склада. Но программу складского учёта без знаний в области логистики и учета программист не напишет в принципе.

    И не доводите до абсурда. Дурак любую хорошую идею превратит в маразм и лоб расшибет. Все же я не утверждал, что НЕпрограммист напишет программу лучше программиста. Я говорил, что ее сможет написать программист (и не только, см. ниже), знающий предметную область, даже если он посредственно знает среду разработки.

    Брехня!!!. На 1С всё СНГ программисты кормятся, не видел ни одного живого бухгалтера, что бы программировал на 1 С. А вот програмерам надо изучать предметную область, согласен.

    Интересно, а Вы видели такого программиста , который бы не знал предметную область??? Это ужасно неудачный пример, т.к. 1С-ники — прикладные программисты, для которых отсутствие знаний в области бухгалтерии (т.е. предметной области) главный признак профнепригодности.
    Нужны живые примеры? Знаю председателя одного из районных судов г. Донецка, который собственноручно на Access (параллельно его осваивая) за пару месяцев наваял программное обеспечение автоматизации документооборота своего суда и внедрил его в реальную работу. Это без отрыва от основной деятельности по рассмотрению судебных дел и управлению судом. А потом освоил тот же Делфи для разработки новой, более совершенной версии. Знаю председателя одного районного суда г. Днепропетровска, который непосредственно руководил разработчиками, они успешно автоматизировали его суд и несколько других, используя IBM Lotus.

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

  • На чем разработка быстрее.NET или Java?

    Проверено многократно. Пофиг какая среда разработки. В скорости выигрывает тот, кто хорошо знает и понимает предметную область, даже если знания среды разработки (языка) посредственные.
    Гуру программирования, не желающие вникать в предметную область, частенько увлекаются бессмысленным программированием (код ради кода), а программировать надо предметную область.

    Поэтому даже на самом «лучшем» языке можно писать проект много дольше, чем на самом «худшем».

  • Delphi мертвый язык?


    Це все викликає лише посмішку.
    Так само, як і проект на Делфі (Нумератор), яким автор дуже пишається.:)

    Ну что Вы, автору вполне есть чем гордиться, кроме этой поделки выходного дня. Просто пример яркий. Дело в том, что он был не один.

    Якщо комусь цікаво — компонент на C#, що робить набагато більше
    Очень интересно. Что он делает много больше? (это без ехидства, реально интересно)
    Судя по диаграммам, подход к решению у нас одинаковый.

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

    Вам не нужен юникод,

    10 лет как писаный мной редактор работает с юникодом, а я не знал, что в Делфи юникода нет... Впрочем, если это про интерфейсные элементы, но на текущий момент уже и это неправда.

  • Delphi мертвый язык?

    История про то как с Delphi на.NET (C#).
    Будучи представителем заказчика, представителям компании разработчика (крутой компании-разработчика) на C# реально задолбался писать требования и рисовать интерфейс — не в коня корм. Решил накидать прототипы в Delphi. Каждый прототип у меня занимал от 1 до 3 рабочих дней. Прототип не только интерфейса, но и отчасти работал бизнес-функционал (глубина реализации бизнес-функций от 20 до 90%).
    В том числе, долго просил сделать настраиваемый нумератор документов, в ответ «два месяца». За два дня накидал на Delphi работающий прототип с правильно спроетированными классами нумератора, ориентированными на бизнес-логику.
    Получив прототип, два программиста на C# делали это (фактически — повторяли) месяца полтора...
    Недавно, потратив три вечера, я из спортивного интереса довел прототип до полноценно реализованной подсистемы, готовой к повторному использованию в любых проектах, в которых что-то нумеруется способом, отличным от простого номера по порядку (как правило, документы).
    Подробности тут:
    armor.kiev.ua/wiki/index.php title=%D0%A3%D1%87%D0%B0%D1%81%D1%82%D0%BD%D0%B8%D0%BA: ArmorAdmin/%D0%9D%D1%83%D0%BC%D0%B5%D1%80%D0%B0%D1%82%D0%BE%D1%80
    Кто считает, что Делфи хорош только рисованием формочек, тот с ним, скорее всего, полноценно и не работал.
    Вот, например, сделайте на.NET что-то вроде этого armor.kiev.ua/wiki/index.php title=%D0%A2−64_%28CD, _2005%29, чтобы юзер вставил диск и сразу начал с ним работать без установки десятков, а иногда сотен, мегабайт самого последнего фрейворка, который ему на компе ну просто необходим как воздух (с точки зрения программера, конечно). Кстати, ссылку дал не просто так, при просмотре текстов используется полноценный текстовый RTF-редактор (в режиме чтения), написанный на Delphi в 1999−2001 гг. без использования rich-библиотек от Мелкософта, только Паскаль, ассемблерные вставки и WinAPI.
    P.S. Споры о том, какой язык лучше, из разряда религиозных, поэтому я в них не участвую. Но поработав несколько последних лет в проектах на.NET, у меня выработалось к этой технологии стойкое отвращение. Может быть потому, что среди многих десятков программистов си-шарпников знаю только двоих, которые думают не уровнем технологий, «фич» и «библиотек», а вникают в проблемы пользователей, для которых пишут код.

    P.P. S. Единственная толковая программа, которая мне известна на.NET, это Paint.NET.

  • Период застоя

    Нет, я сегодня регистратора сменил

  • Период застоя

    Полгода — фигня, это не застой: -)
    Поддерживаю совет eugene_n сделать поделку выходного дня. Лучше, чтобы это был небольшой, но полноценный проект с этапом постановки задачи и проектирования архитектуры, а уже потом кодинг.

    Я недавно после 2−3-летнего перерыва решил возобновить навыки по программированию и получилось вот это: armor.kiev.ua/wiki/index.php title=%D0%A3%D1%87%D0%B0%D1%81%D1%82%D0%BD%D0%B8%D0%BA: ArmorAdmin/%D0%9D%D1%83%D0%BC%D0%B5%D1%80%D0%B0%D1%82%D0%BE%D1%80

← Сtrl 1... 789101112 Ctrl →