В поисках совершенных абстракций

[pu4koff]

Сообщение от atomicxp

Здесь как бы разные варианты есть. Можно считать стандартной библиотекой STL, а можно Qt SDK, или вообще, что-либо другое. Суть не в них, а в собственных понятиях. Если рассматривать файл как набор байт с доступом по индексу, то он таким и будет. Если надо разложить его на биты, то это уже будет битовый файл. Можно получать доступ по итератору, но итератор это не последовательность, а проход по чему-либо что можно так представить.

А может я хочу рассматривать файл как набор символов в кодировке юникода по два байта на один символ или ещё как. Важно не то, как сделать ту или иную операцию на конкретной библиотеке, важно сформировать абстракции позволяющие делать весь спектр операций с минимальной сложностью.

Хочу то, пока не знаю что?
Вообще файл по своему определению не должен знать что он хранит. Это тупое хранилище и всё. Посмотрите на различные реализации сериализации и шаблон DataMapper

[atomicxp]

Сообщение от pu4koff

Хочу то, пока не знаю что?

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

Сообщение от pu4koff

Вообще файл по своему определению не должен знать что он хранит. Это тупое хранилище и всё. Посмотрите на различные реализации сериализации и шаблон DataMapper

Посмотрел, смешение insert, delete и update. Insert и delete для меня это addition и subtraction, так же operator+ и operаtor-. В данном случае прослеживается нарушение абстракции, так как обновление завязано на тип элемента. Если у тебя ещё есть примеры приводи не стесняйся. Свои я скорее всего выведу просто видоизменив до нужной мне степени чужие.

[pu4koff]

Вообще основная суть DataMapper'a не в insert, update и т.п.
С одной стороны от преобрабзователя лежат данные, которыми оперирует приложение (классы, записи,...), а по вторую сторону - хранилище данных (файл, база данных,...). Этот самый DataMapper просто преобразует данные из вида, в котором они хранятся, в вид, в котором они обрабатываются и наоборот. Так что все эти insert'ы и update'ы легко выносятся в свою "абстракцию"

[atomicxp]

Сообщение от pu4koff

Этот самый DataMapper просто преобразует данные из вида, в котором они хранятся, в вид, в котором они обрабатываются и наоборот. Так что все эти insert'ы и update'ы легко выносятся в свою "абстракцию"

Ну не знаю, я встречался с DataAdapter'ом в .NET. Ещё со строгой типизацией. В других система навроде Qt используют MVC. Вот конкретно этот датамапер я не хочу никуда выносить, от таких абстракций у меня всегда возникало больше проблем, чем пользы.

[mustaf0id]

По способу доступа к данным файл можно рассматривать как блок с произвольным доступом (напр. Memory mapped file) или поток данных (те же stream-ы в STL), кстати и сокеты тоже рассматриваются обычно как поток данных.

Вопрос папки они или директории очень важен, так как директории по смыслу являются направляющими и представляют весь путь к директории или файлу, а вот папка она как сущность хранящая что-то внутри себя.

Можно просто считать файловую систему деревом с файлами в листьях.

[MaTBeu]

кстати и сокеты тоже рассматриваются обычно как поток данных

Эммм откуда ж такие сведения?

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

[atomicxp]

Как бы понятно, что есть потоки данных, средство которое объединяет в себе работу с файлами, памятью, сетью и так далее. Есть и другие потоки, которые не вышеупомянутые потоки, а нити процессов. Для примера код из вики плюс откомпилированная версия для Windows.

#include <boost/thread/thread.hpp>
#include <iostream>

using namespace std;

void hello_world()
{
    for(int i = 0; i < 1000; i++)
    {
        cout << "Hello world!!! ";
    }
}

void hello_galaxy()
{
    for(int i = 0; i < 1000; i++)
    {
        cout << "Hello galaxy!!! ";
    }
}

int main(int argc, char* argv[])
{
  // запустить новый поток, вызывающий функцию "hello_world"
  boost::thread my_thread1(&hello_world);
  // запустить новый поток, вызывающий функцию "hello_galaxy"
  boost::thread my_thread2(&hello_galaxy);
  // ждем завершения потоков
  my_thread1.join();
  my_thread2.join();

  return 0;
}

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

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

[mustaf0id]

Сообщение от MaTBeu

Эммм откуда ж такие сведения?

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

Согласен, именно сокеты SOCK_STREAM я и имел в виду

А что если надо взять данные, но не в прямом порядке, а в обратном, или брать их в несколько потоков с взаимоисключением для передачи по разным соединениям чем-то с чем-то.

Фактически это будут разные видов data-mapper-ов, или нет?

[atomicxp]

Сообщение от mustaf0id

Фактически это будут разные видов data-mapper-ов, или нет?

Смысла нет так делать. Я думаю надо создавать полиморфные интерфейсы, одним из которых может стать поток данных. Впрочем если у кого-то есть идеи лучше выкладывайте.

[BaronTreep]

Кстати, раз речь идет об ООП языках, какой язык был первым использовавшим ОО парадигму? По моему это SmallTalk. И как обычно бывает - первый язык, пионер так сказать, содержал идеи которые нашли применение гараздо позже. Другой такой пример - Lisp, вот где целый "сундук" "совершенных абстракций", которые пока очень меедленно входят в современное программирование.

Вот в обычных императивных языках бывают ПРОСТО ЧИСЛА, или ПРОСТО СЛОЖЕНИЕ, т.е. не объекты и методы, а просто представления машинных структур, ячеек памяти, и команд процессора - ближе к ассамблеру скорее, зато эфективно.

В SmallTalk вовсе нет ничего ПРОСТО, число - это экземпляр класса, у класса объявлены методы арифметики, присваивания, булевы методы и т.д., поэтому число наследует эти методы и для него определены соответствующие операции.

Вот и в Ruby например, по примеру SmallTalk такие опарации, как + - * / - это просто методы числовых классов. Т.е. код

x = a + b + c  (*)

Это на самом деле соглашение для упрощения записи

x.= a.+ b.+ c

или, ещё точнее:

x.=(a.+(b.+(c)))

Если заменить привычные знаки на имена функций, то имеем:

x.setq(a.add(b.add(c)))

То что эта композиция функций может быть сведена к (*) без потери информации - это связано с тем что композиция полностью каррирована, т.е. все функции от одного аргумента, и что операция сложения ассоциативна.

Если код

x = a + b + c

интерпретируется как

x.setq(a.add(b.add(c)))

это значит имеет место левое связывание методов с объектами, но ни что не мешает написать например, ближе к функциональному стилю:

(x, y).setq(a.add(b.add(c)), m.add(f, g))

что эквивалентно

x, y = a + b + c, m + (f + g)

Тут скобки уже не арифметические а функциональные.

В лиспе наоборот методы связываются с объектами направо:

(= x (+ a (+ b (c)))

Если определить в С связывание направо, то ничего не мешает писать "как на лиспе":

=.x(+.a(+.b(c)))

И наоборот префиксное выражение в лиспе может быть записано в инфиксной форме

(x.= (a.+ (b.+ (c)))) ;;; x = a + b + c

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

НО запись в процедурном стиле, если её расписать в граф. нотации - это просто линия, т.е. вырожденное дерево. А вот фун. запись это именно дерево. Примечательно что языки которые сейчас появляются (это и D и Nemerle и Scala) стремятся использовать и функциональное программирование, и ООП. кажется что единственной целью может быть только удобство программирования.