UML is a graphical notation specifically for drawing diagrams of an object-oriented system. A UML describes over a dozen different diagrams, but we’re only interested in a few of the most common, such as the classic class diagram.

ConcepObjectModel

ConcepObjectModel

Class Diagram

Class Diagram

When drawing diagrams, it’s common to see signs before the attributes or methods, most

– Minus signs in front of the attributes here. This is referred to as controlling visibility, and Minus means these should be private to the class, not directly accessible from other objects.

+ For example getName operation which will be public and marked with a Plus sign.

 

 

Identifying inheritance

 

Inheritates Abstract Class

Inheritates AbstractClass

easiest way of identifying an inheritance situation is with two words, “Is A”. Inheritance describes an “Is A” relationship.

 

Using aggregation and composition

Aggregation Composition

Aggregation Composition

it’s the unfilled diamond. So, for example, we might have a classroom object that will contain an array of student objects that might be important to diagram that relationship.

Document has a Page or has many pages. But if I were to delete the Document object all the associated Page objects should be deleted too. I would not expect then those page objects to be shared with any other part of the application. On the other hand in a plain aggregation situation as with the Classroom and Student relationship, if I deleted the Classroom object, perhaps the class got canceled, I would not expect all the Student objects to be destroyed, they may be used in different classrooms or just be able to live on their own.

And that’s the difference, Composition implies ownership, Aggregation does not. Now Aggregation is not usually worth showing on a diagram, but Composition often can be. If the lifetime of an object is dependent on another object existing that can be worth showing, even if we are just prompting the idea that when you’re defining the owning class, say here the Document class, you may need to write aconstructor and a destructor that would take care of creating and/or deleting the internal objects.

 

Using interfaces

Interfaces

Interfaces

Sequence Diagrams

Sequence Diagrams

Class Diagram

Class Diagram

Dependency:

Khi một class có sử dụng một instance của class B như một tham số đầu vào của method trong class A.
Ex:

public class A {

    public void doSomething(B b) {}

Nhưng giả sử class A có một member với kiểu dữ liệu là class B thì lúc đó ta có mối quan hệ

Aggregation:

Ex:

public class A {

    private B _b;

    public void setB(B b) { _b = b; }

Với ví dụ trên ta có thể thấy mối quan hệ giữa A và B chỉ là Aggreation có nghĩa là nếu như A bị hủy thì chưa chắc B đã được hủy. Do vậy nếu như instance của B được khởi tạo trong A như ví dụ dưới đây ta có mối quan hệ là

Composition:

Ex:

public class A {

    private B _b = new B();

Hoặc

public class A {

    private B _b;

    public A() {
        _b = new B();
    } // default constructor

Còn mối quan hệ như Inheritance hay Realization thì sao? Đúng như tên gọi của nó, nếu class B kế thừa từ class A ta có mối quan hệ

Inheritance:

Ex:

public class A {

    ...

} // class A

public class B extends A {

    ....

} // class B

Mặt khác nếu class B implement từ A thì ta có mối quan hệ (Ví dụ ta hay thấy đó là implement một interface)

Realization:

Ex:

public interface A {

    ...

} // interface A

public class B implements A {

    ...

} // class B

Introduction

In this article, we are going to explore the classic specification pattern and implement it in order to compose the LINQ queries, and also non-LINQ queries. This article will also help beginners in understanding the specification pattern and how to implement it in practice. Major benefits of the specification patterns include reusability, maintainability, loose coupling of business rules from the business objects, readability and easy testing.

Specification Pattern

Specification pattern as per the definition from Wikipedia, is a particular software design pattern, wherebybusiness rules can be recombined by chaining the business rules together using boolean logic. To put it simply, business rules are segregated based on the Single responsibility principle (SRP) and chained or composed using boolean operands (AND, OR or NOT) to achieve the desired result. Each segregated business rule is called Specification.

Each specification inherits the abstract CompositeSpecification class which defines one abstractmethod called IsSatisfiedBy. This method is the engine of specification pattern. The responsibility of this method is to apply the business rule (specification) on the object in question and return a boolean result. The primary goal of the specification pattern is to select the subset of objects that satisfy a set of specifications chained together.

 

More infor:

codeproject

ABAP 

A table is where data is stored. You always start with tables first, and then your usage pattern dictates whether you need views or materialized views.

A view is like a stored query for future use, if you’re frequently joining or filtering the same tables the same way in multiple places.

A materialized view is like a combination of both: it’s a table that is automatically populated and refreshed via a view. You’d use this if you were using views, and want to pre-join or pre-aggregate the rows to speed up queries.

materialized view

Figure below shows an example of using the Materialized View pattern. Data in the Order, OrderItem, and Customer tables in separate partitions in a Microsoft Azure storage account are combined to generate a view containing the total sales value for each product in the Electronics category, together with a count of the number of customers who made purchases of each item.

materialized view2

Materialised View:Materialized views are schema objects that can be used to summarize, precompute, replicate, and distribute data.It  provides indirect access to table data by storing the results of a query in a separate schema object. Unlike an ordinary view, which does not take up any storage space or contain any data.

Senario:While creating a dataware house we need to go for staging part at that time this is useful.

VIEWS:

We have 2 types

1)Read only

2)Updatable

An updatable view lets you insert, update, and delete rows in the view and propagate the changes to the target master table.

 

In order to be updatable, a view cannot contain any of the following constructs:

SET or DISTINCT operators, an aggregate or analytic function, a GROUP BY, ORDER BY, CONNECT BY, or START WITH clause, a subquery (or collection expression) in a SELECT list

or finally (with some exceptions) a JOIN

 

Views that are not updatable can be modified using an INSTEAD OF trigger.

Reference:

https://msdn.microsoft.com/en-us/library/dn589782.aspx

https://blogs.saphana.com/2014/10/27/how-simple-finance-removes-redundancy-the-case-of-materialized-views/

 

 

 

visitor-pattern

Visitor Design Pattern

Intent

  • Represent an operation to be performed on the elements of an object structure. Visitor lets you define a new operation without changing the classes of the elements on which it operates.
  • The classic technique for recovering lost type information.
  • Do the right thing based on the type of two objects.
  • Double dispatch

Problem

Many distinct and unrelated operations need to be performed on node objects in a heterogeneous aggregate structure. You want to avoid “polluting” the node classes with these operations. And, you don’t want to have to query the type of each node and cast the pointer to the correct type before performing the desired operation.

Discussion

Visitor’s primary purpose is to abstract functionality that can be applied to an aggregate hierarchy of “element” objects. The approach encourages designing lightweight Element classes – because processing functionality is removed from their list of responsibilities. New functionality can easily be added to the original inheritance hierarchy by creating a new Visitor subclass.

Visitor implements “double dispatch”. OO messages routinely manifest “single dispatch” – the operation that is executed depends on: the name of the request, and the type of the receiver. In “double dispatch”, the operation executed depends on: the name of the request, and the type of TWO receivers (the type of the Visitor and the type of the element it visits).

The implementation proceeds as follows. Create a Visitor class hierarchy that defines a pure virtualvisit() method in the abstract base class for each concrete derived class in the aggregate node hierarchy. Each visit() method accepts a single argument – a pointer or reference to an original Element derived class.

Each operation to be supported is modelled with a concrete derived class of the Visitor hierarchy. Thevisit() methods declared in the Visitor base class are now defined in each derived subclass by allocating the “type query and cast” code in the original implementation to the appropriate overloadedvisit() method.

Add a single pure virtual accept() method to the base class of the Element hierarchy. accept() is defined to receive a single argument – a pointer or reference to the abstract base class of the Visitor hierarchy.

Each concrete derived class of the Element hierarchy implements the accept() method by simply calling the visit() method on the concrete derived instance of the Visitor hierarchy that it was passed, passing its “this” pointer as the sole argument.

Everything for “elements” and “visitors” is now set-up. When the client needs an operation to be performed, (s)he creates an instance of the Vistor object, calls the accept() method on each Element object, and passes the Visitor object.

The accept() method causes flow of control to find the correct Element subclass. Then when thevisit() method is invoked, flow of control is vectored to the correct Visitor subclass. accept()dispatch plus visit() dispatch equals double dispatch.

The Visitor pattern makes adding new operations (or utilities) easy – simply add a new Visitor derived class. But, if the subclasses in the aggregate node hierarchy are not stable, keeping the Visitor subclasses in sync requires a prohibitive amount of effort.

An acknowledged objection to the Visitor pattern is that is represents a regression to functional decomposition – separate the algorithms from the data structures. While this is a legitimate interpretation, perhaps a better perspective/rationale is the goal of promoting non-traditional behavior to full object status.

Structure

The Element hierarchy is instrumented with a “universal method adapter”. The implementation ofaccept() in each Element derived class is always the same. But – it cannot be moved to the Element base class and inherited by all derived classes because a reference to this in the Element class always maps to the base type Element.

Visitor scheme

When the polymorphic firstDispatch() method is called on an abstract First object, the concrete type of that object is “recovered”. When the polymorphic secondDispatch() method is called on an abstract Second object, its concrete type is “recovered”. The application functionality appropriate for this pair of types can now be exercised.

Visitor scheme

Example

The Visitor pattern represents an operation to be performed on the elements of an object structure without changing the classes on which it operates. This pattern can be observed in the operation of a taxi company. When a person calls a taxi company (accepting a visitor), the company dispatches a cab to the customer. Upon entering the taxi the customer, or Visitor, is no longer in control of his or her own transportation, the taxi (driver) is.

Visitor example

Check list

  1. Confirm that the current hierarchy (known as the Element hierarchy) will be fairly stable and that the public interface of these classes is sufficient for the access the Visitor classes will require. If these conditions are not met, then the Visitor pattern is not a good match.
  2. Create a Visitor base class with a visit(ElementXxx) method for each Element derived type.
  3. Add an accept(Visitor) method to the Element hierarchy. The implementation in each Element derived class is always the same – accept( Visitor v ) { v.visit( this ); }. Because of cyclic dependencies, the declaration of the Element and Visitor classes will need to be interleaved.
  4. The Element hierarchy is coupled only to the Visitor base class, but the Visitor hierarchy is coupled to each Element derived class. If the stability of the Element hierarchy is low, and the stability of the Visitor hierarchy is high; consider swapping the ‘roles’ of the two hierarchies.
  5. Create a Visitor derived class for each “operation” to be performed on Element objects. visit()implementations will rely on the Element’s public interface.
  6. The client creates Visitor objects and passes each to Element objects by calling accept().

Rules of thumb

  • The abstract syntax tree of Interpreter is a Composite (therefore Iterator and Visitor are also applicable).
  • Iterator can traverse a Composite. Visitor can apply an operation over a Composite.
  • The Visitor pattern is like a more powerful Command pattern because the visitor may initiate whatever is appropriate for the kind of object it encounters.
  • The Visitor pattern is the classic technique for recovering lost type information without resorting to dynamic casts.

Notes

The November 2000 issue of JavaPro has an article by James Cooper (author of a Java companion to the GoF) on the Visitor design pattern. He suggests it “turns the tables on our object-oriented model and creates an external class to act on data in other classes … while this may seem unclean … there are good reasons for doing it.”

His primary example. Suppose you have a hierarchy of Employee-Engineer-Boss. They all enjoy a normal vacation day accrual policy, but, Bosses also participate in a “bonus” vacation day program. As a result, the interface of class Boss is different than that of class Engineer. We cannot polymorphically traverse a Composite-like organization and compute a total of the organization’s remaining vacation days. “The Visitor becomes more useful when there are several classes with different interfaces and we want to encapsulate how we get data from these classes.”

His benefits for Visitor include:

  • Add functions to class libraries for which you either do not have the source or cannot change the source
  • Obtain data from a disparate collection of unrelated classes and use it to present the results of a global calculation to the user program
  • Gather related operations into a single class rather than force you to change or derive classes to add these operations
  • Collaborate with the Composite pattern

Visitor is not good for the situation where “visited” classes are not stable. Every time a new Composite hierarchy derived class is added, every Visitor derived class must be amended.