Principles of Object‑Oriented Architecture and Common Design Patterns

The source emphasizes flexible application of OO principles rather than rigid adherence, advocating minimal code duplication, low coupling, and high cohesion across modules ranging from a single class to an entire system.

Coupling factors include inter‑module calls, data volume transferred, control flow, and interface complexity. The article lists coupling strengths from weakest to strongest: non‑direct, data, stamp, control, external, common, and content coupling.

Ways to reduce coupling involve preferring interfaces over inheritance, keeping module responsibilities single‑purpose, avoiding duplicate code, minimizing global variables, using private members, avoiding hard‑coded strings, and applying design patterns to keep coupling at data level or weaker.

Composition over inheritance is recommended when a Has‑A relationship is more appropriate than an Is‑A relationship, when subclassing merely extends functionality, when utility classes are needed, or when future replacement of a subclass is possible.

Inheritance considerations include implementing abstract methods, extending new features while minimizing overrides of non‑abstract parent methods, and ensuring pre‑conditions are weaker and post‑conditions stricter than the parent.

Class relationships and UML are illustrated with diagrams (not reproduced here) to show typical associations.

Common architectural patterns covered are MVC and its subset MVP, where MVC separates Controller, View, and Model, while MVP lets the Presenter mediate between View and Model.

MVVM (View ↔ ViewModel ↔ Model) is described, with ViewModel handling data display and user interaction; MVVM‑C adds a Callback layer (Fragment/Activity) for user actions.

Design patterns are listed with brief explanations:

Factory Method – creates objects without specifying exact classes.

Singleton – uses the Initialization‑on‑demand holder idiom; thread‑safe via JVM class loader.

Builder – focuses on constructing complex objects step by step, unlike factories that create single types.

Prototype – provides cloning; shallow copy via Object#clone() (requires Cloneable ), deep copy via serialization or manual cloning.

Adapter – converts one interface to another.

Decorator – adds responsibilities dynamically.

Proxy – controls access to another object.

Facade – offers a simplified interface to a subsystem.

Bridge – separates abstraction from implementation.

Composite – composes objects into tree structures.

Flyweight – shares common parts to reduce memory usage.

Strategy – defines interchangeable algorithms.

Template Method – defines skeleton of an algorithm, deferring steps to subclasses.

Observer – establishes a one‑to‑many dependency for change notification.

The article concludes with a note that the content is sourced from the web, with copyright belonging to the original authors.