ООП - объектно-ориентированое программирование

Общие принципы, проектирование, модуляризация, темплейты и шаблоны

Re: ООП - объектно-ориентированое программирование

Postby Vitekkz88 on 15 Sep 2018, 19:57

Usss, следует максимально абстрагироваться, а не описывать базовый класс на все случаи жизни. Тогда будет меньше привязка к полям базового объекта и больше к полям конкретного объекта. Это позволяет локализовать ту ситуацию, о которой Вы говорите. То, что среда Вам не подсвечивает ошибку - слабая причина для грусти. Вы в любом случае клацнете по стрелочке(будет она целой или будет сломанной). Вопрос в другом: как далеко Вы готовы зайти в программировании, прежде чем проверите внесенные изменения.
В текстовых средах разработки(Qt-Creator и Eclipse абсолютно точно) вы аналогично можете не обратить внимание на подчеркивание красным цветом, если ошибка находится за пределами видимости рабочего окна(экран вмещает 50 строчек кода, а ошибка на 75-ой), про косяки в разных файлах говорить не буду - очевидно.

Kosist, ага, посмотрю всё что по ссылкам привели, спасибо! Добавлю следующую часть по ООП с доработками, наверно еще 1-2 поста будет и всё, их в этой ветке оставлю. Поставил 2018 версию, думаю она точно поддерживает нововведения из 2017 SP1.
Для паттернов создам отдельную ветку, тоже в таком ключе мыслю :brows:
Инженер - это открыто светящийся интеллект, свободный и не обидный юмор, это легкость и широта мысли...Это воспитанность, тонкость вкусов, хорошая речь, плавно согласованная и без сорных словечек...
-А. И. Солженицын
User avatar
Vitekkz88
expert
expert
 
Posts: 1033
Joined: 21 Jan 2014, 15:45
Location: Томск
Medals: 3
Activity (1) Silver (1) Автор (1)
LabVIEW Version: 12,13,14
Karma: 300
hardware I/O VIP

Re: ООП - объектно-ориентированое программирование

Postby FireFly on 20 Sep 2018, 16:35

Очень давно, когда ещё активно программировал на LabVIEW, с удовольствием использовал классы как "умные кластеры", хотя иногда и предпринимал попытки сделать интересные штуки на основе наследования (например свой аналог Actor Framework)
Но по-настоящему понял ООП и как его нужно использовать (в том числе применительно к LabVIEW) только после полутора лет программирования на C#.
Начинаешь понимать какие поля в классе делать private, какие protected и даже какие public (моё мнение - никакие :) )
Когда и зачем использовать геттеры и сеттеры, в чём их отличие от bundle by name и unbundle, зачем тратить на них время и "размер проекта".
И очень расстраивает отсутствие интерфейсов (без пляски с бубном), ведь думаю никто не поспорит, что в других языках редко можно встретить класс который реализует меньше 2-3 интерфейсов, и на это есть причина.
Вообще в LabVIEW классы нужны если ты понимаешь суть и необходимость SOLID принципов. Именно классы помогают их реализовать (хотя тут можно уйти в крайность и начать реализовывать SOLID ради реализации SOLID).
Также важно понимать, что без понимания смысла классов их использование может превратиться в культ карго.
Вообще, если честно, не уверен можно ли понять классы в LabVIEW, если программировать только на LabVIEW. По-моему, он не очень к этому располагает. В моём случае, оказался необходим опыт другого, тектового ООП языка.
Иногда лучше молчать и слыть идиотом, чем заговорить и развеять все сомнения.
User avatar
FireFly
expert
expert
 
Posts: 1321
Joined: 25 Apr 2009, 08:58
Location: Санкт-Петербург
Medals: 2
Activity (1) Black (1)
LabVIEW Version: 2014
Karma: 174

Re: ООП - объектно-ориентированое программирование

Postby Vitekkz88 on 20 Sep 2018, 19:59

Часть 4. Malleable Vis и их применение в LVOOP.
Спасибо за обратную связь и приведенные ссылки, по которым я получил хороший материал для анализа. Итак, нововведение Malleable vi. Рассмотрим, что это такое, как эта технология может помочь в LVOOP. О самой технологии:
Malleable vi – позволяет создавать виртуальные приборы, у которых входные терминал являются адаптивными. Это позволяет подавать на входы .vi данные любого типа, но работоспособность будет определяться возможностью обработать эти данные.
Профит: позволяет иметь 1 .vi для выполнения однотипных задач для разных типов данных. Сразу пример, который приводится в LV библиотеке примеров:
1.png

Malleable vi для выделения последнего элемента из массива с такой реализацией:
1.png

Входы-выходы у нас типа variant, но реализация заточена для строго определенной структуры данных – одномерный массив. Другое дело, что элементами этого массива могут быть числа, буквы, кластеры и т.д. Так же хочу отметить Type Specialization структуру:
1.png
1.png (2.43 KiB) Viewed 75 times

Она позволяет переопределить логику выполнения кода в зависимости от входного типа/структуры данных и в сочетании с Malleable vi позволяет строить приборы без высокой степени вложенности и более гибкие. По своей природе Malleable vi реализует полиморфную функцию, однако возникает резонный вопрос: чем отличаются полиморфные vi от этих самых Malleable vi в LabVIEW? Первое и самое очевидное – это способ создания и использования. Нам не нужно забоится о паттерне самого прибора(connector pane patterns). Мы можем описать логику/случай внутри Type Specialization-структуры, а для полиморфного vi нам потребуется создать отдельный прибор с реализацией и включением его в качестве экземпляра в коллекцию полиморфных приборов. Отдельным пунктом в преимуществах Malleable vi стоит использование их с классами, поскольку эти приборы способны адаптировать вход типа данных.
Ранее возникал вопрос о множественном наследование и интерфейсах, мол что делать в этом случае в LabVIEW.
Итак, я ознакомился с презентацией от Piotr Kruczkowski(Integration Engineering Services - Software Architect). Презентацию можете найти по этой ссылке(под сообщением прикреплены файлы): https://forums.ni.com/t5/LabVIEW-Archit ... -p/3804592
В ней говорится о пяти основных рекомендациях в ООП (аббревиатура SOLID) и, в особенности, о реализации пятого принципа(DIP) в LabVIEW – инверсия зависимостей, которая призвана уменьшить взаимосвязанность программных модулей. Про SOLID в том или ином виде рассказывают многие книги по ООП и паттернам проектирования. Я бы сказал, что в паттернах проектирования это раскрывается гораздо сильнее. Кроме SOLID существую и другие рекомендации, которые рассматриваются в более углубленном курсе объектно-ориентированного проектирования.
Кратко:
D — Dependency inversion principle — Принцип инверсии зависимостей: зависимости внутри системы строятся на основе абстракций. Модули верхнего уровня не зависят от модулей нижнего уровня. Абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций.
Возьмем ситуацию, когда объект класса A вызывает методы объекта класса B, значит A зависит от B. С применением этого принципа, объект типа B должен быть инстанциирован вне A и передан как зависимость в A. Говоря проще, мы должны создать интерфейс, через который объект А будет использовать объект В.
Возвращаемся к презентации. Piotr Kruczkowski предлагает использовать подход мутации классов(class mutation mechanism). Термин придуман самим автором наверно, потому что описание этого термина в других источниках я не нашел. Реализация некого интерфейса выполнена с помощью наследования и дружественных классов. В проекте классы MeasA и ViewA унаследованы от IMeasurement и IView, а в качестве описания объекта содержат объект класса А; также эти 2 класса объявлены друзьями для класса А. После этих прелюдий демонстрируется возможность использования классом А и его наследником функции классов MeasA и ViewA в духе интерфейса:
1.png

Реализуется ли инверсия зависимости в данном примере? Да, реализуется, за счет использования абстрактных методов, наследования и прослойки в виде классов. Мутация заключается в том, что классы MeasA и ViewA в качестве объекта используют объект класса А, для которого они являются друзьями.
Так же я рассмотрел примеры использования Malleable vi в классах. Начиная с 2017-ой версии SP1 эти приборы поддерживают адаптацию выходов для объектов класса. Идея с созданием отдельного класса с Malleable vi или просто отдельно Malleable vi с набором методов кажется привлекательной. Итак, мы имеем базовый класс с набором абстрактных методов. Положим, что часть этих методов необходимо вызывать в разных несвязных классах. Создаём отдельные наборы методов как Malleable vi и на вход будем подавать кластер из объектов. Внутри Type Specialization структуры будем вызывать нужный метод для текущего объекта. В этом случае потребуется дополнительно вести внятную иерархию проекта и имён тех самых Malleable vi-интерфейсов, чтобы не запутаться, кто кому что предоставляет. И опять же вся хитрость будет сводиться к созданию одного объекта класса внутри другого объекта класса для вызова его метода. Аналогично, как это делается и в мутации, когда объектом одного класса является объект другого класса и они там по ходу выполнения переопределяются где нужно. Только в случае Malleable vi будем определять вызов метода внутри Type Specialization и это может помочь привести к некоторому однообразию и визуальной понятности.
Заключение: отсутствие интерфейсов/множественного наследования приводят к тому, что приходится заниматься фокусами и вырабатывать собственный стиль либо придерживаться некого корпоративного подхода.
Пока что я выработал единственно правильный подход для LVOOP: Базовые абстрактные классы со своими детьми(конкретными реализациями объектов) и максимальная независимость одного базового класса от другого. Если возникает ситуация, что один независимый класс нуждается в исключительном методе другого класса – проще реализовать его внутри нуждающегося класса. Если же такую реализацию требует десяток объектов, имеет смысл вынести метод в базовый класс и наследовать от него эту реализацию, либо использовать Malleable vi.
Инженер - это открыто светящийся интеллект, свободный и не обидный юмор, это легкость и широта мысли...Это воспитанность, тонкость вкусов, хорошая речь, плавно согласованная и без сорных словечек...
-А. И. Солженицын
User avatar
Vitekkz88
expert
expert
 
Posts: 1033
Joined: 21 Jan 2014, 15:45
Location: Томск
Medals: 3
Activity (1) Silver (1) Автор (1)
LabVIEW Version: 12,13,14
Karma: 300
hardware I/O VIP

Re: ООП - объектно-ориентированое программирование

Postby Vitekkz88 on 20 Sep 2018, 20:14

FireFly писал(а):Вообще, если честно, не уверен можно ли понять классы в LabVIEW, если программировать только на LabVIEW.
Однозначно - нет! Дело даже не столько в программировании, сколько в понятии самой парадигмы и как ей пользоваться. Язык - это средство реализации. В каждом языке есть свои фишки, которые помогают по всякому. Ну и недостатки тоже есть, куда уж без них)
FireFly писал(а):Начинаешь понимать какие поля в классе делать private, какие protected и даже какие public (моё мнение - никакие :) )
На первом этапе вообще всё закрывать, и поля и методы. Открывать только тогда, когда попросят. Твой класс - твои правила.
Инженер - это открыто светящийся интеллект, свободный и не обидный юмор, это легкость и широта мысли...Это воспитанность, тонкость вкусов, хорошая речь, плавно согласованная и без сорных словечек...
-А. И. Солженицын
User avatar
Vitekkz88
expert
expert
 
Posts: 1033
Joined: 21 Jan 2014, 15:45
Location: Томск
Medals: 3
Activity (1) Silver (1) Автор (1)
LabVIEW Version: 12,13,14
Karma: 300
hardware I/O VIP

Previous

Return to Модели программирования

Who is online

Users browsing this forum: No registered users and 1 guest

cron