EOF: разработка поздней NeXT
В нашем случае это расшифровывается как Enterprise Objects Framework, это одна из лучших разработок поздней NeXT. Другая расшифровка EOF, end of file, имела все шансы стать пророчеством...
В начале 90-х, на NeXT заинтересовались одной проблемой, на решении которой можно было неплохо заработать. За пределами компании эту проблему считали неизбежным злом, и, похоже, даже не пытались с ней бороться.
Базы данных становились все более важным явлением. Кто владеет информацией, тот владеет миром. Соответственно, росло число систем управления базами данных. Почти у каждой из них был свой интерфейс программиста (API), свои достоинства и недостатки.
Программ, использующих базы данных, было несметное число - и раз за разом с ними случалась одна и та же неприятность. Их приходилось перерабатывать для работы с другими API и по другим правилам при подключении к системе управления базами данных (СУБД) от других производителей, и при переходе на другие (по мнению руководства, более прогрессивные или эффективные) СУБД.
Сущности (СУБД и программ, использующих СУБД) множилось, каждое подключение к другим СУБД оборачивалось немалыми финансовыми и трудовыми затратами. Статистики у меня нет, но свидетелем и участником подобных "революций" мне быть довелось. Это было безумно интересно: изучать что-то новое, пробовать, осваивать - и переписывать под это новое кучу старых программ, попутно их улучшая...
Программисты как дети, отнимать у них такую игрушку жестоко - но едва ли не треть населения мира голодает, и деньги могли бы быть потрачены на спасение голодающих, или, хотя бы, на приобретение еще одной яхты и оснащение ее системой ПРО...
Проведя несколько мозговых штурмов, и хорошенько обдумав проблему, в 1991 году в здании по адресу 900 Чесапик драйв в Редвуд Сити, в Калифорнии, приступили к решению проблемы.
DBKit
К набору "китов" в среде разработки NeXTSTEP в 1992 году добавился еще один, DBKit.
Строки таблиц в реляционных базах данных этот кит переваривал в объекты и массивы объектов. Объект - это свойства (данные) и действия (методы). DBKit брал на себя заботы об извлечении данных из базы, программы использующие эти данные почти не зависели от природы базы данных.
Почти, потому что механизм, извлекающий данные из базы данных, нуждался в настройке на работу с конкретной базой данных. Настройки на самые важные (популярные) СУБД были включены в DBKit, процесс адаптации новых и менее популярных СУБД был расписан в документации.
Если данные хранились в нескольких базах данных разной природы, не беда: при наличии адаптеров к этим базам конечный пользователь (программа!) изолировалась от подобных низменных деталей.
Этот кит рекламировался NeXT, и считался одним из ее конкурентных преимуществ. Он и был таким преимуществом, но не все с ним было так хорошо и просто.
Я почитал отзывы пользователей (считающих себя продвинутыми), среди которых было много критических. Люди спрашивали, почему в DBKit нет панели для ввода запросов и генератора отчетов, как в 4D или в Paradox, и что им теперь делать.
Вежливые сотрудники компьютерной прессы вежливо объясняли критикам разницу между набором Лего и инструментарием настоящего конструктора. На самом деле критикам надо было посоветовать нанять программиста. Или научиться пользоваться Objective-C и C.
Критики пытались создавать приложения для работы с СУБД используя исключительно Interface Builder - я бы даже не стал их за это винить. Им внушили, что создание программ в NeXTSTEP не должно быть трудным, они поверили.
Реакция умных людей была положительной, но и критики в ней хватало. Кит был далек от идеала, в нем были недоработки, в том числе и концептуальные. Он выполнял свою работу, облегчал взаимодействие с базами данных, решал многие проблемы, добавляя вместо них собственные.
DBKit можно считать разведкой боем. Теперь было понятно, каким должен быть механизм взаимодействия с базами данных.
EOF-1
Новый объектно-ориентированный интерфейс с базами данных создавался с нуля. Судя по размеру технического задания, это был супер-пупер-мегапроект, для реализации которого требовались сотни людей и отдельный офис, где-нибудь на берегу Тихого океана, где бриз и мелкий мягкий песок и пальмы.
Но разработчиков первой версии EOF было всего четверо. Вот их имена: Джек Гринфилд, Рич Вильямсон, Линус Апсон и Дэн Вилхайт. Они выполнили все требования ТЗ, и весной 1994 года Enterprise Objects Framework 1.0 поступила в продажу, за 299 долларов. Времена запредельных цен еще не наступили.
Объекты данных теперь назывались Enterprise Objects (в современном сленге это Business Objects), процесс связывания СУБД разной природы с EO был радикально переработан.
Первыми клюнули банки, быстро оценив преимущества нового фреймворка. Следующими были представители крупного бизнеса и институт военной авиации США. EOF "продавал" лицензии на OPENSTEP, как Aldus PageMaker, за 9 лет до него, продавал Mac’и.
В Enterprise Objects Framework впервые был использован Foundation Kit, фреймворк в котором объединялись классы, не имеющие отношения к пользовательскому интерфейсу, и новинка в управлении памятью, команда autorelease.
Фактически, это полуавтоматический "сборщик мусора", с ручным приводом. Самая большая трудность для новичков в объектно-ориентированной среде NeXTSTEP/OPENSTEP/Cocoa, предмет любви и преклонения для тех, кто освоился с ней. Обычно эта любовь приходила через несколько месяцев, наполненных адскими муками и скрежетом зубовным.
Нынешним программистам в macOS, iOS, tvOS, watchOS и audioOS проходить через это не приходится, но я им не завидую: легким это ремесло не бывает.
Про autorelease и управление памятью в потомках NeXTSTEP, и про их эволюцию, буду писать отдельно: очень поучительная история. С хорошим концом. В смысле, даже не концом: она все еще продолжается...
EOF-2
Естественно, в первой версии продукта были выявлены недостатки, у разработчиков не могли не появиться новые идеи, и в конце 1995 года NeXT Software выпустила вторую его версию.
Самые главные изменения в ней были связаны с планируемым, в ближайшем будущем, выходом NeXT в Интернет, с одним очень большим и амбициозным проектом, составной частью которого должен был стать этот фреймворк.
Кроме главных, были и менее масштабные.
Исправленные баги, добавленный (по просьбам трудящихся) функционал, встроенная поддержка для целой коллекции баз данных.
EOF был одним из немногих, увы, продуктов NeXT, приносивших в компанию деньги. Но число разработчиков оставалось прежним. Обновился только состав команды. Из прежней четверки остался только Дэн Вилхайт. Имена новых разработчиков история сохранила: это были Эрик Нуайо и Чарли Кляйснер. А возглавлял их Крейг Федериги.
Он был и программистом, и менеджером, и идеологом проекта. И это тот самый Федериги, который сегодня входит в состав высшего руководства Apple.
Судьба EOF
В 1996 года фреймворк стал одной из важнейших составных частей WebObjects, о которой мы поговорим в следующей статье, или в двух.
EOF, кроме того, можно было купить отдельно от WebObjects, за те же 299 долларов, до 2000 или 2001 года. В 2005 году в составе Cocoa появился его потомок, Core Data.
По моему, EOF был круче - но это мое личное мнение.
