А фиг ее знает, в чем может выражаться объектная ориентированность названий аргументов командной строки. Имхо, названия вообще не могут быть объекными или функциональными, это же названия.
Ну почему же не могут, вполне могут. Например, программа состоит из модулей а, б и в (и их подмолудей), и опции называются соответственно: --а-опция1, --б-опция2, --в-опция5-подопция9. Это ОО. А можно плясать от функциональности программы, где а, б и в - это то, что программа делает, и настойки касаются конкретно этих линий исполнения (например, разные настройки для архивации/разархивации).
Меня смущает то, что я знаю две общепризнанные формулировки ООП. Поздняя звучит как-то так: "ООП -- это икапсуляция, наследование и полиморфизм". Более ранняя, высказанная Аланом Кеем: "OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things."
Исходя из этих опредений я не понимаю, как непрограммная сущность (то бишь название) может быть объектно-ориентированной.
Ты не подменяй ОО ООП. Никто о ООП тут не говорит. ОО бывает не только П, еще бывает, например, ОО-декомпозиция (и, в противовес, функциональная декомпозиция).
Они хотят показать свою систему как совокупность нескольких компонент, и каждая компонента имеет свой набор опций, и это отражено в именах. Вот и все ОО.
В противовес, они могли бы показать свою систему как нечто, исполняющее несколько разных задач, и сделать наборы опций для каждой конкретной задачи.
(это все мои спекуляции, я не знаю, что у них было и что стало, но я понимаю, что может стоять за ОО)
Вообще-то ОО-анализ (и декомпозиция) замечательно живут и вне программирования. Равно как и функциональные А и Д. Последние очень востребованы, например, в анализе (b последующей оптимизации) бизнес-процессов (IDEF0). ОО там тоже очень кстати: композиция выражается в структуре предприятия, а наследование - в должностных инструкциях, которые друг друга включают.
>Вообще-то ОО-анализ (и декомпозиция) замечательно живут и вне программирования.
Все о чем ты говоришь, можно рассматривать как варианты программирования. Т.е. определения алгоритмов (инструкций), в процессе выполнения которых достигается некоторая цель.
Т.е. всегда речь идет о каких-то динамических системах, где кто-то с кем-то взаимодействует. И мы устанавливаем правила этих взаимодействий.
Название чего-либо -- это статика. В нем ничего ни с чем не взаимодействует. И не может в принципе.
опции - это настройки и характеристики. Это это настройки и характеристики процессов - это функционально-ориентированные опции, если объектов и подсистем - ОО.
Объективно есть опция, скажем, частота кадров. Это и настройка, и характеристика плеейра -- если такая опция есть, это должным образом характеризует его.
А вот название этой опции, будь то frame-rate, divx-frame-rate, ffmpeg-divx-frame-rate, vlc-divx-frame-rate -- это уже чистой воды субъективизм. Если кому-то кажется, что какое-то из них более ОО, чем другие -- ну что поделать, всяк сходит с ума по своему.
ну вот смотри, есть в плеере такой объект-подсистема - divx. И все опции, относящиесая к этой подсистеме, начинаюбтся с divx. И получать список опций можно, например, опцией --divx-help. Это не ОО? Функциональную декомпозицию тут не придумать, потому что у плеера одна задача - играть файл.
В других программах может быть и функциональная декомпозиция, где пляшут не от подсистем, а от действий, которые хочет выполнить пользователь. И тогда будет опция --действие1--настройкаА, --действие1-настройкаБ, ну и --действие1-help для получения всего списка опций для данного действия.
Естественно, эти опции могут перекрываться.
Например, если у тебя есть опция --действие1-логирование, то логирование будет включено только для действия 1, и это может соответствовать включению опций --подсистема1-логирование и т.д. для любой подсистемы, которая принимает участие в этом действии, но только для действия1. С другой стороны, если ты указываешь --подсистема1-логирование, то подсистема 1 будет логировать всегда, независимо от того, какой именно деятельностью занимается система в данный момент.
Вот тебе разница между ОО- и ФО-опциями.
Например, если твоя подсистема - это divx, а ты открыл файл не divx, то все ОО-опции, относящиеся к divx, будут программой проигнорированы, в отличие от (может быть тех же самых с логической точки зрения) опций, заданных для конкретного действия.
Есть еще и третий вариант (стандартная ситуация в юниксовом мире) - зоопарк однобуквенных опций, в которых черт ногу сломит, и из которых совершенно непонятно, что к чему относится. Но и там постепенно делают осмысленные синонимы.
>И все опции, относящиесая к этой подсистеме, начинаюбтся с divx. И получать список опций можно, например, опцией --divx-help. Это не ОО?
Ну не вижу я в названии "--divx-help" никакого ОО. ОО - это когда выделяется объект, который имеет строго определенный контракт и который скрывает от всех детали исполнения своего контракта. Далее объект имеет методы, которые дергаются для получения тех или иных результатов (согласно контракту).
В названии(!) нет никаких контрактов, название не является объектом, у него нет методов, его нельзя дергать.
Поэтому нельзя (с моей точки зрения) вести речь о объектной-ориентированности названий аргументов. Можно говорить о том, что аргументы отражают структуру приложения и еще какую-нибудь муть в том же духе.
Опять же, если --divx-help является ОО названием, то что на счет --help-divx? Или --divx-playback-help и --playback-help-divx, и --playback-divx-help?
так набор опций и есть контракт, это и есть интерфейс для взаимодействия с пользователем. Так что все вполне ОО - инкапсуляция на месте, наследование и полиморфизм реализуются через опции типа --decoder-frame-rate, где decoder - это базовый класс для всех декодеров, и все декодеры типа divx, xvid и т.д. должны реализоваывать весь набор этих базовых опций.
>так набор опций и есть контракт, это и есть интерфейс для взаимодействия с пользователем.
Мы, похоже, с тобой о разных вещах говорим. Набор опций -- это контракт плейера. Как набор публичных методов -- это контракт класса. С этим я не спорю, с этим все нормально.
Но в самом названии опции где ОО?
Вот если продолжать аналогию -- есть класс с методами установки и получения параметра транспорта. Эти методы -- это контракт класса. Пусть они назывались раньше setTransportParams и queryTransportParams. Потом их переименовали в transportSetParams и transportQueryParams. Можно ли здесь говорит о какой-нибудь объектности названий методов?
>Тут само наличие слова транспорт вскрывает объектное деление подсистемы, тем самым оно ОО.
Не на такую широту взглядов я пока пойтить не могу.
Поскольку, продолжая размышлять в таком русле, я прихожу к выводу, что название "Сон, вызванный полетом шмеля над гранатом, за мнгновение до пробуждения" вполне себе ОО.
а в чем конкретно эта объектная ориентированность выражается? А то примеров нету, может, это и осмысленный апдейт
ОтветитьУдалитьА фиг ее знает, в чем может выражаться объектная ориентированность названий аргументов командной строки. Имхо, названия вообще не могут быть объекными или функциональными, это же названия.
ОтветитьУдалитьНу почему же не могут, вполне могут.
ОтветитьУдалитьНапример, программа состоит из модулей а, б и в (и их подмолудей), и опции называются соответственно: --а-опция1, --б-опция2, --в-опция5-подопция9.
Это ОО.
А можно плясать от функциональности программы, где а, б и в - это то, что программа делает, и настойки касаются конкретно этих линий исполнения (например, разные настройки для архивации/разархивации).
>опции называются соответственно: --а-опция1, --б-опция2, --в-опция5-подопция9.
ОтветитьУдалитьЭто ОО.
Ну тогда почтовые адреса -- это чистой воды ОО: город-улица-дом-квартира.
да, а что тебя смущает?
ОтветитьУдалитьПросто если у них раньше был зоопарк опций, никак не сгруппированных визуально, а теперь они все упорядочены - это можно только приветствовать.
Меня смущает то, что я знаю две общепризнанные формулировки ООП. Поздняя звучит как-то так: "ООП -- это икапсуляция, наследование и полиморфизм". Более ранняя, высказанная Аланом Кеем: "OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things."
ОтветитьУдалитьИсходя из этих опредений я не понимаю, как непрограммная сущность (то бишь название) может быть объектно-ориентированной.
Ты не подменяй ОО ООП.
ОтветитьУдалитьНикто о ООП тут не говорит.
ОО бывает не только П, еще бывает, например, ОО-декомпозиция (и, в противовес, функциональная декомпозиция).
Они хотят показать свою систему как совокупность нескольких компонент, и каждая компонента имеет свой набор опций, и это отражено в именах. Вот и все ОО.
В противовес, они могли бы показать свою систему как нечто, исполняющее несколько разных задач, и сделать наборы опций для каждой конкретной задачи.
(это все мои спекуляции, я не знаю, что у них было и что стало, но я понимаю, что может стоять за ОО)
>ОО бывает не только П, еще бывает, например, ОО-декомпозиция (и, в противовес, функциональная декомпозиция).
ОтветитьУдалитьНе бывает. ОО-декомпозиция и ОО-анализ -- это все части объектного подхода к разработке программ. Т.е. все это части процесса програмирования.
И пусть это моя зашоренность, и пусть меня закидывают тухлыми помидорами, но ОО названия -- это маразм.
Вообще-то ОО-анализ (и декомпозиция) замечательно живут и вне программирования.
ОтветитьУдалитьРавно как и функциональные А и Д.
Последние очень востребованы, например, в анализе (b последующей оптимизации) бизнес-процессов (IDEF0). ОО там тоже очень кстати: композиция выражается в структуре предприятия, а наследование - в должностных инструкциях, которые друг друга включают.
>Вообще-то ОО-анализ (и декомпозиция) замечательно живут и вне программирования.
ОтветитьУдалитьВсе о чем ты говоришь, можно рассматривать как варианты программирования. Т.е. определения алгоритмов (инструкций), в процессе выполнения которых достигается некоторая цель.
Т.е. всегда речь идет о каких-то динамических системах, где кто-то с кем-то взаимодействует. И мы устанавливаем правила этих взаимодействий.
Название чего-либо -- это статика. В нем ничего ни с чем не взаимодействует. И не может в принципе.
опции - это настройки и характеристики.
ОтветитьУдалитьЭто это настройки и характеристики процессов - это функционально-ориентированные опции, если объектов и подсистем - ОО.
>опции - это настройки и характеристики.
ОтветитьУдалитьопции и названия опций -- это разные вещи.
Объективно есть опция, скажем, частота кадров. Это и настройка, и характеристика плеейра -- если такая опция есть, это должным образом характеризует его.
А вот название этой опции, будь то frame-rate, divx-frame-rate, ffmpeg-divx-frame-rate, vlc-divx-frame-rate -- это уже чистой воды субъективизм. Если кому-то кажется, что какое-то из них более ОО, чем другие -- ну что поделать, всяк сходит с ума по своему.
ну вот смотри, есть в плеере такой объект-подсистема - divx.
ОтветитьУдалитьИ все опции, относящиесая к этой подсистеме, начинаюбтся с divx. И получать список опций можно, например, опцией --divx-help.
Это не ОО?
Функциональную декомпозицию тут не придумать, потому что у плеера одна задача - играть файл.
В других программах может быть и функциональная декомпозиция, где пляшут не от подсистем, а от действий, которые хочет выполнить пользователь. И тогда будет опция --действие1--настройкаА, --действие1-настройкаБ, ну и --действие1-help для получения всего списка опций для данного действия.
Естественно, эти опции могут перекрываться.
Например, если у тебя есть опция --действие1-логирование, то логирование будет включено только для действия 1, и это может соответствовать включению опций --подсистема1-логирование и т.д. для любой подсистемы, которая принимает участие в этом действии, но только для действия1.
С другой стороны, если ты указываешь --подсистема1-логирование, то подсистема 1 будет логировать всегда, независимо от того, какой именно деятельностью занимается система в данный момент.
Вот тебе разница между ОО- и ФО-опциями.
Например, если твоя подсистема - это divx, а ты открыл файл не divx, то все ОО-опции, относящиеся к divx, будут программой проигнорированы, в отличие от (может быть тех же самых с логической точки зрения) опций, заданных для конкретного действия.
Есть еще и третий вариант (стандартная ситуация в юниксовом мире) - зоопарк однобуквенных опций, в которых черт ногу сломит, и из которых совершенно непонятно, что к чему относится. Но и там постепенно делают осмысленные синонимы.
>И все опции, относящиесая к этой подсистеме, начинаюбтся с divx. И получать список опций можно, например, опцией --divx-help.
ОтветитьУдалитьЭто не ОО?
Ну не вижу я в названии "--divx-help" никакого ОО. ОО - это когда выделяется объект, который имеет строго определенный контракт и который скрывает от всех детали исполнения своего контракта. Далее объект имеет методы, которые дергаются для получения тех или иных результатов (согласно контракту).
В названии(!) нет никаких контрактов, название не является объектом, у него нет методов, его нельзя дергать.
Поэтому нельзя (с моей точки зрения) вести речь о объектной-ориентированности названий аргументов. Можно говорить о том, что аргументы отражают структуру приложения и еще какую-нибудь муть в том же духе.
Опять же, если --divx-help является ОО названием, то что на счет --help-divx? Или --divx-playback-help и --playback-help-divx, и --playback-divx-help?
так набор опций и есть контракт, это и есть интерфейс для взаимодействия с пользователем. Так что все вполне ОО - инкапсуляция на месте, наследование и полиморфизм реализуются через опции типа --decoder-frame-rate, где decoder - это базовый класс для всех декодеров, и все декодеры типа divx, xvid и т.д. должны реализоваывать весь набор этих базовых опций.
ОтветитьУдалить>так набор опций и есть контракт, это и есть интерфейс для взаимодействия с пользователем.
ОтветитьУдалитьМы, похоже, с тобой о разных вещах говорим. Набор опций -- это контракт плейера. Как набор публичных методов -- это контракт класса. С этим я не спорю, с этим все нормально.
Но в самом названии опции где ОО?
Вот если продолжать аналогию -- есть класс с методами установки и получения параметра транспорта. Эти методы -- это контракт класса. Пусть они назывались раньше setTransportParams и queryTransportParams. Потом их переименовали в transportSetParams и transportQueryParams. Можно ли здесь говорит о какой-нибудь объектности названий методов?
ну конечно, ты ведь говоришь пользователю, что в есть такой объект - транспорт.
ОтветитьУдалитьТут само наличие слова транспорт вскрывает объектное деление подсистемы, тем самым оно ОО.
>Тут само наличие слова транспорт вскрывает объектное деление подсистемы, тем самым оно ОО.
ОтветитьУдалитьНе на такую широту взглядов я пока пойтить не могу.
Поскольку, продолжая размышлять в таком русле, я прихожу к выводу, что название "Сон, вызванный полетом шмеля над гранатом, за мнгновение до пробуждения" вполне себе ОО.
:)))