Мой подход. Ядро - Движок. - страница 17
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Верно тут выше замечено - подход напоминает паскалевский ТурбоВижн. Хотя, уже в этой библиотеке были заложены и контроль типов, и инкапсуляционные ограничения.
я вспоминал Паскаль ибо видел его и даже Турбовижн успел пару раз подключать на занятиях... воспоминания крайне неприятные, все что помню как ни крутил это Турбовижн - все равно можно было получить на выходе только Нортон Командер - все было очень узкоспециализированно, если не ошибаюсь, то в Паскале 6.0 не было еще ООП
я вспоминал Паскаль ибо видел его и даже Турбовижн успел пару раз подключать на занятиях... воспоминания крайне неприятные, все что помню как ни крутил это Турбовижн - все равно можно было получить на выходе только Нортон Командер - все было очень узкоспециализированно, если не ошибаюсь, то в Паскале 6.0 не было еще ООП
Как я помню, ТурбоВижн - как раз и была первой ООП-библиотекой (с неполной тогда еще поддержкой идеологии, но все-таки), и появилась она именно в Паскале 6.0
Поглядел в Википедию. вроде бы она со мной согласна.
Как я помню, ТурбоВижн - как раз и была первой ООП-библиотекой (с неполной тогда еще поддержкой идеологии, но все-таки), и появилась она именно в Паскале 6.0
Поглядел в Википедию. вроде бы она со мной согласна.
увы, я как то удачно этот момент в моем обучении прошел - ООП показали только на С++, дальше лет через 5 самостоятельно на Делфи перешел, Паскаль в моем видении остался как процедурный язык программирования
Как я помню, ТурбоВижн - как раз и была первой ООП-библиотекой (с неполной тогда еще поддержкой идеологии, но все-таки), и появилась она именно в Паскале 6.0
Поглядел в Википедию. вроде бы она со мной согласна.
Полноценное ООП для Паскаля впервые появилось в Delphi. Turbo Vision касалось исключительно текстового GUI под Ms-DOS.
Полноценное ООП для Паскаля впервые появилось в Delphi. Turbo Vision касалось исключительно текстового GUI под Ms-DOS.
Ну, так я и говорю - "с неполной поддержкой". Шестой паскаль был "Паскаль с объектами". И верно, ТурбоВижн - это был исключительно оконный интерфейс. Ну, примерно то, что Петер и предлагает вниманию.
На самом деле, творение Петера - достаточно интересно. Вопросы вызывает именно применимость. Я вот уже не раз сталкивался с тем, что именно отсутствие глобально доступных объектов и всемерная инкапсуляция кода, работа исключительно через чисто виртуальные интерфейсы предупреждало много ошибок, и помогало в поддержке и исправлении багов. Собственно, Петер верно заметил - "исходя из удобства программиста".
Полный доступ к массиву всех возможностей - в теории-то, действительно, позволяет достичь большей эффективности работы, за счет отсутствия накладных расходов на интерфейсные обертки, на контроль и преобразование типов, на следование протоколов доступа к объектам... Однако, все это достигается как раз за счет того, что все эти вещи - должен помнить и учитывать сам программист.
Получается, что мы таким подходом, вместо того, чтобы всемерно перекладывать работу на компьютер, берем ее на себя. Петер, как титан запоминания - не тяготится этим. Но, боюсь, остальным это будет весьма напряжно. И соглашаться на это можно как раз ради каких-то больших преимуществ. Увы, я их не вижу. Особенно, с учетом того, что Петер ориентируется не на автоматическую, а на ручную торговлю.
Секрет запоминания в том, что твое мышление должно быть структурировано. Ты должен смотреть на код через призму ООП, но при этом сам ООП не использовать. Это я и делаю. У тебя ООП в программе, у меня, - в голове.
Поэтому, я получаю преимущества ООП и преимущества его отсутствия. А ты только преимущества ООП.
Секрет запоминания в том, что твое мышление должно быть структурировано. Ты должен смотреть на код через призму ООП, но при этом сам ООП не использовать. Это я и делаю. У тебя ООП в программе, у меня, - в голове.
Поэтому, я получаю преимущества ООП и преимущества его отсутствия. А ты только преимущества ООП.
Напомнило:
Поэтому, я получаю преимущества ООП и преимущества его отсутствия. А ты только преимущества ООП.
сложно сказать, что Вы видите, но скажу, что если взять готовый класс, вынести его методы и поля на глобальный уровень видимости (развернуть) то получим Ваш подход, потом уже поля назовем ядром и движком и получим... получим неуправляемый код, который можно писать с нуля, но нельзя модифицировать
ЗЫ:
чем ООП интересно? - да хотя бы тем, что программист не парится постоянно придумывать новые имена переменных! - создал базовый класс, написал, там все что видишь на данный момент и все.... время подошло, сделал наследование - получил сразу кучу переменных от базового класса, не нужно наследование, просто создал экземпляр класса (да хоть массив классов!) - и получил сразу все переменные которые разделены под каждый обьект (класс)... ООП как минимум это практично , а скорость выполнения... ну так всегда или напрямую с регистрами процессора работаем или используем языки высокого уровня, обычно вычислительных мощностей хватает писать все как удобно, если не хватает мощностей, тогда начинаем профилировать и переписывать проблемные участки кода - мало кто этим занимается
сложно сказать, что Вы видите, но скажу, что если взять готовый класс, вынести его методы и поля на глобальный уровень видимости (развернуть) то получим Ваш подход, потом уже поля назовем ядром и движком и получим... получим неуправляемый код, который можно писать с нуля, но нельзя модифицировать
ЗЫ:
чем ООП интересно? - да хотя бы тем, что программист не парится постоянно придумывать новые имена переменных! - создал базовый класс, написал, там все что видишь на данный момент и все.... время подошло, сделал наследование - получил сразу кучу переменных от базового класса, не нужно наследование, просто создал экземпляр класса (да хоть массив классов!) - и получил сразу все переменные которые разделены под каждый обьект (класс)... ООП как минимум это практично , а скорость выполнения... ну так всегда или напрямую с регистрами процессора работаем или используем языки высокого уровня, обычно вычислительных мощностей хватает писать все как удобно, если не хватает мощностей, тогда начинаем профилировать и переписывать проблемные участки кода - мало кто этим занимается
Меня в ООП отталкивает жесткий формат написания кода. Как Вы видели, я склонен составлять большие таблицы данных и считаю это очень практичным. В ООП мне придется придерживаться кучи правил, которые лично меня очень сковывают.
Короче, я программирую с другим ООП. Своим. Там мало правил и много свободы. Функционал сам складывается в большие блоки, а данные организуются в ядрах. Я даже специально не продумываю их структуру. Все само развивается. На интуитивном уровне.