Проблема типизации
Проблема типизации
Эффективное применение объектной технологии требует четкого описания в тексте системы типов всех объектов, с которыми она работает на этапе выполнения. Это правило, известное как статическая типизация (static typing), делает наше ПО:
[x]. более надежным, позволяя компилятору и другим инструментальным средствам устранять несоответствия прежде, чем они смогут нанести вред;
[x]. более понятным, обеспечивая точной информацией читателей: авторов клиентских систем и тех, кто будет сопровождать систему;
[x]. более эффективным, поскольку информация о типах данных позволит компилятору сгенерировать оптимальный код.
Хотя вопросами типизации данных активно занимались и вне объектной среды, да и сама статическая типизация применяется в языках, не поддерживающих ООП, особенно ярко эти идеи проявили себя именно при объектном подходе, во многом основанном на понятии типа, которое, сливаясь с понятием модуля, образует базовую ОО-конструкцию - класс.
О типизации при ОО-разработке можно сказать одно: эта задача проста в своей постановке, но решить ее подчас нелегко.
Более 800 000 книг и аудиокниг! 📚
Получи 2 месяца Литрес Подписки в подарок и наслаждайся неограниченным чтением
ПОЛУЧИТЬ ПОДАРОКЧитайте также
Проблема наследования
Проблема наследования Если существует необходимость наследовать от класса Singleton, то следует придерживаться определенных правил.Во-первых, класс-наследник должен переопределить метод Instance(), так, чтобы создавать экземпляр производного класса. Если не предполагается, что
Но в чем тогда проблема?
Но в чем тогда проблема? Обобщенный указатель всего лишь «прикидывается» указателем и не может быть использован везде, где используются обычные указатели. Например, возьмем адаптер указателя на функцию-член класса из STL:template<class R, class T> mem_fun_t<R, T> mem_fun(R (T::*pm)());
Проблема состояния
Проблема состояния В начале предыдущей главы было указано, что HTTP является сетевым протоколом, не обеспечивающим сохранение состояний. Именно этот факт делает процесс разработки Web-приложений столь отличающимся от процесса построения выполняемого компоновочного
ПРОБЛЕМА ВВОДА
ПРОБЛЕМА ВВОДА Существует несколько способов последовательного ввода набора данных, скажем чисел. Мы обсудим здесь некоторые из них, переходя от менее удобных к более удобным. Вообще говоря, наименее удобный способ - это тот, который мы только что использовали;
5.1.8. Проблема выбора
5.1.8. Проблема выбора Благодаря совместному использованию памяти можно организовать быстрое двустороннее взаимодействие произвольного числа процессов. Любой пользователь сможет получать доступ к сегментам памяти для чтения/записи, но для этого программа должна
В чём ваша проблема?
В чём ваша проблема? Разрабатывайте ПО для себяПри создании программ большую часть времени будет занимать решение ваших собственных проблем. Вы и будете тем самым потенциальным клиентом, соответственно и знание о необходимом у вас уже есть. Это даёт вам отличное начало
Проблема тогда, когда это проблема
Проблема тогда, когда это проблема Не тратьте бесцельно время на проблемы, которых у вас еще нетВам действительно нужно волноваться о вычислениях для 100 000 потребителей сегодня, если это будет у вас через два года?Действительно вам нужно нанять восемь программистов, если
Проблема выбора
Проблема выбора Автор: Олег ВолошинПохоже, что развитие цифровых камер достигло некоторого промежуточного потолка. Нет, разумеется, в техническом плане есть масса перспективных направлений.Тем не менее отличие новой камеры, выпущенной "на днях", от аналогичной, но
Техническая проблема
Техническая проблема Как же должен выглядеть повторно используемый модуль?
Проблема
Проблема Рассмотрим пример стека, но уже не как АТД, а как класс. Мы знаем, как написать класс INTEGER_STACK, задающий стек объектов типа INTEGER. Компоненты будут включать count (число элементов), put (вталкивание элемента), item (элемент в вершине), remove (выталкивание элемента), empty (пустой ли
Роль типизации
Роль типизации Зачем настаивать на явном объявлении типов (первое из двух требований)? Это часть главного вопроса о типизации, которому в этой книге посвящена отдельная лекция (лекция 17). Но уже сейчас можно указать две основные причины, по которым ОО-программа должна быть
Правило типизации
Правило типизации Правило типизации, делающее допустимым первый набор и недопустимым второй, интуитивно понятно, но его надо уточнить.Вначале рассмотрим обычные, не родовые классы. Пусть C такой класс. Рассмотрим объявление его компонента, не использующее, естественно,
Проблема
Проблема Из этих примеров ясно: нам может понадобиться механизм удостоверения типа объекта.Решение этой проблемы, возникающей в специфических, но критически важных случаях, должно быть найдено без потери преимуществ ОО-стиля разработки. В частности, мы не хотим
Правила типизации
Правила типизации Наша ОО-нотация является статически типизированной. Ее правила типов были введены в предыдущих лекциях и сводятся к трем простым требованиям.[x]. При объявлении каждой сущности или функции должен задаваться ее тип, например, acc: ACCOUNT. Каждая подпрограмма
Аргументы в пользу динамической типизации
Аргументы в пользу динамической типизации Несмотря на все это, динамическая типизация не теряет своих приверженцев, в частности, среди Smalltalk-программистов. Их аргументы основаны прежде всего на реализме, речь о котором шла выше. Они уверены, что статическая типизация