Iterative architecture

Iterative Architecture
How SOLID Principals, Design Patterns, and
Unit Testing work together to reduce tech debt iteratively.

It’s dangerous to go alone! Take this.
• Single Responsibility
• Open-Close
• Liskov Substitution
• Interface Segregation
• Dependency Inversion

Let’s code a digital library…
class Book
{
string getTitle()…
string getText()…
string getAuthor()…
bool print()…
}

Single Responsibility Principal
• Each class should do ONE
thing and only ONE thing.
• Classes should be as small
as possible. Then make
them smaller.

How do we fix it?
class Book
{
string getText()…
bool print() {
return Printer.print(currentPage);
}
}
class Printer
{
bool print(string text)…
}
class Visitor
{
bool read(book)…
}

Interface Segregation Principal
• Interfaces should not be
“fat”.
• If you implement an
interface, it should mean
that you need the whole
thing.

Better…
class Book
{
string getText()…
}
class Printer
{
bool print(string text)…
}
class BookPrinter
{
bool printBook(Book book) {
return Printer.print(book.getText()));
}
}

Dependency Inversion Principal
• Classes should depend on
abstractions, not
implementations.
• Basically, depend on
Interfaces, Base Classes,
Abstract Classes, etc…

The Bridge Pattern
interface PrinterBridge
{
Document document
Printer printer;
bool printDocument()…
}
class Book: Document {…
class BookPrinterBridge: PrinterBridge
{
Book document;
Printer printer;
bool printDocument() {
return printer.print(book.getText()));
}
}

Design Patterns
• The most correct solution to a
problem.
• Should anticipate future issues, so
you don’t have to.
• They fit together like building
blocks!

Which is better?
class BookPrinterBridge: PrinterBridge
{
Book book;
Printer printer;
bool printDocument() {
return printer.print(book.getText()));
}
}
…
class Book
{
string getText()…
bool print()…
}

What if we test it?
class BookTests
{
Book target;
bool BookCanPrintBook() {
return target.printBook();
}
}
class Printer
{
bool print(string text) {
throw Exception(“there is a bug…”);
}
}
class BookPrinterTests
{
BookPrinter target;
bool BookPrinterCanPrintBook() {
return target.printBook();
}
}

Unit Testing
• Writing tests helps guarantee that
your code follows good design.
• Tests should be simple enough to
inspire confidence.
• Testing should increase your
development speed.

Have you ever had to write tests like this?
class EmailServiceTests
{
bool canUpdateEmail() {
var mockUsers = new Mock<UserService>();
mockUsers.add(new User() {
Name = “Test”,
Id = 1,
Login = “test”,
Password = “*****”
});
var mockRoles = new Mock<RoleService>();
mockRoles.add(new Role() {
Name = “Test”,
Id = 1
});
var mockPermissions = new Mock<PermissionService>();
mockPermissions.add(new Permission() {
Name = “CanTest”,
Id = 1
});
…
target = new EmailService()
return target.updateEmail(
“test@test.test”,
“Because reasons…”,
new User() {
Name = “Test”,
Id = 1
}
);
}
}

What would good tests look like?
class EmailServiceTests
{
EmailService target;
bool canUpdateEmail() {
return target.updateEmail(userId: 1, email: “test”);
}
}
class AuthenticationServiceTests
{
AuthenticationService target;
bool testIsAuthenticated() {
var mockRoles = new Mock<RoleService>();
mockRoles.add(new Role() {
Name = “Test”,
Id = 1
});
var mockPermissions = new Mock<PermissionService>();
mockPermissions.add(new Permission() {
Name = “CanTest”,
Id = 1
});
return target.isAuthenticated(userId: 1, “CanTest”);
}
}
class EmailAuthenticatorTests
{
EmailAuthenticatorService target;
bool canUpdateEmailWithAuth() {
return target.updateEmail(userId: 1, email: “test”);
}
}

The Decorator Pattern
class AuthenticationDecoratorTests
{
AuthenticationDecorator target;
bool callsAuthBefore() {
var mockService = new Mock<SomeService>();
target.decorates(mockService);
return target.someMethod();
}
}
…
[Authorize]
void someMethod() {…

Lets start with some requirements…
• You are a developer for your favorite project management
software!
• You are trying to populate the dropdown that lets you select a
story’s status.
• You want to add safeguards so that story cards cannot change
state without passing certain checks.

Some examples…
Backlog > Ready > In-Progress > QA > Done
• Stories must have UI mock-ups to move from Backlog to Ready.
• Stories must get PO sign off to move to Done from anywhere.
• Stories can go back to InProgress if they fail QA.
• Stories can skip to Done if that story is a bug that is not reproducible.

So you come across this…
class StatusOptions
{
string[] getStatuses(storyCard) {
if (STATUS) {
if (CONDITION) {
return [“Done”, “QA”];
}
} else if (STATUS or STATUS) {
…
}
}
}
• Violates SRP and Open-Close
• Does not fit any design patterns
• Requires many tests to cover all
scenarios

Open-Closed Principal
• Classes should be open for
extension, but closed for
modification.
• If you add functionality, you
should be able to add code,
not change existing code.

The better solution
interface StatusOption
{
string[] getValidMoves(storyCard);
}
• Satisfies SRP and
Open-Close (mostly).
• Starting to look like a
pattern…
• Can test conditions
granularly, instead of
in combinations.
class InProgressStatusOption: StatusOption
{
string[] getValidMoves(storyCard) {
if (storyCard.isDone()) {
return [“QA”];
}
return [“Backlog”, “InProgress”];
}
}

How do we process the options?
class StatusOptionsProcessor
{
var opt = getOption(storyCard);
return opt.getValidMoves(storyCard);
}
StatusOption getOption(storyCard) {
…
}
}
• Still violates Open-Close
• Almost follows a design pattern
• Tests still reveal some overlap…

The Rule Engine
interface StatusRule
{
bool canHandle(storyCard)
string[] getValidMoves(storyCard);
}
class StatusRuleProcessor
{
StatusOption[] options;
string[] statuses = [];
foreach (option in options) {
if (option.canHandle(storyCard)
statuses.add(option.getValidMoves);
}
return statuses;
}
}
We could make…
• MovesForInProgressRule
• MovesForQARule
• AllowMoveToDoneRule
• FailQARule

Story time…
• Benefits are immediate.
• The value should not be underestimated.
• Good code is worth doing, even in an emergency.

Summary
• SOLID Principals, Design Patterns, and Unit Testing form a system
of feedback loops to help you write good code.
• You can use these feedback loops to improve your code
incrementally.
• This allows you to reduce tech debt over time.

Josh Rizzo
Principal Consultant at Improving
Josh.Rizzo@Improving.com
Presentation link: tx.ag/YAlGNqm

Iterative architecture

More Related Content

What's hot (20)

Similar to Iterative architecture (20)

Recently uploaded (20)

Iterative architecture

Editor's Notes