Здравствуйте, igna, Вы писали:

I>Здравствуйте, alexeiz, Вы писали:

A>>Какие требования к этому API? Ведь не случайно же оно такое. ioctl, rpc и т.п. имеют право на существование, потому что разрабатывались с учетом специфических требований.

I>Нет к нему (пока) никаких требований.

Ну, и тогда нафиг такое не нужно. Если требований нет, то нужно извлекать пользу из максимально удобного синтаксиса, возможного в используемом языке программирования.

Иначе просто глупо получается. Зачем, скажите, передавать параметры через строчку, когда в C можно передавать параметры нормальным образом? Зачем вызывать функции через whatToDo, если C напрямую поддерживает функции?

Если нет требований, то действительно, only asses can do something like that.

На самом деле, я лично видел один раз подобный подход. Не чисто такой, как ты описал, но похожий. Вместо строчки whatToDo было числовое значение операции, вместо строчки parameters был вектор упакованный в Variant. Объяснение такому подходу было следующее: максимально расширяемый интерфейс.

В конце концов это вылилось в кучу проблем:
* интерфейс был непонятно какой, без разбора гиганского switch-а со значениями операций было невозможно понять, что там за операции (методы).
* для каждой операции было офигительно трудно найти список параметров без вгрызания в код, упаковывающий-распаковывающий эти параметры в Variant.
* программирование для такого интерфейса превратилось в (вставить-ваши-любимые-отборные-маты). Добавление новой тривиальной функции превратилось в час-два работы. После чего требовался часовой отдых для успокоения нервов.

В результате я потратил несколько дней, чтобы вывести все это дерьмо из нашего проекта и перевести все на нормальные методы C++ и абстрактные классы для явного выделения интерфейсов. К счастью обошлось без увечий.

Нашел рассуждения по поводу передачи всего объекта вместо отдельных его полей в книге The Code Complete. Нужна хотя бы не вся книга (тем более что это незаконно ), а раздел "7.5. Советы по использованию параметров метода", точнее даже кусок начинающийся словами "Передавайте в метод те переменные или объекты, которые нужны ему для поддержания абстракции интерфейса" на английском языке.

Вот про использование строк вместо перечислений там похоже ничего нет. Где взять? Где написано, что писать функцию открывающую файл на чтение при получении "r", а не чего-нибудь вроде READ, неприлично?

Здравствуйте, igna, Вы писали:

I>Нашел рассуждения по поводу передачи всего объекта вместо отдельных его полей в книге The Code Complete. Нужна хотя бы не вся книга (тем более что это незаконно ), а раздел "7.5. Советы по использованию параметров метода", точнее даже кусок начинающийся словами "Передавайте в метод те переменные или объекты, которые нужны ему для поддержания абстракции интерфейса" на английском языке.

Pass the variables or objects that the routine needs to maintain its interface abstraction There are two competing schools of thought about how to pass members of an object to a routine. Suppose you have an object that exposes data through 10 access routines and the called routine needs three of those data elements to do its job.

Proponents of the first school of thought argue that only the three specific elements needed by the routine should be passed. They argue that doing this will keep the connections between routines to a minimum; reduce coupling; and make them easier to understand, reuse, and so on. They say that passing the whole object to a routine violates the principle of encapsulation by potentially exposing all 10 access routines to the routine that's called.

Proponents of the second school argue that the whole object should be passed. They argue that the interface can remain more stable if the called routine has the flexibility to use additional members of the object without changing the routine's interface. They argue that passing three specific elements violates encapsulation by exposing which specific data elements the routine is using.

I think both these rules are simplistic and miss the most important consideration: what abstraction is presented by the routine's interface? If the abstraction is that the routine expects you to have three specific data elements, and it is only a coincidence that those three elements happen to be provided by the same object, then you should pass the three specific data elements individually. However, if the abstraction is that you will always have that particular object in hand and the routine will do something or other with that object, then you truly do break the abstraction when you expose the three specific data elements.

If you're passing the whole object and you find yourself creating the object, populating it with the three elements needed by the called routine, and then pulling those elements out of the object after the routine is called, that's an indication that you should be passing the three specific elements rather than the whole object. (In general, code that "sets up" for a call to a routine or "takes down" after a call to a routine is an indication that the routine is not well designed.)

If you find yourself frequently changing the parameter list to the routine, with the parameters coming from the same object each time, that's an indication that you should be passing the whole object rather than specific elements.

Здравствуйте, igna, Вы писали:


I>С чего бы? Под твое определение попадает случай, когда какое-то поле используется как для чтения, так и для записи; но там четкое разделение, одни поля для чтения, другие для записи.

И что тут такого-то? Посмотри спеку на любой контроллер — там такое сплошь и к ряду...

Здравствуйте, igna, Вы писали:

I>ready используется в имплементации, собственно вся структура job используется в имплементации, с точки зрения последней и succeeded с failed не избыточны, проблема в том, что все это вывешено на обозрение пользователю.

Это на С или С++ ? Если на С++ — кто мешает не вывешивать ? private и proteced не отменены даже для struct. Конструкторы тоже.

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Это на С или С++ ? Если на С++ — кто мешает не вывешивать ? private и proteced не отменены даже для struct. Конструкторы тоже.

Пример на С, хотя в действительности используется другой язык, а именно WSDL.

Здравствуйте, igna, Вы писали:

I>Ищу аргументы против API вроде следующего (пример на С, хотя в действительности используется другой язык):

На http://www.jug.ru/servlets/index посмотри презентацию Джошуа Блоха про API.
Думаю, там найдешь нужные доводы. На английском, с картинками. Даже аудио есть, кажется.