What are the four principles of software engineering?

The four core principles of software engineering are modularity, abstraction, encapsulation, and separation of concerns. Every other list of software engineering principles, from SOLID to the design concepts in Pressman's textbook, is a longer or more specific version of these four. They all answer one question: how do we build a large program that people can still change safely after it ships?

There is no single official list. The IEEE defines software engineering as the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software. That definition describes a discipline, not a set of rules, so textbooks and companies each name the rules they find most useful. The four below appear in nearly all of them.

1. Modularity

Modularity means building a system from separate parts, called modules, where each module does one job. A module can be a function, a class, a package, or a whole service. The test of good modularity is that you can understand, test, and replace one module without reading the others.

In a web application, one module handles sign-in, another handles payments, and a third renders pages. A developer fixing a payment bug opens the payment module and nothing else. Modularity is also what allows several developers to work on the same product at the same time without editing the same files.

Two measures describe module quality. Cohesion is how closely the contents of one module belong together; high cohesion is good. Coupling is how much one module depends on the internals of another; low coupling is good. Pressman calls the combination of high cohesion and low coupling functional independence.

2. Abstraction

Abstraction means showing only the details that matter at the current level and hiding the rest. A caller sees a name and a contract, such as save(order), and does not see the SQL statements, connection pools, or retries behind it.

A database access module is the standard example. It offers save, update, and delete, and the rest of the program never writes a query. If the team later moves from one database to another, only that module changes.

Abstraction is also how we manage size. Nobody can understand a million lines of code at once, so we work at one layer at a time and trust the contract of the layers below.

3. Encapsulation

Encapsulation means keeping data and the code that changes it together, and blocking direct access to the data from outside. In object-oriented languages this is done with private fields and public methods.

A User class keeps password and email private and exposes updatePassword() and getEmail(). No other part of the program can set the password to an empty string, because the only way in is a method that checks the input. As long as the public methods keep the same signature, the internals can change without breaking callers.

Abstraction and encapsulation are often confused. Abstraction is about what the outside sees; encapsulation is about what the outside is prevented from touching.

4. Separation of concerns

Separation of concerns means each part of the system deals with one concern, such as storage, business rules, or presentation, and not the others. It is modularity applied along the lines of responsibility rather than along the lines of size.

The Model-View-Controller pattern is the common example. The model holds data and business rules, the view draws the screen, and the controller turns user input into calls on the model. A designer can change the view without touching the rules, and a rule change never edits a template.

A closely related idea is locality of change: a single change in requirements should require edits in a single, small place in the code. When one requirement change touches twelve files, the concerns are mixed.

The four principles in one table

How the four relate to SOLID and other lists

SOLID is a set of five object-oriented design principles. The open-closed principle, stated by Bertrand Meyer, says that software entities should be open for extension but closed for modification: you add behavior by adding new code, not by editing tested code. The single responsibility principle is separation of concerns applied to one class. Dependency inversion is abstraction applied to how modules connect. Every SOLID rule is a specific form of one of the four principles above.

Pressman's design concepts are a longer textbook list: abstraction, architecture, patterns, separation of concerns, modularity, information hiding, functional independence, refinement, aspects, and refactoring. Information hiding is Pressman's name for encapsulation. Functional independence is the cohesion-and-coupling measure described under modularity.

Other lists name principles such as DRY (do not repeat yourself), KISS (keep it simple), and YAGNI (you are not going to need it). Those are working habits for individual developers rather than structural principles, and they apply in addition to the four.