К слову, не мобильная версия Википедии, тоже работает. Там просто поверх обычного контента выводится div всё прячущий. При желании в инспекторе/firebug'е это можно исправить и получить доступ к немобильной версии.
что удивительного? надо быть дебилом или НЛО, чтобы минусовать подобный пост. все люди хотят хорошо спать. ) из-за отсутствия отрицательного нивелирования топик и имеет столько плюсов.
Более того, уже давно существует и используется протокол OpenSearch, клиентами которого могут быть всякие «быстрые поисковики», находящиеся справа от строки URI в FF, Opera и IE.
Он позволяет любому сервису описать структуру входящего запроса, ответом на который будет обычная HTML-страница «результатов поиска». А также описать XML с данными «поискового сервиса», который браузер сможет добавить в список тех самых быстрых поисковиков легко и прозрачно.
да юзерам вКонтакте насрать на эту премию вообще. даже висячая реклама в новостях не позволила контакту победить в прошлом году.
побеждать там осознанно могут только сайты типа башорга или хабра. т.е. со знакомой с IT аудиторией.
Я не могу понять смысл фразы Мейерса в словах «functions that might be broken»… Кем broken? Какого фига он их broken? =)
Ведь из термина инкапсуляции в ключе взаимодействия классов само-собой вытекает необходимость сохранения 100% внешнего интерфейса класса, если мы хотим обеспечить дальнейшую работоспособность его клиентов.
Если это принять как постулат в текущей ситуации, то значит мы должны озаботиться тем, чтобы у класса всегда оставались N публичных методов, через которые с ним работают клиенты. И никакая имплементация этого класса не должна менять ожидаемого результата работы этих методов. Т.е. нужно соблюдать обычные рамки входных и выходных аргументов. Если мы придерживаемся этих условий, то и недостаточной инкапсуляции, по моему, не возникает в принципе.
Ну не может же метод calcSin(double grad) после изменений в нём начать форматировать винчестер, какие бы изменения в ней не были произведены? Это же фантастика. Если реализована хорошая атомарность классов и их (хотя бы публичных) методов, то ситуаций изменения смысла и типа возвращаемого клиенту значения просто не возникает.
С всем утвержеднием «gauge the amount of encapsulation in a class is to count the number of functions that might be broken if the class's implementation changes» я не согласен…
Инкапсуляция это ведь не гарантия того, что класс будет работать после ковыряния в нём программиста (broken'а функций, эволюции класса), а принцип того, что у нас есть возможность выделить общедоступный способ взаимодействия с классом и спрятать сокровенные потроха от жадных рук. Ничего большего она нам сама по себе не позволяет делать. Если мы изменили правила общедоступного обращения, то тут уж как не крути, а всем остальным нужно перестраиваться.
В общем, я до сих пор проблематики с точки зрения проектирования уловить не смог :\
1) То есть вопрос дистрибьюции программного пакета вынуждает нас менять архитектуру этого пакета?.. Как-то странно. Понимаю, что решение подобных вопросов позволяет уменьшить время, затрачиваемое на внедрение обновлённого компонента или автоматизацию какой-то части рутинной работы. Но здесь идея преподносится так, как будто это реально оправданная задача с точки зрения ООПроектирования.
2) Как клиенты могут использовать приватную функцию?.. Зачем им вообще знать, что приватный метод класса изменился? Ведь клиент использует класс полностью через внешний интерфейс, как чёрный ящик. Я прав? Просто отдаём из новый скомпилированную библиотеку, если это абсолютно чёрный ящик. Или отдаём новые сорцы класса на компиляцию, гарантируя то, что внушний интерфейс класса остался прежним, а изменился лишь приватный метод.
3) Зачем что-то прятать от людей? Если метод реализован как private, то уже никакому нормальному человеку не должно приходить в голову пытаться переопределять его. Разве не так? Если ему нужно изменять приватные методы, то значит класс плохо спроектирован, либо в него не были заложены понадобившиеся возможности. Это вопрос рефакторинга. Просто опять не могу увидеть плюса в этих прятаньях метода от кого-то.
Я так понял, у вас файлы с вынесенными в статичными функциями компилируются как некая отдельная библиотека, раз уж вы упоминаете вопросы перекомпиляции. Но, по моему, выигрыша во времени или чем-либо другом, при возникновении необходимости перекомпиляции из-за внесенных изменений в private методах классах, совершенно не возникает.
P.S. Я в проблематике компилируемых языков плохо разбираюсь, совсем неофит. Поэтому, может, мои рассуждения со стороны выглядят нелепо или вообще походят на софизм. Вы скажите, промолчу и пойду читать Страуструпа ))
Может не во всём хорошо разобрался, заранее приношу извинения, но вот пара вопросов, возникших у меня:
Почему вообще возникает желание выносить приватные методы куда-либо из класса? Ведь на приватные, как на неизменные, ложится реализация базиса класса, его костяк, которые никаким наследованием не должен принципиально изменяться. Именно в продумывании приватного поведения (внутреннего программного интерфейса) заключается продумывание поведение класса. Чаще всего именно так, имхо.
Почему, опять же, поднимается вопрос прятанья каких-либо методов от интерфейса класса, если эти методы являются приватными? Это ведь абсолютно внутренний интерфейс, а не внешний. Зачем его куда-то ещё прятать, если он уже приватный и недоступный никому из-вне?
Прекрасная тема! Удачный красивый синтез программирования с поэзией и искусством смотрится потрясающе =) Есть в этом что-то магическое! ) И наталкивающее на автоматизацию распознавания «прекрасности» текстов.
WoW — лучшая MMORPG!!!
Он позволяет любому сервису описать структуру входящего запроса, ответом на который будет обычная HTML-страница «результатов поиска». А также описать XML с данными «поискового сервиса», который браузер сможет добавить в список тех самых быстрых поисковиков легко и прозрачно.
По моему геймерский Antec Nine Hundred он не переплюнет…
побеждать там осознанно могут только сайты типа башорга или хабра. т.е. со знакомой с IT аудиторией.
Ведь из термина инкапсуляции в ключе взаимодействия классов само-собой вытекает необходимость сохранения 100% внешнего интерфейса класса, если мы хотим обеспечить дальнейшую работоспособность его клиентов.
Если это принять как постулат в текущей ситуации, то значит мы должны озаботиться тем, чтобы у класса всегда оставались N публичных методов, через которые с ним работают клиенты. И никакая имплементация этого класса не должна менять ожидаемого результата работы этих методов. Т.е. нужно соблюдать обычные рамки входных и выходных аргументов. Если мы придерживаемся этих условий, то и недостаточной инкапсуляции, по моему, не возникает в принципе.
Ну не может же метод calcSin(double grad) после изменений в нём начать форматировать винчестер, какие бы изменения в ней не были произведены? Это же фантастика. Если реализована хорошая атомарность классов и их (хотя бы публичных) методов, то ситуаций изменения смысла и типа возвращаемого клиенту значения просто не возникает.
С всем утвержеднием «gauge the amount of encapsulation in a class is to count the number of functions that might be broken if the class's implementation changes» я не согласен…
Инкапсуляция это ведь не гарантия того, что класс будет работать после ковыряния в нём программиста (broken'а функций, эволюции класса), а принцип того, что у нас есть возможность выделить общедоступный способ взаимодействия с классом и спрятать сокровенные потроха от жадных рук. Ничего большего она нам сама по себе не позволяет делать. Если мы изменили правила общедоступного обращения, то тут уж как не крути, а всем остальным нужно перестраиваться.
В общем, я до сих пор проблематики с точки зрения проектирования уловить не смог :\
2) Как клиенты могут использовать приватную функцию?.. Зачем им вообще знать, что приватный метод класса изменился? Ведь клиент использует класс полностью через внешний интерфейс, как чёрный ящик. Я прав? Просто отдаём из новый скомпилированную библиотеку, если это абсолютно чёрный ящик. Или отдаём новые сорцы класса на компиляцию, гарантируя то, что внушний интерфейс класса остался прежним, а изменился лишь приватный метод.
3) Зачем что-то прятать от людей? Если метод реализован как private, то уже никакому нормальному человеку не должно приходить в голову пытаться переопределять его. Разве не так? Если ему нужно изменять приватные методы, то значит класс плохо спроектирован, либо в него не были заложены понадобившиеся возможности. Это вопрос рефакторинга. Просто опять не могу увидеть плюса в этих прятаньях метода от кого-то.
Я так понял, у вас файлы с вынесенными в статичными функциями компилируются как некая отдельная библиотека, раз уж вы упоминаете вопросы перекомпиляции. Но, по моему, выигрыша во времени или чем-либо другом, при возникновении необходимости перекомпиляции из-за внесенных изменений в private методах классах, совершенно не возникает.
P.S. Я в проблематике компилируемых языков плохо разбираюсь, совсем неофит. Поэтому, может, мои рассуждения со стороны выглядят нелепо или вообще походят на софизм. Вы скажите, промолчу и пойду читать Страуструпа ))
Почему вообще возникает желание выносить приватные методы куда-либо из класса? Ведь на приватные, как на неизменные, ложится реализация базиса класса, его костяк, которые никаким наследованием не должен принципиально изменяться. Именно в продумывании приватного поведения (внутреннего программного интерфейса) заключается продумывание поведение класса. Чаще всего именно так, имхо.
Почему, опять же, поднимается вопрос прятанья каких-либо методов от интерфейса класса, если эти методы являются приватными? Это ведь абсолютно внутренний интерфейс, а не внешний. Зачем его куда-то ещё прятать, если он уже приватный и недоступный никому из-вне?