4. vector<vector<int>> getData()
{
vector<vector<int>> vector1;
for (auto x = vector.begin();
x != vector.end(); ++x)
{ Це може бути легко
if (x->at(0) == 4) (для вас)
{ (зараз)
vector1.push_back(*x);
}
}
return vector1;
}
http://amzn.com/0132350882
5. vector<vector<int>> getFlaggedCells()
{
vector<vector<int>> flaggedCells;
for (auto cell : gameBoard)
{
if (cell.at(STATUS) == FLAGGED)
{
flaggedCells.push_back(cell);
}
}
Цей код легший для
return flaggedCells;
розуміння
}
http://amzn.com/0132350882
6. vector<Cell> getFlaggedCells()
{
vector<Cell> flaggedCells;
for (auto cell : gameBoard)
{
if (cell.isFlagged())
{
flaggedCells.push_back(cell);
}
} Цей код легший і
return flaggedCells; простіший!
}
8. Простота і складність об’єктивні і абсолютні
Легкість і важкість суб’єктивні і відносні
Складно – коли функція відповідає за
декілька концепцій:
Що + Як
I/O + бізнес правила
БД + бізнес правила
Concurrency + domain
…
18. Coupling (зв’язність)
• Afferent
– Скільки компонентів залежать від модуля
– Показує наскільки модуль відповідальний
• Efferent
– Від скількох компонентів залежить модуль
– Показує наскільки модуль незалежний
– Включає: наслідування, interface impl, типи
параметрів, типи змінних, exceptions,...
• Ca and Ce є метриками стабільності
19. Instability
I = Ce / (Ce + Ca)
Ce Ca
• показує нестійкість до змін
• 0 – стабільний модуль
• 1 – нестабільний
20. Cohesion (пов’язаність, зчеплення)
• Показує наскільки сильні взаємозв’язки між
частинами одного модулю
• Чи всі методи класу використовують всі
його поля
• Низька пов’язаність:
– Клас з багатьма статичними методами
– “Несфокусований” клас
21. Cohesion
Кореляція:
high complexity and low cohesion
Кореляція:
complexity and number of defects
22. Low coupling + high cohesion
сприяють легкому внесенню змін у ПЗ
Більшість шаблонів проектування є
рецептами для зниження coupling та
підвищення cohesion
29. High level
module
Course IEmailSender
Dependency is
inverted
SmtpEmailSender
30. Dependency inversion
• High level modules should not depend on
low-level modules
• Both should depend on abstractions
• Abstractions should not depend on details
• Details should depend on abstractions
31. Lower coupling
Що отримуємо
• Залежності вказуються явно, немає прихованих
залежностей
• Класи самодокументовані
• Класи більше не відповідають за створення об’єктів
• Після створення клас гарантовано знаходиться у
робочому стані
• Легко знаходити класи з багатьма параметрами в
конструкторі (і зменшувати їх відповідальності)
• Легше знаходити методи, яким потрібні не всі
залежності класу
32. class UsersImporter
{
public:
void import()
{
auto importContext =
new ImportContext(currentUserName);
// ...
fileImporter->import();
// ...
}
};
33. void import()
{
auto importContext =
new ImportContext(currentUserName);
// ...
IFileImporter* fileImporter =
new CsvFileImporter(importContext);
fileImporter->import();
// ... ? Залежить від ImportContext
delete fileImporter;
? Тип повинен визначатись
} залежно від ImportContext
? Потрібно керувати часом
життя FileImporter’а
34. Abstract Factory. Потреба:
• Залежність залежить від параметра, який не
відомий клієнту на час його створення
• if/else та switch блоки для вирішення, яку
залежність створити
• Залежність потрібно до-ініціалізувати
• Об’єкт повинен керувати часом життя
залежності
