Архітектура Програмного Забезпечення

Архітектура визначає:

• Основні компоненти програми.

• Обов’язки кожного компонента.

Приклад архітектури:

Дизайн Класів

Принципи дизайну класів• Хороші класи – класи, спроектовані за

принципами SOLID:

• Single Responsibility Principle• Open Closed Principle• Liskov Substitution Principle• Interface Segregation Principle• Dependency inversion principle

Single Responsibility Principle (SRP)Принцип Єдиного Обов’язку

Клас має бути створений для виконання лише однієї задачі.

public class Employee{

private String name;

public String GetName() { return name; }

public void PrintReport() //це не має входити в обовязки {

//робітника}

}

Недоліки коду, показаного вище:1. Складність розуміння.2. Складність повторного використання.3. Складність підтримки коду.4. Ненадійність, велика ймовірність зміни класу,

при потребі зміни будь – яких аспектів системи

кому таке треба?

Зв’язність (Cohesion)Зв’язність – міра взаємоповязаності всередині модуля (класу).

Клас з високою зв’язністю має чітко звязані між собою обовязки, він призначений для виконання однієї задачі.

public class Employee { private String name;

public String GetName() { return name; } }

//клас Reporter друкує звіт про певного робітника. //кожен клас має свою зону відповідальності public class Reporter { public void PrintReport(Employee worker) { } }

Переваги SRP

+ Запобігає дублюванню коду.

+ Мінімізує кількість коду, який потрібно змінити в разі змін потреб до програмного продукту.

+ Полегшує розуміння коду.

Open Closed Principle (OSP)Принцип Відкритості/Закритості

Клас має бути відкритий для розширення, але закритий для змін.

Це означає, що нова поведінка в програмі повинна додаватись шляхом додавання нових сутностей, а не зміни старих.

public enum MessageType { SMS, EMAIL };

 

public class Message{

private MessageType type;

  public MessageType GetMessageType() {

return type;}

}

  public class MessageSender{ 

private void sendSMS(Message msg){//... send message as SMS}

  private void sendEmail(Message msg){//... Send message as Email}

 

public void Send(Message msg){

if (msg.GetType() == MessageType.SMS)

sendSMS(msg);

else if (msg.GetType() == MessageType.EMAIL)

sendEmail(msg); }

  }

//!!! зверніть увагу на метод "Send" - тут визначення того, який метод викликати, //відбувається в залежності від значеня поля msg

Зв’язаність (Coupling)

Зв’язаність (залежність) – це характеристика класу, яка визначає ступінь взаємодії модуля (класу) з іншими модулями

public class SMSMessage : IMessage { public void Send() { //...send SMS Message } } public class EmailMessage : IMessage { public void Send() { //...send Email Message } }

public class MessageSender{ private void SendMessage(IMessage msg) { msg.Send(); } }

//обидва класи (SMSMessage і EmailMessage) реалізують інтерфейс IMessage,//і тепер самі підкласи вирішують, який саме меод буде викликаний

Liskov Substitution Principle (LSP)Принцип підстановки Лісков

Об’єкти в ієрархії класів можуть бути замінені на їх підтипи без порушення

цілісності системи.

Interface segregation principle (ISP)Принцип розділення інтерфейсу

Клієнти не повинні залежати від методів, які вони не використовують.

Даний принцип означає, що занадто великі інтерфейси необхідно розділяти на менші та специфічні, щоб їх клієнти знали лише про ті методи, що необхідні для них у роботі

public interface IAnimal { void Eat(); void Fly(); void Bark(); }

public class Dog : IAnimal{ public void Eat() { //some realization }

public void Fly() {

throw new NotImplementedException(); }

public void Bark() { //some realization }}

public class Bird : IAnimal{ public void Eat() { //some realization }

public void Fly() { //some realization }

public void Bark() { throw new NotImplementedException(); }}

public interface

IAnimal { void Eat(); }

public interfaceIFlyable

{ void Fly(); }

public interfaceIBarkable

{ void Bark(); }

public class Bird : IAnimal, IFlyable{ public void Eat() { // some realization }

public void Fly() { // some realization }}

public class Dog : IAnimal, IBarkable{ public void Eat() { // some realization }

public void Bark() { // some realization }}

Dependency Inversion Principle (DIP)Принцип інверсії залежностей

• Модулі верхнього рівня не повинні залежати від модулів нижнього рівня. Обидва повинні залежати від абстракції.

• Абстракції не повинні залежати від деталей реалізацій. Деталі повинні залежати від абстракцій.

Шаблони Проектування

ЧИ БУЛА ЦЯ ЗАДАЧА ВИРІШЕНА ДО МЕНЕ?

Патерни проектування - це готові прийоми вирішення задач проектування програмного забезпечення, які перевірені часом та практикою.

Інколи ми використовуємо патерни, навіть не задумуючись про це.

Література:

1. “Дизайн-патерни – просто як двері“ Андрій Будай2. “Head First Design Patterns” Freeman E.T., Freeman E. (є російський переклад)3. “Design Patterns: Elements of Reusable Object-Oriented Software” Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides. (є російський переклад)

Практика, практика і знову практика...

Сінглтон (одинак)

Одинак — шаблон проектування, який

- гарантує, що клас матиме тільки один екземпляр.

- забезпечує глобальну точку доступу до цього екземпляра.

public class Singleton {

//статичний закритий обєкт private static Singleton instance;

  //конструктор закритий! private Singleton() { } //відкладена ініціалізація public static Singleton getInstance() { if (instance == null) instance = new Singleton();  return instance; } }

Адаптер

Адаптує інтерфейс одного класу в інший, очікуваний клієнтом.

Адаптер забезпечує роботу класів з несумісними інтерфейсами

Адаптер public class Fish { public void swim() { /*some realization*/ } }

public class Hatchet { public void sink() { /*some realization*/ } }

public class HatchetToFishAdapter : Fish { private Hatchet hatchet;  public void swim() { hatchet.sink(); } }

Дякую за увагу!