Книга по клиент - серверным БД.

← →
Danilka © (2006-04-14 16:51) [80]

[78] Суслик © (14.04.06 16:47)
> Пойми, это форма записи

Дык, возьми листочек и попробуй расписать :)

← →
Суслик © (2006-04-14 16:54) [81]

> [80] Danilka © (14.04.06 16:51)
> [78] Суслик © (14.04.06 16:47)
> > Пойми, это форма записи
>
> Дык, возьми листочек и попробуй расписать :)

Этта. Ты понимаешь, это как язык разговора - он другой, ну и что? Это не значит, что говорится о неясных мне понятиях. Т.е. определенный факт деятельности был записан в форме гаап. А ты пиши его сразу в нашей форме. В МСФО важна не форма, а суть проводок.

> [79] Игорь Шевченко © (14.04.06 16:50)

Нормально у меня все с проектированием :) Требуется, конечно, рефакторинг. Ну а разве есть системы, где он не нужен? Не думаю.

---------
По поводу ООП. С чего это такие сомнения? Чем ООП не угодил.

← →
Игорь Шевченко © (2006-04-14 16:59) [82]

Суслик © (14.04.06 16:54) [81]

> Нормально у меня все с проектированием :)

Прочитай собственные предыдущие посты и усомнись в этом факте.

> По поводу ООП. С чего это такие сомнения? Чем ООП не угодил.

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

← →
Суслик © (2006-04-14 17:06) [83]

Этта, качество моего проектирования скорее тема не для форума. Тут все равно ничего не докажу :)

> ООП тоже не является серебряной пулей. Грубо говоря, не
> всякая задача может быть легко и просто представлена в виде
> компактной группы прозрачно взаимодействующих объектов.

А кто тебе говорил, что она должна быть компактной и прозрачной? Собственно я тоже так раньше думал - с ООП все должно быть просто. Потом почитал книжку Буча. Меня поразили его слова - если кто-то считает, что с объектами станет жить проще, то он заблуждается и несильно понимает суть ООП. Сейчас не помню в точности что он говорил по поводу того, что нужно понимать в ООП, если интересно посмотрю.
Мое же мнение, что ООП дает возможность масштабируемости решения (это не все, конечно, но это то, что пришло на ум). Т.е. когда ты загоняя логику в определенные границы, диктуемые библиотекой классов можешь сколь угодно развивать использование библиотеки вширь. API (набор необъектных функций) в этом смысле дают рядовому работнику-разработчику куда большие возможности пойти на лево от заданного курса партии. Оно тебе надо? А написав однажды серьезную ООП библиотеку, желательно с принципом Голливуда (не звоните, мы вам сами позвоним), ты ограничиваешь фантазию работника. Можешь брать хоть 100 чел - они будут писать так, как тебе нужно.

← →
Marser © (2006-04-14 17:11) [84]

Уже второй год у увлечением читаю тематические диалоги ИШ и Суслика. Спасибо, господа, очень интересное и полезное чтение. Я серьёзно.

← →
Игорь Шевченко © (2006-04-14 17:29) [85]

Суслик © (14.04.06 17:06) [83]

> А кто тебе говорил, что она должна быть компактной и прозрачной?
>

Ну это как бы один из способов достижения масштабируемости :)

> А написав однажды серьезную ООП библиотеку, желательно с
> принципом Голливуда (не звоните, мы вам сами позвоним),
> ты ограничиваешь фантазию работника

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

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

> API (набор необъектных функций) в этом смысле дают рядовому
> работнику-разработчику куда большие возможности пойти на
> лево от заданного курса партии. Оно тебе надо?

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

← →
Суслик © (2006-04-14 17:38) [86]

> Оно мне пофиг, если код выполняет свою задачу и сопровождабелен.

Но не может быть таковым, если каждый из 100 человек пошел налево :)
ИМХО.

> тебе вообще не нужно 100 разработчиков - продвинутый генератор
> исходного кода и все задачи решены

Заменить человека, вернее его мозг, пока невозможно. ИМХО. Можно только дать человеку интсрумент с богатыми возможностями, который все же "ведет" человека по заданному курсу, который диктуется твоей библиотекой.
Примерно по этому принципу устроены многие сервера приложений. Человек пишет сервлет (плугин). Сервер же данный сервлет выполняет предоставляя сервлету богатые (иногда очень и очень) инструменты. При этом сервлет не может делать то, что ему захочется - даже в файл записать ничего не сможет, а вот воспользоваться готовым (и очень навернутым) механизмом распределенных транзакций - запросто.

← →
Игорь Шевченко © (2006-04-14 17:56) [87]

Суслик © (14.04.06 17:38) [86]

Я несколько поясню, о чем речь в разговорах про "серьезную библиотеку". Вот возьмем, к примеру, Delphi - инструмент компонентной разработки. Много ли ты видел наборов компонент, относящихся к задачам какой-либо предметной области ? Обычно ведь задачи в областях более или менее одинаковые, по крайней мере, домены предметной области. Даже тот же ECO - это всего лишь механизм.

Вот мне стало интересно (я наборов компонент для предметных областей честно не видел), почему для интерфейса с пользователем или с базами данных или с внешними мирами наборы компонент есть, а для предметных областей - нету ? Может не везде ООП так уж победно шествует ? :)

> Но не может быть таковым, если каждый из 100 человек пошел
> налево

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

> Заменить человека, вернее его мозг, пока невозможно. ИМХО.
> Можно только дать человеку интсрумент с богатыми возможностями,
> который все же "ведет" человека по заданному курсу, который
> диктуется твоей библиотекой.
> Примерно по этому принципу устроены многие сервера приложений.
> Человек пишет сервлет (плугин). Сервер же данный сервлет
> выполняет предоставляя сервлету богатые (иногда очень и
> очень) инструменты. При этом сервлет не может делать то,
> что ему захочется - даже в файл записать ничего не сможет,
> а вот воспользоваться готовым (и очень навернутым) механизмом
> распределенных транзакций - запросто.

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

← →
Суслик © (2006-04-14 18:04) [88]

Игорь, наверное ты меня превратно понял. Поясню. Сначала напомню о чем речь - о ООП и о его ценности. Мы же это стали обсуждать?

В [74] я сказал, что в том же j2ee много сделано, но есно не для бухучета, а вообще для серверных приложений. При том, что j2ee все же диктует определенный подход к работе.

Я хочу сказать, что с ООП диктовать общий подход к работе проще, чем без него. Т.е. в ООП можно написать среду разработки, в который ТЫ сидишь, и которая по сути к тебе обращается. В API же ты САМ решаешь что и когда использовать и можешь решить это делать не так, как хочет твой начальник.

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

Ясно, что за людьми можно следить. Но ты знаешь, мне еще и работать самому хочется, а не по коду чужому лазить.

Конечно, можно и без ООП сделать такую же среду, кто спорит (процессор же не знает о ООП). Но зачем велик изобретать - есть ООП, с ним делать среды разработки проще (уверен). Поэтому для меня ООП это хорошо.

Суслик © (14.04.06 18:04) [88]

> Игорь, наверное ты меня превратно понял. Поясню. Сначала
> напомню о чем речь - о ООП и о его ценности. Мы же это стали
> обсуждать?

Вот тот же Буч, он в своей знаменитой книге применяет ООП не для создания механизмов, а для решения задач предметной области.
Например, графического редактора - кстати, очень удобно с помощью ООП, или автомата полива теплицы.

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

Но это механизм. Грубо говоря, тебе вместо одного молотка дали более удобный, но гвозди все равно ты сам забиваешь.

> Я хочу сказать, что с ООП диктовать общий подход к работе
> проще, чем без него. Т.е. в ООП можно написать среду разработки,
> в который ТЫ сидишь, и которая по сути к тебе обращается.
> В API же ты САМ решаешь что и когда использовать и можешь
> решить это делать не так, как хочет твой начальник.

> Но зачем велик изобретать - есть ООП, с ним делать среды
> разработки проще (уверен).

Зачем что-то рисовать, если можно скопировать
Зачем что-то копировать, если можно обвести
Зачем что-то обводить, если можно вырезать и наклеить.

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

> Зачем делать среду разработки вместо того, чтобы решать
> конкретные задачи на купленной среде разработки.

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

Книга по клиент - серверным БД. Найти похожие ветки