В данном докладе мы рассмотрим пять основных принципов дизайна классов в объектно-ориентированном проектировании, которые известны, как принципы SOLID. А также как обеспечить достаточный уровень гибкости, связанности, управляемости, стабильности и понятности кода.
Sergey Teplyakov, .NET Expert, “SOLID Principles in the real world”:
• Why design principles matters?
• SOLID principles in the real world
S – Single Responsibility Principle
O – Open-Closed Principle
L – Liskov Substitution Principle
I – Interface Segregation Principle
D – Dependency Inversion Principle
В данном докладе мы рассмотрим пять основных принципов дизайна классов в объектно-ориентированном проектировании, которые известны, как принципы SOLID. А также как обеспечить достаточный уровень гибкости, связанности, управляемости, стабильности и понятности кода.
Sergey Teplyakov, .NET Expert, “SOLID Principles in the real world”:
• Why design principles matters?
• SOLID principles in the real world
S – Single Responsibility Principle
O – Open-Closed Principle
L – Liskov Substitution Principle
I – Interface Segregation Principle
D – Dependency Inversion Principle
Описан подход к внесению изменений в автоматные программы, позволяющий уменьшить число модификаций, которые могут привести к появлению ошибок. Подход основан на применении рефакторингов автоматных программ – последовательности небольших эквивалентных преобразований, сохраняющих поведение,. Предложен ряд рефакторингов автоматных программ, расширяющий набор классических рефакторингов на случай автоматного программирования.
TMPA-2015 Paper: Автоматизированное создание тест-кейсов для тестирования сое...Iosif Itkin
Tools & Methods of Program Analysis Conference in St. Petersburg
Современные брокерские, биржевые и
клиринговые платформы неотделимы от финансовых
протоколов, обеспечивающих интеграцию подсистем и
подсоединение пользовательских систем. Верификация
корректной работы протоколов и подключений является неотъемлемой частью тестирования любой реализации
программного обеспечения для таких платформ. В данной
статье рассмотрен комплексный подход к
автоматизированной генерации тест-кейсов для
тестирования различных финансовых протоколов. Выявлены требования к документации, необходимые для
реализации данного подхода, а именно к способам описания
словарей сообщений и способам описания состояний и
переходов между ними. Рассмотрена реализация
стандартного протокола распространения данных о котировках - ITCH. Предложены способы
автоматизированной генерации тест-кейсов для его динамической верификации. Ключевые слова—протокол, тестирование протоколов, protocol testing, connectivity testing, XML, XSD, workflow, конечные автоматы, словарь, dictionary, Finite State Machine,
FSM, UML, SCXML, инструменты тестирования, testing tools
Быть разработчиком: вызовы, ожидания, перестроение мозговSergey Nemchinsky
Программное выступление по всем вопросам разработки софта, не связанным с программами. Ценности, личности, общение, задачи
https://www.youtube.com/watch?v=_jJDaHaY4GE
2. Содержание
Что такое рефакторинг кода
Методы рефакторинга
Изменение сигнатуры метода (Change Method Signature)
Инкапсуляция поля (Encapsulate field)
Выделение метода (Extract Method)
Перемещение метода (Move Method)
Замена условного оператора полиморфизмом (Replace
Conditional with Polymorphism)
Проблемы, возникающие при проведении
рефакторинга
Средства автоматизации рефакторинга
3. Что такое рефакторинг
Рефакторинг или Реорганизация —
процесс полного или частичного
преобразования внутренней структуры
программы при сохранении её внешнего
поведения.
В его основе лежит последовательность
небольших эквивалентных (т.е.,
сохраняющих поведение) преобразований.
4. Что такое рефакторинг
Поскольку каждое преобразование маленькое,
программисту легче проследить за его правильностью, и в
то же время, вся последовательность может привести к
существенной перестройке программы и улучшению её
согласованности и четкости.
Рефакторинг позволяет разрабатывать архитектуру
программы постепенно, откладывая проектные решения до
тех пор, пока не станет более ясной их необходимость.
Рефакторинг изначально не предназначен для исправления
ошибок и добавления новой функциональности, но
помогает избежать ошибок и облегчить добавление
функциональности.
5. Методы рефакторинга
Наиболее употребимые методы рефакторинга:
Изменение сигнатуры метода (Change Method Signature)
Инкапсуляция поля (Encapsulate Field)
Выделение класса (Extract Class)
Выделение интерфейса (Extract Interface)
Выделение локальной переменной (Extract Local Variable)
Выделение метода (Extract Method)
Генерализация типа (Generalize Type)
Встраивание (Inline)
Введение фабрики (Introduce Factory)
Введение параметра (Introduce Parameter)
Подъём поля/метода (Pull Up)
Спуск поля/метода (Push Down)
Замена условного оператора полиморфизмом (Replace Conditional with
Polymorphism)
6. Изменение сигнатуры метода
(Change Method Signature)
Заключается в добавлении, изменении или
удалении параметра метода.
Изменив сигнатуру метода, необходимо
скорректировать обращения к нему в коде всех
клиентов.
Это изменение может затронуть внешний
интерфейс программы, кроме того, не всегда
разработчику, изменяющему интерфейс,
доступны все клиенты этого интерфейса, поэтому
может потребоваться та или иная форма
регистрации изменений интерфейса для
последующей передачи их вместе с новой
версией программы.
7. Инкапсуляция поля
(Encapsulate field)
В случае, если у класса имеется
открытое поле, необходимо сделать
его закрытым и обеспечить методы
доступа.
После "Инкапсуляции поля" часто
применяется "Перемещение метода".
8. Выделение метода (Extract
Method)
Заключается в выделении из длинного и/или требующего
комментариев кода отдельных фрагментов и преобразовании их в
отдельные методы, с подстановкой подходящих вызовов в местах
использования.
В этом случае действует правило: если фрагмент кода требует
комментария о том, что он делает, то он должен быть выделен в
отдельный метод и назван так, чтобы исключить комментарий как
таковой.
Также правило: один метод не должен занимать более чем один
экран (25-50 строк, в зависимости от условий редактирования), в
противном случае некоторые его фрагменты имеют
самостоятельную ценность и подлежат выделению.
Из анализа связей выделяемого фрагмента с окружающим
контекстом делается вывод о перечне параметров нового метода и
его локальных переменных.
10. Замена условного оператора
полиморфизмом (Replace
Conditional with Polymorphism)
Условный оператор с несколькими ветвями
заменяется вызовом полиморфного
метода некоторого базового класса,
имеющего подкласссы для каждой ветви
исходного оператора.
Выбор ветви осуществляется неявно, в
зависимости от того, экземпляру какого из
подклассов оказался адресован вызов.
11. Замена условного
оператора полиморфизмом
Последовательность действий:
вначале следует создать базовый класс и нужное число
подклассов
в некоторых случаях следует провести оптимизацию условного
оператора путем "Выделения метода"
возможно использование "Перемещения метода", чтобы
поместить условный оператор в вершину иерархии
наследования
выбрав один из подклассов, нужно конкретизировать в нём
полиморфный метод базового класса и переместить в него
тело соответствующей ветви условного оператора.
повторить предыдущее действие для каждой ветви условного
оператора
заменить весь условный оператор вызовом полиморфного
метода базового класса
12. Проблемы, возникающие при
проведении рефакторинга
проблемы, связанные с базами
данных
проблемы изменения интерфейсов
трудности при изменении дизайна