Гради Буч мне внезапно открыл глаза на ООП. До того я никак не мог понять: что это и зачем?
После прочтения «ООП» Буча мои волосы стали мягкими и шелковистыми, и пришло понимание основ. С этого момента я начал жонглировать объектами. Сначала, как и в цирковом училище, лишь парой-тройкой. Затем больше и больше.
Потом появилась мания, всё перевести в объекты, и я заплутал в трущобах высотных конструкций из этих самых объектов.
Тут пришло время для паттернов, т.е. о том, как организовать (!) свою работу с объектами. Не всё сразу. Один-два примера. Практика. Практика. Ещё парочка. Практика. Практика.
Прочитал ваш коммент про необходимость разделять объекты-контейнеры и функциональные объекты. С этим согласен.
Но на мой взгляд, это все же не проблема ООП, а скорее вопрос архитектурных соглашений в рамках проекта или языка.
Более того, объектно-ориентированные языки сами зачастую нарушают правило инкапсуляции, предоставляя доступ к данным через специальные методы — getters и setters в Java, properties в C# и т.д.
Мне кажется здесь вы перепутали инкапсуляцию с доступом к свойствам. Часто это взаимосвязанные вещи, но не тождественные.
Отключение прямого доступа к свойствам — обычно завязано на некоторое поведение объекта, связанное с этим свойством, или, к примеру, изменение других, сопутствующих свойств.
А инкапсуляция — это уже сокрытие реализации. К чему вам видеть, что у объекта имеется десять вспомогательных методов, которые выполняют «грязную работу»? Объект предоставляет вам красивые публичные методы для работы (меню ресторана), и не пускает вас на кухню, чтобы вы не лезли с советами к шеф-повару. :)
Если при этом на кухне меняется оборудование, технология приготовления блюд — в идеальном варианте вы всё равно получите то, что указано в меню, вам не придётся выяснять подробности приготовления.
Полиморфизм — это тоже весьма сильное средство в умелых руках.
ООП даёт вам возможность, сообразуясь с вашей целью, написать соответствующий «язык» на основе другого «языка». Фреймворки — это, по большому счёту, некоторое специфическое подмножество языка (С, Java, PHP — не суть важно) которое предоставляет определённый формат работы с ним. Если он вам подходит — отлично, меньше лишней работы. Не подходит — пишите своё или ищите подходящий вашим задачам.
Каждая селёдка — рыба, но не каждая рыба — селёдка. Это ещё Врунгель рассказывал. :)
Может вам просто не везёт, но практически все девушки, связанные с IT, которые мне попадались — совершенно нормальные, адекватные и привлекательные. Все проблемы от нервов и отсуствия мозгов, а не от профессии и технического склада ума. :)
Не совсем. Феномен «зловещей долины» отлично подходит для демонстрации созданий, который должны вызывать ужас. Самая отличная и настойчиво эксплуатируемая с древних времён тема — ожившие трупы. Собственно здесь самое ужасное то, что появляется создание которое вроде как «свой», но очевидно, что своим быть не может. Да ещё и отделаться от этих тварей непросто. На этих страхах и живут детские «страшилки», целый пласт фантастики ужасов и Голливуд. :)
А с декорациями немного другой момент, попробую сформулировать.
В театре нам показывают: «вот тут у нас КАК БЫ кухня», «вот тут у нас КАК БЫ тронный зал». Всё. Здесь уже включается воображение, которое достраивает картинку и весь фокус внимания переходит на игру актёров. Больше на декорации мозг не отвлекается, они служат только своеобразным «якорем» для обозначения места действия.
В кино же, нам показывают это так: «А тут кухня», «а тут тронный зал». То есть окружающая кинореальность играет не меньшую роль в подаче всей картинки. Вы когда-нибудь видели трансляции спектаклей по телевизору? Разница кардинальная между спектаклем и кино, опять же — фокус внимания.
Постепенно все привыкли, что кино выглядит так, как оно выглядит на экране (и подсознательно мы сразу отмечаем разницу с реальностью). Все достижения технологии шли на увеличение разрешения, на повышение контраста, яркости, сочности картинки, оставляя при этом чётко очерченную грань «это — кино» (можно сравнить качество картинки фильмов 70-х, 80-х, 90-х и 2000-х годов. Так сказать — наглядное отображение прогресса киноиндустрии).
Сейчас же, когда удаётся посмотреть материал, подготовленный на более качественном уровне, с более плавной картинкой, мозг срывается в «истерику» и сразу отмечает те мелочи, которые ДОЛЖНЫ разделить реальность и экран. И вроде движения более плавные и реальные (не зря многие отмечают это как «театральная постановка» — собственно реализм движений это и даёт), но в тоже самое время нет точки отсчёта, чтобы окончательно провести границу реальность-картинка.
С повышением детализации, с привычкой к более качественной картинке (если она будет, конечно) мне кажется, что это всё отойдёт на задний план, и новые фильмы будут восприниматься также, как и обычное кино.
А ощущение «мыльной оперы», «документалки» и «компигры» — это просто мозг мечется, не привычный к новому стандарту.
У меня есть предположение, что здесь ещё сказывается и отношение к декорациям: декорации, применяемые в кино в 70-80 быстро входили в контекст и воспринимались как «реальность» фильма. Те же самые декорации в театре воспринимаются именно как декорации и требуют отдельного перестроения восприятия под контекст.
Аналогично — при увеличении качества картинки и приближения её к реалиям, потребуется более тщательно относится к вопросу воссоздания кинореальности. При современных достижениях компьютерного моделирования это уже не должно быть большой проблемой, на мой взгляд.
И само собой — в немалой степени здесь сказывается привычка: вспомните, как воспринимались раньше фильмы Кинг-Конг, Терминатор, и классика жанра — Годзилла и прочие возвращения динозавров. :)
Это было восхитительно и пугающе реально. А нынче восприятие уже настолько привыкло к более сильным эффектам и кинореальности, что старые фильмы воспринимаются с улыбкой.
Следите за выходным уровнем на мастер-шине: не допускайте клипирования сигнала (превышение порога 0 дБ), а лучше сохраняйте дистанцию до порога (-2, -3 дБ).
Лучше оставить запас побольше: итоговый трек перед мастерингом обычно имеет запас по уровню до 6 (шести) дБ. Да и у многих профессиональных мастров звуковых дел именно 6 дБ фигурирует в качестве цифры хорошего запаса по уровню.
В любом случае на мастеринге фонограмму надо будет «плющить» как минимум максимайзером (если это не тихая песня в акустическом варианте), поэтому лучше обезопасить себя, и оставить запас чуть побольше: это позволит на мастеринге более комфортно работать с конечным миксом.
Для начала вам нужно определиться, что вы имеете ввиду, когда говорите «улучшить» звук живого инструмента.
Но вообще, самый простой вариант для того, чтобы «пощупать» звук: записать звучание инструмента сразу двумя микрофонами (в данном случае я имею ввиду электрогитару), при этом микрофоны снимают разный звук с динамика (например один установлен под углом и направлен на середину, а второй снимает мембрану чуть в стороне от оси). И после этого крутить баланс этих двух треков, выясняя, что именно вам нужно (вообще расстановка микрофонов — это отличный вариант изменить звук, но и редкостный геморрой при этом).
Если писать «домашний вариант», то треки пишутся в линию, а уже потом обрабатываются на компьютере, в зависимости от требований к звучанию. Тут вариантов может быть масса.
Но опять же — это в зависимости от звука и музыки, понятно, что для фанка вам потребуется одно (прозрачный звук гитары), а для метала — совершенно другое звучание (тут на помощь приходят даблтреки, а в экстремальных случаях и для достижение некоторых специфических нюансов — даже квадраплы для треков).
Поэтому внимательно анализируйте, сравнивайте и думайте, чего вам не хватает. Исходя из этого уже можно что-то предпринимать.
Как мне кажется, суть статьи не в том, что автор пробует силы в писательстве, а в том замечательном, на мой взгляд, подходе, когда правит бал содержимое, а всё оформление направлено на то, чтобы удобно и приятно это содержимое преподнести.
За такой доскональный подход и внимание к удобству читателя, автору почёт и уважение.
Меня конечно раздражает безграмотность, но в данном случае этот недостаток с лихвой окупается способом подачи материала. Мне так кажется. :)
А если внезапно в AppStore завернут приложение на ревью, с какой либо отсылкой на код, ну например в виде некорректного использования приватных фреймворков из iOS SDK?
В такой ситуации все вопросы к настройкам/версиям Air? Или существуют какие-то другие способы устранения подобных неприятностей?
Хм. А вот, к примеру, при подключении к Game Center от Apple получил предложение прочитать лицензию для начала. Если мне не изменяет память — 54 страницы.
Прочитал только первую страницу. Затем взглядом зацепился за количество страниц и со словами «ну и хрен с ним», закрыл соглашение.
Поэтому мой вариант: «Да, читаю местами». Не будем уточнять, какими. :)
А я не понимаю одного: неужели тролль, подавший иск, в случае проигрыша по необоснованной претензии, никак не должен компенсировать это? Например оплатить судебные издержки, и тому подобное.
Ведь если нет, то это просто дичайший невод для ловли компаний: закидываешь кучу исков, и хотя бы в одном-двух, но перепадёт что-нибудь.
А если заставить компенсировать расходы (а несидящих в тюрьмах — обязательно присутствовать на слушании, дорога — за свой счёт), то мне кажется многократно поубавиться желающих влезть в необоснованную тяжбу.
А в PHP достаточно такого: $a = (int|bool|array|string|object)$a;
Ну в этом-то и дело.
Сейчас ради интереса посмотрел в мануал по PHP: найти описание явного приведения типов намного проще, и легче запомнить, чем немаленькие таблицы неявных приведений.
Отсюда вопрос: кто будет сознательно использовать приведение типов через арифметические (строковые) операции?
Ну и в той же Java: ну кому, кому блин может придти в голову, намеренно преобразовать число в строку через конкатенацию числа и строки? :)
Ну я еще могу понять, когда появляются странные штуки при реализации логики, взаимодействия классов. Но вот такой хитровыкрученный пример — это явный «изыск».
Издательство, выпустившее книгу «BitTorrents for dummies» теперь подаёт в суд на пользователей, которые прочитали «BitTorrents for dummies» и распространяют «BitTorrents for dummies» через BitTorrent. :D
После прочтения «ООП» Буча мои волосы стали мягкими и шелковистыми, и пришло понимание основ. С этого момента я начал жонглировать объектами. Сначала, как и в цирковом училище, лишь парой-тройкой. Затем больше и больше.
Потом появилась мания, всё перевести в объекты, и я заплутал в трущобах высотных конструкций из этих самых объектов.
Тут пришло время для паттернов, т.е. о том, как организовать (!) свою работу с объектами. Не всё сразу. Один-два примера. Практика. Практика. Ещё парочка. Практика. Практика.
И так далее.
Ну и самое главное: не паниковать. :)
Но на мой взгляд, это все же не проблема ООП, а скорее вопрос архитектурных соглашений в рамках проекта или языка.
Мне кажется здесь вы перепутали инкапсуляцию с доступом к свойствам. Часто это взаимосвязанные вещи, но не тождественные.
Отключение прямого доступа к свойствам — обычно завязано на некоторое поведение объекта, связанное с этим свойством, или, к примеру, изменение других, сопутствующих свойств.
А инкапсуляция — это уже сокрытие реализации. К чему вам видеть, что у объекта имеется десять вспомогательных методов, которые выполняют «грязную работу»? Объект предоставляет вам красивые публичные методы для работы (меню ресторана), и не пускает вас на кухню, чтобы вы не лезли с советами к шеф-повару. :)
Если при этом на кухне меняется оборудование, технология приготовления блюд — в идеальном варианте вы всё равно получите то, что указано в меню, вам не придётся выяснять подробности приготовления.
Полиморфизм — это тоже весьма сильное средство в умелых руках.
ООП даёт вам возможность, сообразуясь с вашей целью, написать соответствующий «язык» на основе другого «языка». Фреймворки — это, по большому счёту, некоторое специфическое подмножество языка (С, Java, PHP — не суть важно) которое предоставляет определённый формат работы с ним. Если он вам подходит — отлично, меньше лишней работы. Не подходит — пишите своё или ищите подходящий вашим задачам.
Это не проблема ООП, это проблема выбора. :)
Может вам просто не везёт, но практически все девушки, связанные с IT, которые мне попадались — совершенно нормальные, адекватные и привлекательные. Все проблемы от нервов и отсуствия мозгов, а не от профессии и технического склада ума. :)
А с декорациями немного другой момент, попробую сформулировать.
В театре нам показывают: «вот тут у нас КАК БЫ кухня», «вот тут у нас КАК БЫ тронный зал». Всё. Здесь уже включается воображение, которое достраивает картинку и весь фокус внимания переходит на игру актёров. Больше на декорации мозг не отвлекается, они служат только своеобразным «якорем» для обозначения места действия.
В кино же, нам показывают это так: «А тут кухня», «а тут тронный зал». То есть окружающая кинореальность играет не меньшую роль в подаче всей картинки. Вы когда-нибудь видели трансляции спектаклей по телевизору? Разница кардинальная между спектаклем и кино, опять же — фокус внимания.
Постепенно все привыкли, что кино выглядит так, как оно выглядит на экране (и подсознательно мы сразу отмечаем разницу с реальностью). Все достижения технологии шли на увеличение разрешения, на повышение контраста, яркости, сочности картинки, оставляя при этом чётко очерченную грань «это — кино» (можно сравнить качество картинки фильмов 70-х, 80-х, 90-х и 2000-х годов. Так сказать — наглядное отображение прогресса киноиндустрии).
Сейчас же, когда удаётся посмотреть материал, подготовленный на более качественном уровне, с более плавной картинкой, мозг срывается в «истерику» и сразу отмечает те мелочи, которые ДОЛЖНЫ разделить реальность и экран. И вроде движения более плавные и реальные (не зря многие отмечают это как «театральная постановка» — собственно реализм движений это и даёт), но в тоже самое время нет точки отсчёта, чтобы окончательно провести границу реальность-картинка.
С повышением детализации, с привычкой к более качественной картинке (если она будет, конечно) мне кажется, что это всё отойдёт на задний план, и новые фильмы будут восприниматься также, как и обычное кино.
У меня есть предположение, что здесь ещё сказывается и отношение к декорациям: декорации, применяемые в кино в 70-80 быстро входили в контекст и воспринимались как «реальность» фильма. Те же самые декорации в театре воспринимаются именно как декорации и требуют отдельного перестроения восприятия под контекст.
Аналогично — при увеличении качества картинки и приближения её к реалиям, потребуется более тщательно относится к вопросу воссоздания кинореальности. При современных достижениях компьютерного моделирования это уже не должно быть большой проблемой, на мой взгляд.
И само собой — в немалой степени здесь сказывается привычка: вспомните, как воспринимались раньше фильмы Кинг-Конг, Терминатор, и классика жанра — Годзилла и прочие возвращения динозавров. :)
Это было восхитительно и пугающе реально. А нынче восприятие уже настолько привыкло к более сильным эффектам и кинореальности, что старые фильмы воспринимаются с улыбкой.
Лучше оставить запас побольше: итоговый трек перед мастерингом обычно имеет запас по уровню до 6 (шести) дБ. Да и у многих профессиональных мастров звуковых дел именно 6 дБ фигурирует в качестве цифры хорошего запаса по уровню.
В любом случае на мастеринге фонограмму надо будет «плющить» как минимум максимайзером (если это не тихая песня в акустическом варианте), поэтому лучше обезопасить себя, и оставить запас чуть побольше: это позволит на мастеринге более комфортно работать с конечным миксом.
Но вообще, самый простой вариант для того, чтобы «пощупать» звук: записать звучание инструмента сразу двумя микрофонами (в данном случае я имею ввиду электрогитару), при этом микрофоны снимают разный звук с динамика (например один установлен под углом и направлен на середину, а второй снимает мембрану чуть в стороне от оси). И после этого крутить баланс этих двух треков, выясняя, что именно вам нужно (вообще расстановка микрофонов — это отличный вариант изменить звук, но и редкостный геморрой при этом).
Если писать «домашний вариант», то треки пишутся в линию, а уже потом обрабатываются на компьютере, в зависимости от требований к звучанию. Тут вариантов может быть масса.
Но опять же — это в зависимости от звука и музыки, понятно, что для фанка вам потребуется одно (прозрачный звук гитары), а для метала — совершенно другое звучание (тут на помощь приходят даблтреки, а в экстремальных случаях и для достижение некоторых специфических нюансов — даже квадраплы для треков).
Поэтому внимательно анализируйте, сравнивайте и думайте, чего вам не хватает. Исходя из этого уже можно что-то предпринимать.
Как мне кажется, суть статьи не в том, что автор пробует силы в писательстве, а в том замечательном, на мой взгляд, подходе, когда правит бал содержимое, а всё оформление направлено на то, чтобы удобно и приятно это содержимое преподнести.
За такой доскональный подход и внимание к удобству читателя, автору почёт и уважение.
Меня конечно раздражает безграмотность, но в данном случае этот недостаток с лихвой окупается способом подачи материала. Мне так кажется. :)
А если внезапно в AppStore завернут приложение на ревью, с какой либо отсылкой на код, ну например в виде некорректного использования приватных фреймворков из iOS SDK?
В такой ситуации все вопросы к настройкам/версиям Air? Или существуют какие-то другие способы устранения подобных неприятностей?
Прочитал только первую страницу. Затем взглядом зацепился за количество страниц и со словами «ну и хрен с ним», закрыл соглашение.
Поэтому мой вариант: «Да, читаю местами». Не будем уточнять, какими. :)
Хм. А яблочко-то — с гнильцой! Не по джентльменски это как-то.
Ведь если нет, то это просто дичайший невод для ловли компаний: закидываешь кучу исков, и хотя бы в одном-двух, но перепадёт что-нибудь.
А если заставить компенсировать расходы (а несидящих в тюрьмах — обязательно присутствовать на слушании, дорога — за свой счёт), то мне кажется многократно поубавиться желающих влезть в необоснованную тяжбу.
Или не так?
Ну в этом-то и дело.
Сейчас ради интереса посмотрел в мануал по PHP: найти описание явного приведения типов намного проще, и легче запомнить, чем немаленькие таблицы неявных приведений.
Отсюда вопрос: кто будет сознательно использовать приведение типов через арифметические (строковые) операции?
Ну и в той же Java: ну кому, кому блин может придти в голову, намеренно преобразовать число в строку через конкатенацию числа и строки? :)
Ну я еще могу понять, когда появляются странные штуки при реализации логики, взаимодействия классов. Но вот такой хитровыкрученный пример — это явный «изыск».