Keep It Short and Simple: is a design principle that indicate simplicity and avoiding unnecessary complexity problem in development. Design system, code, solutions needs to be as simple as possible, simple system and code are easier to read and test. Divide larger problems into smaller. Solve only the problems we need, use clear and descriptive variable, functions, class names. Follow design pattern and coding standards already proven to work. eg: Without KISS- if we need to validate or enforce rules for the radius, like ensuring it is positive , then properties and constructer make code more robust. With KISS- if class only exists to perform a single calculation, there is no need to instantiate it. (see below image)
Unified Modeling Language: is a standardized visual modeling language used to design,visualize and document the software system. Provide set of diagrams and symbols to represent system's design, functionality, making it easier for architects, developers to communicate and understand the system. It does not indicate how to develop software, only provide a way to represent design visually. UML divided into 2 main categories.
Product class: id, name,
GetDetails()
Customer class: id, name,
email, Register()
Order class: id, date,
total, PlaceOrder()
To start with diagrams, firstly we define name of the class at the top of
section (Employee), we
define attributes attributes (properties, fields, or variables) in the
second section (name:string), we
define methods (functions) in the third section to specify any behavioral
features of class
(setName(params):returnType). To indicate the accessibility of attribute/method we use
+ for public, - for private, and # for protected.
There are also specific notations for relationships between components:
Association : In this type, there is no base and child class.
Bidirectional Association the both classes know about each other, can access and interact
with each other.
Unidirectional Association the one class knows about the other and uses it, but the reverse
is not true.
Ex: Student uses Class.
Aggregation: In this type, class can depend on another class, but can exist
without that class. If the class is destroyed, the class can be used. Ex: A student
can exist without a teacher
Composition: In this type, class has another class, the dependent class
cannot exist without this class. Ex: Department cannot exist without School.
Multiplicity : It shows the numerical relationship between two. Ex: One
teacher can teach many students. Can be excatly one (1), zero or one (0..1), zero or many
(0..*), one or many (1..*)
classes
Design patterns are essential for writing clean and scalable code, it is a
solution for common design problems, help to improve the structure. Are used to solve
problems of Object Generation and Integration. We should use design pattern only when it
appropriate, but if it is not required then it can lead to messy codebases. Gang of Four -
is a group of authors who defined core object-oriented design patterns in a
famous book. It introduce 23 classic design patterns groupped three categories: Creational ,
Structural, Behavioral based on problems mostly happened
in architecture.
Creation design pattern : are focused on handling object creation. In real time
application,
project created with many classes and if logic is not centralized then it leads to tightly
coupled, messy code, means we need to deal many classes. Creational pattern solve this
problem by creating, initializing and returning appropriate object to client. What does:
- automatically decide that the class of object needs to be created based on the
configuration
- ensuring that instance are created only when necessary
A factory is an object used to create other objects, a class with
method, that method creates and return different objects based on received input parameter.
Simply, we have a superclass and N number of subclasses then suppose we create and return an
object of one of these subclasses, for this we should use the Factory pattern. eg;
- Without Factory pattern we have problems: tightly coupling between client and
classes.
Making changes in one class will affect others, we also need to modify client code. Adding
extra logic condition will add overheads the development and testing process. Violates
OCP.
- With Factory pattern: client code is not directly dependent on subclass, follow
OCP,
cleaner and more modular.
Factory Method Design Pattern is not just variant of Factory Design Pattern, it's a separate pattern defined in GoF, it defines an Abstract method (usually in an Interface) for creating an object and lets subclasses override this method to specify which concrete class to instantiate.
When object creation logic is simple we use Factory Design Pattern , suitable for small system. And when object creation logic needs to change we use Factory Method Design Pattern, suitable for large system.
