Each programming paradigm has its own set of constructs and their use will shape the system you create.

The main OO concepts:

1. Abstraction – simplify a concept by ignoring unimportant details.
2. Encapsulation – allows to bundle data and functions into a self-contained object, so the other objects can interact with it through an exposed interface.
3. Decomposition – allows you to break up a whole problem into smaller, distinct parts.
4. Generalization – allows you to factor out conceptual commonalities.

Object-oriented refers to a system composed of objects. where each object is an instance of a class (the type of each object is its class). Objects may interact with each other through the use of their methods. The OO paradigm allows for inheritance among abstract data types (one abstract type can be declared an extension of another type).

UML component diagrams are concerned with the components of a system. Components are defined as independent, encapsulated units of the system. Each component provides an interface for other components to interact with it.

The Component Diagram are used to visualize how a system’s pieces interact and and what relationships they have among them. This is high-level diagram, and shouldn’t considered to have details.

Continue reading “UML Component Diagram” →

It’s a difficult to capture the complete behavior of a system with a single perspective. Hence we have to observe it from 4 views.

1 – Logical View

Focuses on the functionality of a system and the objects found within it. The context is the services that should be provided to the end users. From the found objects you can create a UML class diagram that illustrates the logical view.

The class diagram has several purposes such as establishing the vocabulary of the problem and resulting system by defining all of the classes, their attributes and behaviors. It becomes easy to understand the key abstraction and terminology. The Logical View is also useful when specifying database schemes.

2 – Process View

It presents the processes implemented by the objects in the logical view. Focusing on non functional requirements which specify the desired qualities for the system. It includes quality attributes such as Performance and Availability.

Also helps to show the execution order of your different objects. It would show the calls to methods by the logical view in the correct order. Behaviors that asynchronous or concurrent are also described.

A UML sequence diagram would be helpful for illustrating the methods.

A UML activity diagram can illustrate the processes or activities for a system.

Continue reading ““4+1” Model View” →

The principle states that classes should achieve code reuse through aggregation rather than inheritance. For example the Composite design pattern and the Decorator design pattern use this approach.

The idea here that concrete classes can delegate tasks for other concrete classes. Delegation will provide loser level coupling then inheritance. Hence, provide your system more flexibility.

Disadvantages of Composition:

The biggest drawback of composition is that you must provide implementations for all behavior without the benefit of inheritance to share code. This means that you might have very similar implementations across the classes.

To manage complexity, one idea is that a class should be designed so that it does not need to know about and depend upon almost every other class in the system. By limiting which classes communicate with each other, you can enforce the principle of Least Knowledge. This principle is also realized in a rule known as The Law of Demeter.

The underlying idea of this Law is that classes should know about and interact with as few other classes as possible. This means that any class should only communicate with its “immediate friends”. These “friends” would be other classes that one class should only know about. It helps to reduce coupling and provide stability to a system.

• A method, M, is an object, O, can call on any other method within O itself (encapsulated within the same object).
• A method M, can call the methods of any parameter P (encapsulated within an object that is in the parameters of M).
• A method M, can call a method, N, of an object, I, if I is instantiated within M (encapsulated within an object that is instantiated inside of M).
• Any method, M, in object O, can invoke methods of any type of object that is a direct component of O (encapsulated within an object that is referenced in an instance variable of the class for M).

To summarize the rules, a method should not invoke methods of any object that is not local.

Classes should know as little as possible about your system as a whole, this will help to reduce amount of coupling and prevent unwanted effects from cascading through your entire system.

The Interface Segregation principle states that a class should not be forced to depend on methods it does not use. This means that any classes that implement an interface, should not have “dummy” implementations of any methods defined in the interface. Instead, you should split large interfaces into smaller generalizations.

The example before applying the Interface Segregation principle:

The best way is to apply Interface Segregation principle applying splitting the ICashier interface into 2 smaller. This will allow each interface to be more accurate with its description of expected behaviors, and it will allow you to pick and choose which correct combinations of interfaces a concrete class should implement.

Continue reading “SOLID (I) – Interface Segregation Principle” →