Re[4]: Что-то нетак с ООП
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 21.01.12 01:45
Оценка: 1 (1) +1
Здравствуйте, Eye of Hell, Вы писали:

A>>К сожалению повторное использование классов затруднительно из-за большого количества завсимостей между оными. Вы можете использовать либо всё, либо ничего. Без понимания внутренних зависимостей классов (какой класс из какого когда и что вызывает) не обойтись.


EOH>Такое бывает при неправильном использовании классов и отсутствии архитектуры. Обычно используется высокоуровневая архитектура приложения, которая однозначно определяет как связываются между собой части программы. Для примера посмотрите как построен Qt Creator — он ольшой, в нем сотни классов, но при этом связи между ними прозрачны. Потому что архитектура, сигналы и слоты.


А ну-ка, выдерни из Qt какой-нибудь приличный класс, тот же QPainter и заюзай его без самой Qt. Что, скажешь, что у Qt архитектура отсутствует?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[2]: Что-то нетак с ООП
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 21.01.12 02:07
Оценка:
Здравствуйте, Son of Northern Darkness, Вы писали:

A>>И почему такая уверенность, что так и надо делать? Как им вдолбить простую истину, высказанную к сожалению не помню кем, что хороший код, это не тот код, в который нечего добавить, а код, из которого нечего выкинуть?


SON>Это не правда. Хороший код, это код в который можно расширить, не переделывая уже сделанную работу или переделывая минимально.


Ошибка. Расширить код, не переделывая его, возможно только при одном условии: что такие расширения были предусмотрены изначально. Иначе ты просто путаешь интуитивное восприятие "расширяемости" с фактическими действиями ради её воплощения.

SON>Вот за этим ООП и нужно.


Это распространённый миф. Расширяемую программу можно написать совсем не в одной только в ОО-парадигме.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[11]: Что-то нетак с ООП
От: Undying Россия  
Дата: 21.01.12 08:34
Оценка:
Здравствуйте, Enomay, Вы писали:

U>>Например, у нас есть винформсовский textBox. В том числе при своей работе он решает следующие задачи: 1) вывод рамки, 2) получение символа на который пришелся клик мышки, 3) получение координат изображения и текста при их совместном выводе. Все это типовые задачи, вероятность повторного использования которых в других контролах весьма высока. Ежели вы не видите недостатков у ООП, то продемонстрируйте как можно выковырять эту функциональность из textBox'а и использовать при написании своих контролов.


E>паттерн декоратор


Т.е. надо позвонить в Микрософт и сказать, что у них проектировщики дебилы, не догадавшиеся заюзать в textbox'е паттерн декоратор? После чего решить эти задачи заново, т.к. никакой возможности выковырять эту функциональность из textbox'а ООП не позволяет.

E>почитайте GOF, у них есть отличный пример с текстовым редактором.


Паттерн декоратор тут не нужен и близко. Тут нужно было всю более менее универсальную функциональность textbox'а (в том числе мной перечисленную) вынести в чистые функции. А дальше уже можно было с легкостью использовать эту функциональность и в стандартном textbox'е и в любой другой задаче.
Re[12]: Что-то нетак с ООП
От: mrTwister Россия  
Дата: 21.01.12 09:40
Оценка:
Здравствуйте, Undying, Вы писали:

U>Т.е. надо позвонить в Микрософт и сказать, что у них проектировщики дебилы, не догадавшиеся заюзать в textbox'е паттерн декоратор? После чего решить эти задачи заново, т.к. никакой возможности выковырять эту функциональность из textbox'а ООП не позволяет.


Ну то есть все претензии к ООП заключаются в том, что ООП позволяет писать говнокод? Ты, наверное, знаешь некоторую парадигму или язык программирования, которые не позволяет писать говногод? Назови его!
Пока что тут прозвучал только один ответ, похожий на правду — Brain Driven Development

E>>почитайте GOF, у них есть отличный пример с текстовым редактором.


U>Паттерн декоратор тут не нужен и близко. Тут нужно было всю более менее универсальную функциональность textbox'а (в том числе мной перечисленную) вынести в чистые функции. А дальше уже можно было с легкостью использовать эту функциональность и в стандартном textbox'е и в любой другой задаче.


Если у функций будут параметры, значит будут и зависимости, а следовательно будут и все те проблемы, что у textBox, если не следовать BDD
лэт ми спик фром май харт
Re[13]: Что-то нетак с ООП
От: mrTwister Россия  
Дата: 21.01.12 09:49
Оценка:
Здравствуйте, mrTwister, Вы писали:

T>Если у функций будут параметры, значит будут и зависимости, а следовательно будут и все те проблемы, что у textBox, если не следовать BDD


Для примера, будет у тебя функция, которая рисует рамку и которая в качестве своего аргумента принимает textBox. Удачи её использовать без textBox
лэт ми спик фром май харт
Re[3]: Что-то нетак с ООП
От: Ziaw Россия  
Дата: 21.01.12 14:29
Оценка: 4 (2)
Здравствуйте, batu, Вы писали:

B>у ООП единственный недостаток это жесткое наследование класс-объект. Чуть отличия у объекта так требуется новый класс, что не всегда разумно с предметной точки зрения.


Это недостаток конкретных реализаций, ноги которых растут из C++. А вообще будущее именно за гибридными языками, хорошо умеющими ООП, ФП и МП. Имеющими механизм строгой типизации, мощным выводом типов, но легко переключающиеся на динамику, там где это разумно.

В этом направлении, с небольшими отклонениями движется достаточно много языков.

Отдельно выскажусь о метапрограммировании. Как и с ООП/ФП его необходимость понимается только теми, кто смог хоть раз воспользоваться его приемами эффективно и безболезненно. И, точно так же, после понимания, начинается некоторая ломка в языках, которые ее не поддерживают. Так как задачи, которые лучше всего решаются с применением МП возникают регулярно. Для примера такой ломки, любой сишарпер, активно использующий linq, может попробовать покодить на C# 2.0.
Re[12]: Что-то нетак с ООП
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 21.01.12 16:38
Оценка:
Здравствуйте, Undying, Вы писали:

U>>>Например, у нас есть винформсовский textBox. В том числе при своей работе он решает следующие задачи: 1) вывод рамки, 2) получение символа на который пришелся клик мышки, 3) получение координат изображения и текста при их совместном выводе. Все это типовые задачи, вероятность повторного использования которых в других контролах весьма высока. Ежели вы не видите недостатков у ООП, то продемонстрируйте как можно выковырять эту функциональность из textBox'а и использовать при написании своих контролов.

E>>паттерн декоратор
U>Т.е. надо позвонить в Микрософт и сказать, что у них проектировщики дебилы, не догадавшиеся заюзать в textbox'е паттерн декоратор? После чего решить эти задачи заново, т.к. никакой возможности выковырять эту функциональность из textbox'а ООП не позволяет.

Я не знаю, что такое winforms, но подозреваю, что в итоговой работе используются стандартные контролы Windows. В таком случае Вы, конечно, можете написать проектировщикам, что они дебилы, но думаю, что Вам следует подумать заранее, что это писалось в середине 80-х для машин с 512KB оперативной памяти (да-да, ещё даже не знаменитые 640) и строить декораторы тогда было мало уместно.

Но, с другой стороны, я бы тем проектировщикам пару ласковых отвесил. В ряде программ Microsoft (например, Excel) есть средства, которые по поведению ничуть не отличаются от тех же textbox'ов, но при этом не оформлены как окна на уровне GUI. Мне кажется, это просто нечестно.
В X Window другая традиция — аналогом контрола MS GUI является widget, а окно — более высокий уровень организации, и никто не запрещает использовать готовые виджеты. Вот там уже никто не мешает использовать любые вариации на тему декораторов.

E>>почитайте GOF, у них есть отличный пример с текстовым редактором.


U>Паттерн декоратор тут не нужен и близко. Тут нужно было всю более менее универсальную функциональность textbox'а (в том числе мной перечисленную) вынести в чистые функции. А дальше уже можно было с легкостью использовать эту функциональность и в стандартном textbox'е и в любой другой задаче.


Возможно. Но опять-таки это будет не MS GUI, а что-то специфически своё. А до тех пор, пока при создании, например, кнопки к ней подключается DefButtonProc из стандартной DLL'ки — у Вас не будет такой возможности.
The God is real, unless declared integer.
Re[4]: Что-то нетак с ООП
От: batu Украина  
Дата: 21.01.12 17:19
Оценка:
Здравствуйте, Ziaw, Вы писали:

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


B>>у ООП единственный недостаток это жесткое наследование класс-объект. Чуть отличия у объекта так требуется новый класс, что не всегда разумно с предметной точки зрения.


Z>Это недостаток конкретных реализаций, ноги которых растут из C++. А вообще будущее именно за гибридными языками, хорошо умеющими ООП, ФП и МП. Имеющими механизм строгой типизации, мощным выводом типов, но легко переключающиеся на динамику, там где это разумно.


Z>В этом направлении, с небольшими отклонениями движется достаточно много языков.


Z>Отдельно выскажусь о метапрограммировании. Как и с ООП/ФП его необходимость понимается только теми, кто смог хоть раз воспользоваться его приемами эффективно и безболезненно. И, точно так же, после понимания, начинается некоторая ломка в языках, которые ее не поддерживают. Так как задачи, которые лучше всего решаются с применением МП возникают регулярно. Для примера такой ломки, любой сишарпер, активно использующий linq, может попробовать покодить на C# 2.0.

Все это хорошо согласуется с моими предложениями в языке. Единственно, что бы я уточнил, что сам язык должен быть метаязыком. Здесь никакого противоречия. Обычный язык мы же используем для его же собственного описания. Потому не только OOП и ФП но и языки документирования, конструирования сайтов, языки определения грамматик должны иметь единый синтаксис и единые правила формирования понятий. Именно последнее и делает язык метаязыком.
Re[4]: Что-то нетак с ООП
От: batu Украина  
Дата: 21.01.12 17:24
Оценка:
Здравствуйте, Ziaw, Вы писали:

Z>Отдельно выскажусь о метапрограммировании. Как и с ООП/ФП его необходимость понимается только теми, кто смог хоть раз воспользоваться его приемами эффективно и безболезненно.

Да. К предыдущему можно добавить что язык должен быть как компилируемым, так и интерпретирующим одновременно. И это тоже возможно
Re[15]: Что-то нетак с ООП
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 21.01.12 21:52
Оценка:
Здравствуйте, Enomay, Вы писали:

T>>>Не наблюдал такого никогда. Приведи конкретный пример, посмотрим.

V>>А я постоянно это наблюдаю
V>>Можно даже правило такое замудрить, как декомпозицию не проводи она все равно хоть что-то пополам переедит.

E>проблема в том, кто эту самую декомпозицию, с нарушением SRP, проводит


Не-а и нефиг гнать на людей. Проблема ровно в одной букве: S. SRP — неплохой принцип, но у него одна беда, которая сводит на нет всю его пользу — размытость. "Ответственность" за "работоспособность" — это тоже, знаешь ли, single responsibility.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[5]: Что-то нетак с ООП
От: Eye of Hell Россия eyeofhell.habr.ru
Дата: 22.01.12 00:46
Оценка:
ГВ>А ну-ка, выдерни из Qt какой-нибудь приличный класс, тот же QPainter и заюзай его без самой Qt. Что, скажешь, что у Qt архитектура отсутствует?

Не помню чтобы я утверждал про связь наличия архитектуры и полной изолированности компонентов. А ну-ка, выдерни из здания туалет и попробуй его заюзать без канализации. Что, скажешь, у зданий архитектура отсутствут?
Re[5]: Что-то нетак с ООП
От: Ziaw Россия  
Дата: 22.01.12 03:00
Оценка:
Здравствуйте, batu, Вы писали:

B>Все это хорошо согласуется с моими предложениями в языке. Единственно, что бы я уточнил, что сам язык должен быть метаязыком. Здесь никакого противоречия. Обычный язык мы же используем для его же собственного описания. Потому не только OOП и ФП но и языки документирования, конструирования сайтов, языки определения грамматик должны иметь единый синтаксис и единые правила формирования понятий. Именно последнее и делает язык метаязыком.


Ты сейчас описываешь проект Nemerle 2. Сам язык будет определен ровно теми же средствами, которые доступны прикладному программисту. В nemerle 1 есть некая прослойка, позволяющая расширять парсер/кодогенератор в отдельно взятых местах. Основные же парсер и генератор захардкожены в компиляторе. Во второй версии весь язык будет описан расширяемой пег грамматикой, тем же инструментом, что дается в распоряжение программисту.

Вот работающий прототип расширяемой грамматики: https://github.com/rampelstinskin/ParserGenerator/blob/master/Test/Main.n
В парсер выражений добавляются операции инкремента, декремента и унарного плюса. На сам парсер и на его расширение понадобилось 45 текстовых неплотных строк.

Насчет интерпретации идей пока не возникало. В принципе написать eval не сложно, сложно найти нужный баланс между скоростью байткод компиляции и выполнением.
Re[6]: Что-то нетак с ООП
От: batu Украина  
Дата: 22.01.12 08:34
Оценка:
Здравствуйте, Ziaw, Вы писали:

Z>Ты сейчас описываешь проект Nemerle 2. Сам язык будет определен ровно теми же средствами, которые доступны прикладному программисту. В nemerle 1 есть некая прослойка, позволяющая расширять парсер/кодогенератор в отдельно взятых местах. Основные же парсер и генератор захардкожены в компиляторе. Во второй версии весь язык будет описан расширяемой пег грамматикой, тем же инструментом, что дается в распоряжение программисту.


Z>Вот работающий прототип расширяемой грамматики: https://github.com/rampelstinskin/ParserGenerator/blob/master/Test/Main.n

Z>В парсер выражений добавляются операции инкремента, декремента и унарного плюса. На сам парсер и на его расширение понадобилось 45 текстовых неплотных строк.

Z>Насчет интерпретации идей пока не возникало. В принципе написать eval не сложно, сложно найти нужный баланс между скоростью байткод компиляции и выполнением.

Нет. Я не про немерле. Я про свой язык. И вообще про свою систему. А интерпретацией все очень просто. Операции, операторы и функции с параметрами константами и статическими данными могут выполнятся на предварительном этапе трансляции (у меня это называется обработка стилей). Например, 5+7 вполне может выполнится до трансляции. Так же до трансляции могут выполняться данные определенные в самом стиле и переменные определенные специальным оператором Var(Динамические переменные определяются оператором Dim) для интерпретатора.
А для остальных языков глобальная недоработка это символьные (или текстовые типы. Они вводятся с потолка. У меня все построено на группах. Символы определяются как перечислимые концепты. То, что они перечислимые сомнений не вызывает. Группу перечислимых концептов (любых) можно объединить в перечислимые скобки, где сразу за открывающей скобкой через точку определяется имя перечислимого класса. По умолчанию (т.е. без указания имени перечислимого класса) это является текстовой группой, а скобки так и называются текстовые. Знаки (буквы) в таком случае являются именами перечислимых концептов. Вот такой ход конем. Кстати, еще один любопытный ход. Объединение в группу скобками отключает фунциональную часть концепта. Поэтому можно спокойно включать знаки форматирования. В текстовых скобках они не будут участвовать в форматировании редактируемого текста.
Ну, там долго рассказывать.. Это вкратце..
Re[7]: Что-то нетак с ООП
От: Ziaw Россия  
Дата: 22.01.12 13:18
Оценка:
Здравствуйте, batu, Вы писали:

B>Нет. Я не про немерле. Я про свой язык. И вообще про свою систему.


есть где почитать?
Re[8]: Что-то нетак с ООП
От: Sinclair Россия https://github.com/evilguest/
Дата: 22.01.12 14:00
Оценка: 1 (1) +2
Здравствуйте, Mystic, Вы писали:
M>Есть директория, в которой 100 000 файлов. Их надо все обработать и напечатать, сколько файлов было обработано. Это все прекрасно можно сделать с использованием счетчика и FindFirst/FindNext. А теперь предположим, что у нас есть прекрасный класс Directory, скрывающий доступ к FindFirst/FindNext. Какие методы должны быть в нем и как они должны быть реализованы, чтобы избежать накладных расходов (повторное сканирование директории, хранение списка файлов, ...)
Не понял. Вы серъёзно или это такой тонкий троллинг?
Если нет — то вот вам схема класса (компилироваться не будет, т.к. пишу по памяти в уме):
public class Directory
{
  public IEnumerablr<FileInfo> FindFiles(string pattern)
  {
     try
     { 
       var r = FindFirst(_path, pattern);
       while (r.Found)
       {
         yield return r.FileInfo;
         r = FindNext(r);
       }
     }
     finally
     {
       FindClose(r);
     }
  }
}

Как видите, он скрывает доступ к FindFirst/FindNext/FindClose, при этом нет никаких накладных расходов на повторное сканирование директории или хранение списка файлов.
При этом я могу совершенно спокойно писать, скажем, вот так:
...
foreach(var fi in d.FindFiles("*.cs")
  if (fi.LastModified >= yesterday)
    return fi.Name

Это значительно компактнее, чем вариант с прямым использованием FindXXX, и гарантированно закрывает хэндл поиска.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[6]: Что-то нетак с ООП
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 22.01.12 14:04
Оценка:
Здравствуйте, Eye of Hell, Вы писали:

ГВ>>А ну-ка, выдерни из Qt какой-нибудь приличный класс, тот же QPainter и заюзай его без самой Qt. Что, скажешь, что у Qt архитектура отсутствует?


EOH>Не помню чтобы я утверждал про связь наличия архитектуры и полной изолированности компонентов.


Возможно, что я тебя неправильно понял.

EOH>А ну-ка, выдерни из здания туалет и попробуй его заюзать без канализации. Что, скажешь, у зданий архитектура отсутствут?


Так в том-то и дело, что наличие архитектурного планирования, — т.е. того самого высокоуровневого разделения обязанностей, напрямую препятствует повторному использованию компонентов вне определённых сценариев. Или без двойного отрицания: архитектура прямо предписывает определённые сценарии как для использования компонентов, так и для расширения системы.

Поэтому ты не можешь поставить туалет в чисто поле без канализации. И поэтому же должен знать взаимосвязи классов, чтобы правильно их использовать (например, QAbstractItem, QAbstractItemView и сопутствующие). Так что, ИМХО, вот это высказывание
Автор: Artifact
Дата: 18.01.12
всё-таки довольно близко к истине:

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


И чем сильнее архитектура системы повлияла на отдельные компоненты, тем ближе к истине процитированное.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[7]: Что-то нетак с ООП
От: Eye of Hell Россия eyeofhell.habr.ru
Дата: 22.01.12 16:54
Оценка: +1
ГВ>Так в том-то и дело, что наличие архитектурного планирования, — т.е. того самого высокоуровневого разделения обязанностей, напрямую препятствует повторному использованию компонентов вне определённых сценариев. Или без двойного отрицания: архитектура прямо предписывает определённые сценарии как для использования компонентов, так и для расширения системы.

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

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

ГВ>Поэтому ты не можешь поставить туалет в чисто поле без канализации. И поэтому же должен знать взаимосвязи классов, чтобы правильно их использовать (например, QAbstractItem, QAbstractItemView и сопутствующие). Так что, ИМХО, вот это высказывание
Автор: Artifact
Дата: 18.01.12
всё-таки довольно близко к истине:

ГВ>

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


ООП вроде как != повторному использованию кода?
Re[8]: Что-то нетак с ООП
От: batu Украина  
Дата: 22.01.12 17:51
Оценка:
Здравствуйте, Ziaw, Вы писали:

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


B>>Нет. Я не про немерле. Я про свой язык. И вообще про свою систему.


Z>есть где почитать?

Здесь концепция http://files.rsdn.ru/91645/%d0%9a%d0%be%d0%bd%d1%86%d0%b5%d0%bf%d1%82%d0%bd%d0%b0%d1%8f%20%d0%bf%d0%b0%d1%80%d0%b0%d0%b4%d0%b8%d0%b3%d0%bc%d0%b0.doc
Здесь о группировании http://files.rsdn.ru/91645/%d0%93%d1%80%d1%83%d0%bf%d0%bf%d0%b8%d1%80%d0%be%d0%b2%d0%b0%d0%bd%d0%b8%d0%b5%20%d0%be%d0%b1%d1%8a%d0%b5%d0%ba%d1%82%d0%be%d0%b2.doc
Это так вкратце что б не грузить деталями. Концепцию можно назвать субъектно-ориентированой. Но думаю концептная не так громко звучит.
Группирование это центральные классы в реализации и они же определяют применение скобок и потому являются основой синтаксиса языка. Cинтаксис в основе простой и универсальный: Концепт = "имя класса концепта" "имя концепта" "Реализация". Дальше только применение групп сразу после имени класса концепта и т.д. Реализация тоже группа. Обычно это операторы или так называемое тело оператора или класса.. вообщем так.. Для затравки достаточно. Будет интересно дальше расскажу..
Re[9]: Что-то нетак с ООП
От: Mystic Украина http://mystic2000.newmail.ru
Дата: 22.01.12 18:30
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Как видите, он скрывает доступ к FindFirst/FindNext/FindClose, при этом нет никаких накладных расходов на повторное сканирование директории или хранение списка файлов.

S>При этом я могу совершенно спокойно писать, скажем, вот так:
S>
S>...
S>foreach(var fi in d.FindFiles("*.cs")
S>  if (fi.LastModified >= yesterday)
S>    return fi.Name
S>

S>Это значительно компактнее, чем вариант с прямым использованием FindXXX, и гарантированно закрывает хэндл поиска.

Количество файлов придется подсчитывать самому.
Re[10]: Что-то нетак с ООП
От: Sinclair Россия https://github.com/evilguest/
Дата: 23.01.12 02:36
Оценка:
Здравствуйте, Mystic, Вы писали:

M>Количество файлов придется подсчитывать самому.

И? А что, FindFirst/FindNext уже предлагают какой-то волшебный способ подсчитать его, не заканчивая итерирование?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.