Simply put, software engineering turns human needs into dependable software while dealing with real-world limits. These limits include time, money, available people, and incomplete information. Software engineering includes programming, but it also covers deciding what to build, checking that it works, and keeping it useful as needs change. To understand the field, it helps to know how it began, how AI is changing it, and where it may go next.

Then: born of a crisis

The term software engineering became well known during the software crisis of the late 1960s. Many early programs were written by one person and were small enough for that person to understand fully. This approach stopped working as software became larger and more important. Projects were late, cost too much, failed after release, or were never finished. These problems became known as the software crisis. In 1968, a NATO conference used the title software engineering to express a hope: building software could become as systematic as other engineering fields. Computers have changed greatly since 1968, but software projects still face late schedules, rising costs, and systems that break easily.

The joys of software engineering still attract people to the field. The Mythical Man-Month by Frederick P. Brooks describes several of them. Engineers can enjoy building things that help other people, solving problems that feel like puzzles, and turning ideas into working software without needing a factory or raw materials. They also keep learning because the field is always changing.

The woes of software engineering also remain. Brooks listed several. Programs must be precise because computers follow instructions, not intentions. Reviews, tests, and fault-tolerant designs help us find or handle the mistakes that will occur. Engineers also depend on people, requirements, and code they do not control. Testing and debugging take careful work, and the last part of a project often costs the most. Products and the technologies used to build them can quickly become outdated. Even so, Brooks concluded that for many people, "the joys far outweigh the woes."

In 1986, Brooks made a famous prediction: no single breakthrough -- no silver bullet -- would transform software development within ten years. In No Silver Bullet, he divided the difficulty of building software into two types. Accidental complexity comes from imperfect tools. Essential complexity comes from the problem being solved. Brooks argued that essential complexity made up most of the remaining work. Therefore, no single new method or tool was likely to make software development ten times more productive, reliable, or simple. He considered several possible breakthroughs, including AI, but rejected them all. His prediction remained true for decades. Then large language models learned to write code. Could they be the silver bullet that Brooks thought was unlikely?

Now: the AI inflection

Software engineering covers the whole life of a system, not only writing its code. Engineers study user needs, design and build the system, test and review it, deploy and secure it, fix failures, and improve it over time. They repeat these activities as needed and work in teams rather than alone. Success is measured by the value delivered, not the amount of code written. Practices such as agile processes, DevOps, and continuous delivery help teams manage this work. The SWEBOK guide gives an overview of the field.

AI now helps with nearly all of these activities. Within a few years, AI coding tools became a normal part of many developers' work. These tools can do much more than complete lines of code. They can explore an unfamiliar codebase, generate and change code, suggest tests, diagnose failures, review changes, and draft documentation. In agentic mode, an AI tool can receive a goal written in natural language, edit several files, run tests, and prepare the changes for a human to review. Accepting generated code without checking it carefully is often called vibe coding.

However, generating code faster does not automatically produce better software. In surveys, developers' most common frustration is AI output that is almost right, but not quite. Finding a small mistake in code that looks correct can require more skill than writing the code. One randomized study found that experienced developers worked more slowly with AI even though they believed they had worked faster. A later study of newer agentic tools found some improvement in speed, but the study could not show clearly how large the improvement was. In short, the benefit depends on the task, codebase, tool, and user's skill. Our impressions alone do not measure that benefit well.

The clearest finding so far is that AI amplifies both the strengths and weaknesses of the engineering process around it. Research involving thousands of professionals supports this view. A team with clear goals, good tests, effective reviews, and fast feedback can turn faster code generation into useful results sooner. A team without these practices may simply create defects sooner. In Brooks' terms, AI may be our strongest tool yet for reducing accidental complexity. It also helps with essential work, such as exploring requirements and drafting designs. However, humans still decide what to build and whether it has been built well. Therefore, AI makes software engineering fundamentals more important, not less.

Engineers are also building more software that uses AI as part of the system. Such systems bring their own concerns, including data quality, unpredictable output, evaluation, privacy, algorithmic bias, and monitoring.

Next: the evolving engineer

Developers are giving AI larger pieces of work: first lines of code, then whole tasks, and perhaps soon larger parts of a project. In controlled tests, AI agents can complete increasingly long tasks. However, real projects that last many years are more complicated than such tests. Giving instructions through natural language, examples, and tests may become as important as writing code by hand.

One possible next step is AI-native software engineering: designing the workflow for ongoing collaboration between humans and AI. This approach goes further than adding an AI assistant to today's process. In AI-assisted software engineering, AI works inside a process directed by humans. In agentic software engineering, humans give AI tasks with several steps. In AI-native engineering, teams redesign the process itself. In this possible future, sometimes called SE 3.0, engineers record goals, constraints, designs, and acceptance criteria in forms that AI agents can use. Agents plan changes, write code, run tests, and review one another's work. Humans set the direction, make difficult choices, and decide what is safe to release. Requirements, tests, architecture records, and security controls will then matter more, not less. They set the limits within which the agents work.

Experts disagree about how far this change will go, so evaluate their predictions carefully. Some predict the end of programming, with most software requested in natural language and generated when needed. Others point out that benchmarks leave out much of real software work, such as unclear goals, knowledge that has not been written down, and long-term maintenance. They also argue that a code change that passes its tests is not necessarily part of a dependable system. Checking whether AI evaluations reflect real software work is itself a software engineering problem.

As it becomes easier to give implementation work to AI, deciding, designing, checking, and taking responsibility become more valuable. Someone must understand the users and the subject area. Someone must decide what should and should not be built, divide the work into clear parts, design a system that can be maintained, spot mistakes in code that looks correct, combine human and AI work, and take responsibility for the released system. AI can help with every one of these activities, but it cannot take responsibility for the result.

Engineers must understand the work before they can direct, evaluate, or fix it. Therefore, software engineering foundations matter more than ever. The world still needs many software engineers, but the skills they use may change. They may spend less time writing code by hand and more time directing, evaluating, and taking responsibility for it.

Software engineering may now be going through its biggest change since 1968, but its future is still unclear. The rewards Brooks described remain. Some old difficulties may be becoming smaller, while new ones appear. We do not yet know whether AI will be the silver bullet that Brooks thought was unlikely, or simply a powerful tool that amplifies both the strengths and weaknesses of software teams.

Object-Oriented Programming (OOP) is a programming paradigm. A programming paradigm guides programmers to analyze programming problems, and structure programming solutions, in a specific way.

Programming languages have traditionally divided the world into two parts—data and operations on data. Data is static and immutable, except as the operations may change it. The procedures and functions that operate on data have no lasting state of their own; they’re useful only in their ability to affect data.

This division is, of course, grounded in the way computers work, so it’s not one that you can easily ignore or push aside. Like the equally pervasive distinctions between matter and energy and between nouns and verbs, it forms the background against which you work. At some point, all programmers—even object-oriented programmers—must lay out the data structures that their programs will use and define the functions that will act on the data.

With a procedural programming language like C, that’s about all there is to it. The language may offer various kinds of support for organizing data and functions, but it won’t divide the world any differently. Functions and data structures are the basic elements of design.

Object-oriented programming doesn’t so much dispute this view of the world as restructure it at a higher level. It groups operations and data into modular units called objects and lets you combine objects into structured networks to form a complete program. In an object-oriented programming language, objects and object interactions are the basic elements of design.

_{-- Object-Oriented Programming with Objective-C, Apple}

Some other examples of programming paradigms are:

Some programming languages support multiple paradigms.
Example Java is primarily an OOP language, but it supports limited forms of functional programming and can be used to write procedural code (although this is not recommended), e.g., se-edu/addressbook-level1.
Example JavaScript and Python support functional, procedural, and OOP programming.

An object in Object-Oriented Programming (OOP) has state and behavior, similar to objects in the real world.

Every object has both state (data) and behavior (operations on data). In that, they’re not much different from ordinary physical objects. It’s easy to see how a mechanical device, such as a pocket watch or a piano, embodies both state and behavior. But almost anything that’s designed to do a job does, too. Even simple things with no moving parts such as an ordinary bottle combine state (how full the bottle is, whether or not it’s open, how warm its contents are) with behavior (the ability to dispense its contents at various flow rates, to be opened or closed, to withstand high or low temperatures).

It’s this resemblance to real things that gives objects much of their power and appeal. They can not only model components of real systems, but equally as well fulfill assigned roles as components in software systems.

_{-- Object-Oriented Programming with Objective-C, Apple}

OOP views the world as a network of interacting objects.

OOP solutions try to create a similar object network inside the computer’s memory – a sort of virtual simulation of the corresponding real world scenario – so that a similar result can be achieved programmatically.

OOP does not demand that the virtual world object network follow the real world exactly.

Every object has both state (data) and behavior (operations on data).

Every object has an interface and an implementation.

Every real-world object has,

• an interface through which other objects can interact with it, and
• an implementation that supports the interface but may not be accessible to the other objects.

Similarly, every object in the virtual world has an interface and an implementation.

Objects interact by sending messages. Both real world and virtual world object interactions can be viewed as objects sending messages to each other. The message can result in the sender object receiving a response and/or the receiver object’s state being changed. Furthermore, the result can vary based on which object received the message, even if the message is identical (see rows 1 and 2 in the example below).

The concept of Objects in OOP is an abstraction mechanism because it allows us to abstract away lower-level details and work with larger units. That is, we can ignore details such as data formats and method implementations, and work at the level of objects.

Encapsulation protects an implementation from unintended actions and from inadvertent access.
_{-- Object-Oriented Programming with Objective-C, Apple}

An object is an encapsulation of some data and related behavior in terms of two aspects:

1. The packaging aspect: An object packages data and related behavior together into one self-contained unit.

2. The information hiding aspect: The data in an object is hidden from the outside world and is only accessible using the object's interface.

Writing an OOP program is essentially writing instructions that the computer will use to,

1. create the virtual world of the object network, and
2. provide it with the inputs to produce the outcome you want.

A class contains instructions for creating a specific kind of object. Sometimes, multiple objects keep the same type of data and have the same behavior because they are of the same kind. Instructions for creating a 'kind' (or ‘class’) of object can be written once, and those same instructions can be used to objects of that kind. We call such instructions a class.

While all objects of a class have the same attributes, each object has its own copy of the attribute value.
Example All Person objects have the name attribute but the value of that attribute varies between Person objects.

However, some attributes are not suitable to be maintained by individual objects. Instead, they should be maintained centrally, shared by all objects of the class. They are like ‘global variables’ but attached to a specific class. Such variables whose value is shared by all instances of a class are called class-level attributes.
Example The attribute totalPersons should be maintained centrally and shared by all Person objects rather than copied at each Person object.

Similarly, when a normal method is being called, a message is being sent to the receiving object and the result may depend on the receiving object.
Example Sending the getName() message to the Adam object results in the response "Adam" while sending the same message to the Beth object results in the response "Beth".

However, there can be methods related to a specific class but not suitable for sending messages to a specific object of that class. Such methods that are called using the class instead of a specific instance are called class-level methods.
Example The method getTotalPersons() is not suitable to send to a specific Person object because a specific object of the Person class should not have to know about the total number of Person objects.

Class-level attributes and methods are collectively called class-level members (also called static members sometimes because some programming languages use the keyword static to identify class-level members). They are to be accessed using the class name rather than an instance of the class.

An Enumeration is a fixed set of values that can be considered as a data type. An enumeration is often useful when using a regular data type such as int or String would allow invalid values to be assigned to a variable.

Objects in an OO solution need to be connected to each other to form a network so that they can interact with each other. Such connections between objects are called associations.
Example Suppose an OOP program for managing a learning management system creates an object structure to represent the related objects. In that object structure you can expect to have associations between a Course object that represents a specific course and Student objects that represent students taking that course.

Associations in an object structure can change over time.
Example To continue the previous example, the associations between a Course object and Student objects can change as students enroll in the course or drop the course over time.

Associations among objects can be generalized as associations between the corresponding classes too.
Example In our example, as some Course objects can have associations with some Student objects, you can view it as an association between the Course class and the Student class.

Implementing associations

You use instance-level variables to implement associations.
Example In our example, the Course class can have a students variable to keep track of students associated with a particular course.

When two classes are linked by an association, it does not necessarily mean both objects taking part in an instance of the association know about (i.e., have a reference to) each other. The concept of navigability tells us if an object taking part in an association knows about the other. In other words, it tells us if we can 'navigate' from the one object to the other in a given direction -- because if the object 'knows' about the other, it has a reference to the other object, and we can use that reference to 'navigate to' (i.e., access) that other object.

Navigability can be unidirectional or bidirectional. Suppose there is an association between the classes Box and Rope, and the Box object b and the Rope object r are taking part in one instance of that association.

• Unidirectional: If the navigability is from Box to Rope, b will have a reference to r but r will not have a reference to b. That is, one can navigate from b to r using b's reference to r (but not in the other direction).
  Similarly, if the navigability is in the other direction, r will have a reference to b but b will not have a reference to r.
• Bidirectional: b will have a reference to r and r will have a reference to b i.e., the two objects will be pointing to each other for the same single instance of the association.

Note that two in opposite directions do not add up to a single bidirectional association.

class Person {
    Cat pet;
    //...
}

class Cat {
    Person owner;
    //...
}

    

    Copy
    

    


    
    
    
    

    Wrap Text
    

    


    
    
    

class Person:

  def __init__(self):
    self.pet = None  # a Cat object

class Cat:

  def __init__(self):
    self.owner = None  # a Person object

    

    Copy
    

    


    
    
    
    

    Wrap Text
    

    


    
    
    

class Person {
    Cat pet;
    //...
}

class Cat{
    Person breeder;
    //...
}

    

    Copy
    

    


    
    
    
    

    Wrap Text
    

    


    
    
    

class Person:

  def __init__(self):
    self.pet = None  # a Cat object

class Cat:

  def __init__(self):
    self.breeder = None  # a Person object

    

    Copy
    

    


    
    
    
    

    Wrap Text
    

    


    
    
    

Multiplicity is the aspect of an OOP solution that dictates how many objects take part in each association.
Example The multiplicity of the association between Course objects and Student objects tells you how many Course objects can be associated with one Student object and vice versa.

Implementing multiplicity

A normal instance-level variable gives us a 0..1 multiplicity (also called optional associations) because a variable can hold a reference to a single object or null.

class Logic {
    Minefield minefield;
    // ...
}

class Minefield {
    //...
}

    

    Copy
    

    


    
    
    
    

    Wrap Text
    

    


    
    
    

class Logic:
  
  def __init__(self):
    self.minefield = None
    
  # ...


class Minefield:
  # ...

    

    Copy
    

    


    
    
    
    

    Wrap Text
    

    


    
    
    

A variable can be used to implement a 1 multiplicity too (also called compulsory associations).

class Logic {
    ConfigGenerator cg = new ConfigGenerator();
    ...
}

    

    Copy
    

    


    
    
    
    

    Wrap Text
    

    


    
    
    

To implement other multiplicities, choose a suitable data structure such as Arrays, ArrayLists, HashMaps, Sets, etc.

class Minefield {
    Cell[][] cell;
    //...
}

    

    Copy
    

    


    
    
    
    

    Wrap Text
    

    


    
    
    

class Minefield:

  def __init__(self):
    self.cells = {1:[], 2:[], 3:[]}

    

    Copy
    

    


    
    
    
    

    Wrap Text
    

    


    
    
    

In the context of OOP associations, a dependency is a need for one class to depend on another without having a direct association in the same direction. Reason for the exclusion: If there is an association from class Foo to class Bar (i.e., navigable from Foo to Bar), that means Foo is obviously dependent on Bar and hence there is no point in mentioning dependency specifically. In other words, we are specifically focusing on non-obvious dependencies here. One cause of such dependencies is interactions between objects that do not have a long-term link between them.
Example A Course class can have a dependency on a Registrar class because the Course class needs to refer to the Registrar class to obtain the maximum number of students it can support (e.g., Registrar.MAX_COURSE_CAPACITY).

class Foo {

    int calculate(Bar bar) {
        return bar.getValue();
    }
}

class Bar {
    int value;

    int getValue() {
        return value;
    }
}

    

    Copy
    

    


    
    
    
    

    Wrap Text
    

    


    
    
    

class Foo:

    def calculate(self, bar):
        return bar.value;

class Bar:

    def __init__(self, value):
      self.value = value

    

    Copy
    

    


    
    
    
    

    Wrap Text
    

    


    
    
    

A composition is an association that represents a strong whole-part relationship.
Example A Board (used for playing board games) consists of Square objects.

Composition implies:

1. when the whole is destroyed, parts are destroyed too i.e., the part cannot exist without being attached to a whole.
2. there cannot be cyclical links.

Whether a relationship is a composition can depend on the context.

A common use of composition is when parts of a big class are carved out as smaller classes to make the internal design easier to manage. In such cases, the classes extracted out still act as parts of the bigger class and the outside world has no business knowing about them.

Cascading deletion alone is not sufficient for composition. Suppose there is a design in which Person objects are attached to Task objects and the former get deleted whenever the latter are deleted. This fact alone does not mean there is a composition relationship between the two classes. For it to be composition, a Person must be an integral part of a Task in the context of that association, at the concept level (not simply at implementation level).

Identifying and keeping track of composition relationships in the design has benefits such as helping to maintain the data integrity of the system. For example, when you know that a certain relationship is a composition, you can take extra care in your implementation to ensure that when the whole object is deleted, all its parts are deleted too.

Implementing composition

Composition is implemented using a normal variable. If correctly implemented, the ‘part’ object will be deleted when the ‘whole’ object is deleted. Ideally, the ‘part’ object may not even be visible to clients of the ‘whole’ object.

class Email {
    private Subject subject;
  ...
}

    

    Copy
    

    


    
    
    
    

    Wrap Text
    

    


    
    
    

class Email:

  def __init__(self):
    self.__subject = Subject()

    

    Copy
    

    


    
    
    
    

    Wrap Text
    

    


    
    
    

Aggregation represents a container-contained relationship. It is a weaker relationship than composition.
Example SportsClub can act as a container for Person objects who are members of the club. Person objects can survive without a SportsClub object.

Implementing aggregation

Implementation is similar to that of composition except the containee object can exist even after the container object is deleted.

class Team {
    Person leader;
    ...
    void setLeader(Person p) {
        leader = p;
    }
}

    

    Copy
    

    


    
    
    
    

    Wrap Text
    

    


    
    
    

class Team:
  
  def __init__(self):
    self.__leader = None
    
  def set_leader(self, person):
    self.__leader = person

    

    Copy
    

    


    
    
    
    

    Wrap Text
    

    


    
    
    

An association class represents additional information about an association. It is a normal class but plays a special role from a design point of view.
Example A Man class and a Woman class are linked with a ‘married to’ association and there is a need to store the date of marriage. However, that data is related to the association rather than specifically owned by either the Man object or the Woman object. In such situations, an additional association class can be introduced, e.g., a Marriage class, to store such information.

Implementing association classes

There is no special way to implement an association class. It can be implemented as a normal class that has variables to represent the endpoints of the association it represents.

class Transaction {

    //all fields are compulsory
    Person seller;
    Person buyer;
    Date date;
    String receiptNumber;

    Transaction(Person seller, Person buyer, Date date, String receiptNumber) {
        //set fields
    }
}

    

    Copy
    

    


    
    
    
    

    Wrap Text
    

    


    
    
    

The OOP concept Inheritance allows you to define a new class based on an existing class.
Example For example, you can use inheritance to define an EvaluationReport class based on an existing Report class so that the EvaluationReport class does not have to duplicate data/behaviors that are already implemented in the Report class. The EvaluationReport can inherit the wordCount attribute and the print() method from the base class Report.

• Other names for Base class: Parent class, Superclass
• Other names for Derived class: Child class, Subclass, Extended class

A superclass is said to be more general than the subclass. Conversely, a subclass is said to be more specialized than the superclass.

Applying inheritance to a group of similar classes can result in the common parts of those classes being extracted into more general classes.
Example Man and Woman behave the same way for certain things. However, the two classes cannot be simply replaced with a more general class Person because of the need to distinguish between Man and Woman for certain other things. A solution is to add the Person class as a superclass (to contain the code common to men and women) and let Man and Woman inherit from the Person class.

Inheritance implies that the derived class can be considered a subtype of the base class (and the base class is a supertype of the derived class), resulting in an is-a relationship.

Inheritance does not necessarily mean a subtype relationship exists. However, the two often go hand-in-hand. For simplicity, at this point let us assume inheritance implies a subtype relationship.

Inheritance relationships through a chain of classes can result in inheritance hierarchies (aka inheritance trees).

Example Two inheritance hierarchies/trees are given below. Note that the triangle points to the parent class. Observe how the Parrot is a Bird as well as an Animal.

Multiple Inheritance is when a class inherits directly from multiple classes. Multiple inheritance among classes is allowed in some languages (e.g., Python, C++) but not in other languages (e.g., Java, C#).

Example The Honey class inherits from the Food class and the Medicine class because honey can be consumed as a food as well as a medicine (in some oriental medicine practices). Similarly, a Car is a Vehicle, an Asset, and a Liability.

Method overriding is when a subclass changes the behavior inherited from the parent class by re-implementing the method. Overridden methods have the same name, the same type signature, and the same (or a subtype of the) return type.

Method overloading is when there are multiple methods with the same name but different type signatures. Overloading is used to indicate that multiple operations do similar things but take different parameters.

An interface is a behavior specification i.e., a collection of . If a class , it means the class is able to support the behaviors specified by that interface.

There are a number of situations in software engineering when it is important for disparate groups of programmers to agree to a "contract" that spells out how their software interacts. Each group should be able to write their code without any knowledge of how the other group's code is written. Generally speaking, interfaces are such contracts. _{--Oracle Docs on Java
Example Suppose SalariedStaff is an interface that contains two methods setSalary(int) and getSalary(). AcademicStaff can declare itself as implementing the SalariedStaff interface, which means the AcademicStaff class must implement all the methods specified by the SalariedStaff interface i.e., setSalary(int) and getSalary().}

A class implementing an interface results in an is-a relationship, just like in class inheritance.
Example In the example above, AcademicStaff is a SalariedStaff. An AcademicStaff object can be used anywhere a SalariedStaff object is expected e.g., SalariedStaff ss = new AcademicStaff().

You can declare a class as an abstract class when it is merely a representation of commonalities among its subclasses, in which case it does not make sense to instantiate objects of that class.
Example The Animal class that exists as a generalization of its subclasses Cat, Dog, Horse, Tiger, etc. can be declared as abstract because it does not make sense to instantiate an Animal object.

Example The move method of the Animal class is likely to be an abstract method as it is not possible to implement a move method at the Animal class level to fit all subclasses because each animal type can move in a different way.

A class that has an abstract method becomes an abstract class because the class definition is incomplete (due to the missing method body) and it is not possible to create objects using an incomplete class definition.

Every instance of a subclass is an instance of the superclass, but not vice versa. As a result, inheritance allows substitutability: the ability to substitute a child class object where a parent class object is expected.

Example Consider the Staff hierarchy below.

An AcademicStaff is an instance of a Staff, but a Staff is not necessarily an instance of an AcademicStaff. That is, wherever an object of the superclass is expected, it can be substituted by an object of any of its subclasses.

The following code is valid because an AcademicStaff object is substitutable for a Staff object.

Staff staff = new AcademicStaff(); // OK

    

    Copy
    

    


    
    
    
    

    Wrap Text
    

    


    
    
    

But the following code is not valid because staff is declared as a Staff type and therefore its value may or may not be of type AcademicStaff, which is the type expected by variable academicStaff.

Staff staff;
...
AcademicStaff academicStaff = staff; // Not OK

    

    Copy
    

    


    
    
    
    

    Wrap Text
    

    


    
    
    

Overridden methods are resolved using dynamic binding, and therefore resolve to the implementation in the object's actual type.

void adjustSalary(int byPercent) {
    for (Staff s: staff) {
        s.adjustSalary(byPercent);
    }
}

    

    Copy
    

    


    
    
    
    

    Wrap Text
    

    


    
    
    

In contrast, overloaded methods are resolved using static binding.

class Account {

    Account() {
        // Signature: ()
        ...
    }

    Account(String name, String number, double balance) {
        // Signature: (String, String, double)
        ...
    }
}

    

    Copy
    

    


    
    
    
    

    Wrap Text
    

    


    
    
    

void calculateGrade(int[] averages) { ... }
void calculateGrade(String matric) { ... }

    

    Copy
    

    


    
    
    
    

    Wrap Text
    

    


    
    
    

Polymorphism allows you to write code targeting superclass objects, use that code on subclass objects, and achieve possibly different results based on the actual class of the object.

Polymorphism literally means "ability to take many forms".

Three concepts combine to achieve polymorphism: substitutability, operation overriding, and dynamic binding.

• Substitutability: Because of substitutability, you can write code that expects objects of a parent class and yet use that code with objects of child classes. That is how polymorphism is able to treat objects of different types as one type.
• Overriding: To get polymorphic behavior from an operation, the operation in the superclass needs to be overridden in each of the subclasses. That is how overriding allows objects of different subclasses to display different behaviors in response to the same method call.
• Dynamic binding: Calls to overridden methods are bound dynamically to the implementation of the actual object's class at runtime. That is how the polymorphic code can call the method of the parent class and yet execute the implementation of the child class.

What is the difference between a Class, an Abstract Class, and an Interface?

• An interface is a behavior specification with no implementation.
• A class is a behavior specification + implementation.
• An abstract class is a behavior specification + a possibly incomplete implementation.

How does overriding differ from overloading?

Overloading is used to indicate that multiple operations do similar things but take different parameters. Overloaded methods have the same method name but different method signatures and possibly different return types.

Overriding is when a subclass redefines an operation using the same method name and the same type signature. Overridden methods have the same name, same method signature, and same return type.

A software requirement specifies a need to be fulfilled by the software product.

A software project may be one of two types:

• a brownfield project, i.e., a project to replace or update an existing software product
  Example Adding an online payment option to a university's existing course registration system.
• a greenfield project, i.e., a project to develop a new system from scratch
  Example Building a new app that lets students swap tutorial slots, where no such system exists yet.

In either case, requirements need to be gathered, analyzed, specified, and managed.

Requirements come from stakeholders.

Identifying requirements is often not easy.
Example Stakeholders may not be aware of their precise needs, may not know how to communicate their requirements correctly, or may not be willing to spend effort identifying requirements.

Requirements can be divided into two in the following way:

1. Functional requirements specify what the system should do.
   Example The system should allow a user to search for a book by its title.
2. Non-functional requirements specify the constraints under which the system is developed and operated.
   Example The search should return results within two seconds.

You may have to spend extra effort identifying NFRs as early as possible because:

1. NFRs are easier to miss.
   Example Stakeholders tend to think of functional requirements first.
2. Sometimes NFRs are critical to the success of the software.
   Example A web application that is too slow or that has weak security is unlikely to succeed even if it has all the right functionality.

Requirements can be prioritized based on the importance and urgency, while keeping in mind the constraints of schedule, budget, staff resources, quality goals, and other constraints.

A common approach is to group requirements into priority categories. Note that all such scales are subjective, and stakeholders define the meaning of each level in the scale for the project at hand.

Some requirements can be discarded if they are considered ‘out of ’.

Here are some characteristics of well-defined requirements ^{[📖 zielczynski]}:

• Unambiguous
• Testable (verifiable)
• Clear (concise, terse, simple, precise)
• Correct
• Understandable
• Feasible (realistic, possible)
• Independent
• Necessary
• Implementation-free (i.e., abstract)

Two of these carry most of the weight: a requirement that is unambiguous and testable states an observable result, so evidence can settle whether it has been met. A requirement that states a judgment instead can only be settled by argument. To make one testable, say who is involved, what they are doing, and what result counts as success.

Besides these criteria for individual requirements, the set of requirements as a whole should be:

• Consistent
• Non-redundant
• Complete

Requirements are not settled once and then left alone; they keep changing while the product is being built. Three reasons account for most of it:

1. Stakeholders work out what they want by seeing something concrete.
   Example A user who could not describe the report they needed can say exactly what is wrong with the first version of it.
2. The world the product lives in changes.
   Example A new regulation comes into force, or a competitor ships a feature that users now expect.
3. The team learns what things actually cost.
   Example A requirement turns out to take ten times the effort everyone assumed, which changes whether it is worth having at all.

Two things follow from this.

A specification that is not kept up to date does not become harmless, it becomes misleading, because people keep acting on it. A developer builds the version that was superseded a month ago; a tester reports a defect against behavior nobody wants any more.

Every change is also a decision about what will not be built. Accepting a new requirement late competes with requirements already agreed, so priorities have to be revisited rather than settled once at the start.

In a brainstorming session there are no "bad" ideas. The aim is to generate ideas, not to validate them. Brainstorming encourages you to "think outside the box" and put "crazy" ideas on the table without fear of rejection.

Surveys can be used to solicit responses and opinions from a large number of stakeholders regarding a current product or a new product.

Observing users in their natural work environment can uncover product requirements. Usage data from an existing system can also show how that system is being used, which can help in building a better replacement.
Example Usage data can reveal the situations where the user makes mistakes when using the current system.

Interviewing stakeholders and domain experts can produce useful information about project requirements. How much it produces depends far more on how the interview is run than on how long it lasts.

1. Find out what the person is responsible for before you meet them, and decide what only they can tell you. An interview spent on things you could have looked up is a wasted one.
2. Open with something concrete rather than an abstract question. 'What do you need?' invites a vague answer, or a feature request that hides the need behind it. Walking through a recent situation, a screen of the current system, or a prototype gets you specifics.
3. Ask what goes wrong today and what they do instead. Workarounds are where unmet requirements hide: if someone keeps a private spreadsheet, the system is failing them in a way worth understanding.
4. Play the answer back in your own words before moving on. It is very common for both sides to leave an interview believing they agreed, having understood different things.
5. Confirm your written notes with the interviewee afterwards. They can correct what you misheard while they still remember what they said.

Treat what you hear as claims to be checked, rather than requirements to be recorded. People often describe the process they are supposed to follow rather than the one they actually follow, and two stakeholders can want things that cannot both be true.
Example One department wants every leave application approved by a manager; another wants short absences to need no approval at all.

Focus groups are a kind of informal interview within an interactive group setting. A group of people (e.g. potential users, beta testers) is asked about their understanding of a specific issue, process, product, advertisement, etc.

Prototyping can uncover requirements, in particular, those related to how users interact with the system. UI prototypes or mock-ups, also called wireframe diagrams, are often used in brainstorming sessions or in meetings with users to get quick feedback.

Prototyping can be used for discovering as well as specifying requirements e.g. a UI prototype can serve as a specification of what to build.

Studying existing products can unearth shortcomings that a new product can address. Product manuals and other forms of documentation can tell us how existing solutions work.
Example When developing a game for a mobile device, a look at a similar PC game can give insight into the kind of features and interactions the mobile game can offer.

Gathering requirements tells you what people said; validating requirements tells you whether what you wrote down is what they meant. It is worth distinguishing from the check that comes much later:

• Validating requirements asks whether you have written down the right thing.
• Verifying software asks whether what was built matches what was written down.

A team that only does the second can build exactly the wrong product, correctly.

Three checks are cheap enough to run on a student project:

1. Walk the requirement back to the stakeholder in words they would use, and wait for the correction. Reading your own notes aloud to the person who gave them to you finds misunderstandings faster than any amount of rereading them yourself.
2. Put something in front of a user instead of describing it. People correct a rough sketch or a mock-up far more readily than they correct a paragraph, because they can see what they would actually be given.
3. State the observable result that would settle the requirement. If nobody can say what would count as having met it, the requirement is not yet saying anything a team could build against.

A requirement you cannot yet state in observable terms is not wrong, it is not ready. Record it as an open question, or as the next thing to put a prototype in front of. A product vision, an unresolved disagreement between two stakeholders, or a quality concern that nobody has quantified yet are all legitimate inputs at this stage; deleting them because they cannot be phrased as a check yet would throw away the very things most worth resolving.

A textual description (i.e., prose) can be used to describe requirements. Prose is especially useful when describing abstract ideas such as the vision of a product.

Avoid using lengthy prose to describe requirements; they can be hard to follow.

A common format for writing user stories is:

You can write user stories using a physical medium or a digital tool. For example, you can use index cards or sticky notes, and arrange them on walls or tables. Alternatively, you can use software (e.g., GitHub Project Boards, Trello, Google Docs, ...) to manage user stories digitally.

User stories in use

With sticky notes

^{[credit: https://www.flickr.com/photos/jakuza/2682466984/]}

---

With paper

^{[credit: https://www.flickr.com/photos/jakuza/with/2726048607/]}

---

With software

^{[credit: https://commons.wikimedia.org/wiki/File:User_Story_Map_in_Action.png]}

---

---

The {benefit} can be omitted if it is obvious.

It is recommended to confirm there is a concrete benefit even if you omit it from the user story. If not, you could end up adding features that have no real benefit.

You can add more characteristics to the {user role} to provide more context to the user story.

You can write user stories at various levels. High-level user stories, called epics (or themes) cover bigger functionality. You can then break down these epics into multiple user stories of normal size.

You can add conditions of satisfaction to a user story to specify things that need to be true for the user story implementation to be accepted as ‘done’.

These are more widely known as acceptance criteria. Whatever they are called, they are the part of a story that states an observable result, and therefore the part that survives when the conversation behind the story does not.

Other useful information that can be added to a user story includes (but is not limited to):

• Priority: how important the user story is
• Size: the estimated effort to implement the user story
• Urgency: how soon the feature is needed

User stories capture user requirements in a way that is convenient for , , and .

[User stories] strongly shift the focus from writing about features to discussing them. In fact, these discussions are more important than whatever text is written. _{[Mike Cohn, MountainGoat Software 🔗]}

User stories differ from mainly in the level of detail. User stories should only provide enough details to make a reasonably low-risk estimate of how long the user story will take to implement. When the time comes to implement the user story, the developers will meet with the customer face-to-face to work out a more detailed description of the requirements. [more...]

Leaving out detail on purpose relies on the implementer being able to come back and ask. Where asking is slow or does not happen at all — work handed to another team across a time zone, or generated in a single pass by an AI coding assistant with no round of clarification — an unstated detail never surfaces as a question. It gets filled in with a plausible guess, and the guess arrives faster than the question ever would.
Example 'As a user, I can delete a task' leaves open whether deleting is recoverable. Someone who can ask, asks. Someone working from the story alone picks one, and the answer looks finished either way.

The further the implementer sits from the conversation, the more of a story's meaning has to survive in writing — which is the job the acceptance criteria are doing.

User stories can capture non-functional requirements too because even NFRs must benefit some stakeholder.

While user stories can be recorded on in the initial stages, an online tool is more suitable for longer-term management of user stories, especially if the team is not .

A use case describes an interaction between the user and the system for a specific functionality of the system.

System: Online Banking System (OBS)
Use case: UC23 - Transfer Money
Actor: User
MSS:
  1. User chooses to transfer money.
  2. OBS requests for details of the transfer.
  3. User enters the requested details.
  4. OBS requests for confirmation.
  5. User confirms.
  6. OBS transfers the money and displays the new account balance.
  Use case ends.

UML includes a diagram type called use case diagrams that can illustrate use cases of a system visually, providing a visual ‘table of contents’ of the use cases of a system.

In the example on the right, note how use cases are shown as ovals and user roles relevant to each use case are shown as stick figures connected to the corresponding ovals.

Use cases capture the functional requirements of a system.

Specifying a term in the glossary is useful in the following cases:

• A domain-specific/technical term that may not be known to all stakeholders, to indicate its definition
• When a term has multiple meanings, to indicate which of them is used in the project
• When there are multiple terms used for the same concept, to indicate which of them will be used in the project

A supplementary requirements section can be used to capture requirements that do not fit elsewhere. Typically, this is where most Non-Functional Requirements will be listed.

Teams package these formats in different ways: some collect them into a single document that says what is to be built, while others keep each format where it is most useful and write down only what needs agreeing.

Where there is such a document, product-led teams usually call it a product requirements document (PRD), or a product brief. It typically carries the product's purpose, who it is for, the scope and the priorities within it, the stories or use cases that matter most, and the quality constraints the product has to meet.

A software requirements specification (SRS) is its more formal counterpart, used where requirements have to be agreed precisely with a customer, audited, or contracted for. An SRS is heavier, more structured, and more stable than a PRD; the two are not interchangeable names for the same thing.

A single document is one common packaging, not a rule. Many teams keep user stories in a tracker, the glossary in a wiki, and prototypes in a design tool, and write down only what needs agreeing in one place.

Each format earns its place by doing a different job:

• Prose frames the problem and the product's purpose.
• A feature list supports scope and delivery discussions.
• A user story records one negotiable slice of user value.
• A use case makes one workflow, and what can go wrong in it, precise.
• A glossary settles what shared terms mean.
• Supplementary requirements capture what cuts across all of the above.

Choosing between them is a question of what you need to be precise about, not of which notation is better.

Working from such a document has a name: specification-driven development means starting from a specification that is clear, versioned, and testable, and using it both to direct the implementation and to judge what comes back. The second half is the part that is easy to skip. A specification that only ever directs work, and is never used to check the result against, is a wish list.

This matters more as producing a candidate implementation gets cheaper. An assistant can draft questions, propose alternatives, or write code, but it cannot establish what stakeholders actually want, and it cannot decide a trade-off between things two of them both want. Those stay with the people accountable for the product, which is why writing the specification, and the judgment that goes into it, is the part of this work that does not get handed off.

Software design has two main aspects:

• Product/external design: designing the external behavior of the product to meet the users' requirements. This is usually done by product designers with input from business analysts, user experience experts, user representatives, etc.
• Implementation/internal design: designing how the product will be implemented to meet the required external behavior. This is usually done by software architects and software engineers.

The guiding principle of abstraction is that only details that are relevant to the current perspective or the task at hand need to be considered. As most programs are written to solve complex problems involving large amounts of intricate details, it is impossible to deal with all these details at the same time. That is where abstraction can help.

Data abstraction: abstracting away the lower level data items and thinking in terms of bigger entities
Example Within a certain software component, you might deal with a user data type, while ignoring the details contained in the user data item such as name and date of birth. These details have been ‘abstracted away’ as they do not affect the task of that software component.

Control abstraction: abstracting away details of the actual control flow to focus on tasks at a higher level
Example print("Hello") is an abstraction of the actual output mechanism within the computer.

Abstraction can be applied repeatedly to obtain progressively higher levels of abstraction.
Example Levels of data abstraction: a File is a data item that is at a higher level than an array, and an array is at a higher level than a bit.
Example Levels of control abstraction: execute(Game) is at a higher level than print(Char), which is at a higher level than an Assembly language instruction MOV.

Abstraction is a general concept that is not limited to just data or control abstractions.

Coupling is a measure of the degree of dependence between components, classes, methods, etc. Low coupling indicates that a component is less dependent on other components. High coupling (aka tight coupling or strong coupling) is discouraged due to the following disadvantages:

• Maintenance is harder because a change in one module could cause changes in other modules coupled to it (i.e., a ripple effect).
• Integration is harder because multiple components coupled with each other have to be integrated at the same time.
• Testing and reuse of the module are harder due to its dependence on other modules.

Example Design A appears to have more coupling between the components than design B.

X is coupled to Y if X depends on Y such that some changes to Y may require corresponding changes in X.

Cohesion is a measure of how strongly related and focused the various responsibilities of a component are. A highly cohesive component keeps related functionalities together while keeping out all other unrelated things.

Higher cohesion is better. Disadvantages of low cohesion (aka weak cohesion):

• Lowers the understandability of modules as it is difficult to express module functionalities at a higher level.
• Lowers maintainability because a module can be modified due to unrelated causes (reason: the module contains unrelated pieces of code) or many modules may need to be modified to achieve a small change in behavior (reason: the code related to that change is not localized to a single module).
• Lowers reusability of modules because they do not represent logical units of functionality.

Cohesion can be present in many forms. Some examples:

• Code related to a single concept is kept together, e.g. the Student component handles everything related to students.
• Code that is invoked close together in time is kept together, e.g. all code related to initializing the system is kept together.
• Code that manipulates the same data structure is kept together, e.g. the GameArchive component handles everything related to the storage and retrieval of game sessions.

Example Suppose a Payroll application contains a class that deals with writing data to the database. If the class includes some code to show an error dialog to the user if the database is unreachable, that class is not cohesive because it seems to be interacting with the user as well as the database.

A model is a representation of something else.
Example A class diagram is a model that represents a software design.

A model provides a simpler view of a complex entity because a model captures only a selected aspect. This omission of some aspects implies models are abstractions.

Example A class diagram captures the structure of the software design but not the behavior.

Multiple models of the same entity may be needed to capture it fully.
Example In addition to a class diagram (or even multiple class diagrams), a number of other diagrams may be needed to capture various interesting aspects of the software.

In software development, models are useful in several ways:

a) To analyze a complex entity related to software development, such as the the software has to operate in.

b) To communicate information among stakeholders. Models can be used as a visual aid in discussions and documentation.

c) As a blueprint for creating software. Models can be used as instructions for building software.

The following diagram uses the class diagram notation to show the different types of UML diagrams.

An OO solution is basically a network of objects interacting with each other. Therefore, it is useful to be able to model how the relevant objects are 'networked' together inside a software i.e., how the objects are connected together.

Note that these object structures within the same software can change over time.

However, object structures do not change at random; they change based on a set of rules set by the designer of that software. Those rules that object structures need to follow can be illustrated as a class structure i.e., a structure that exists among the relevant classes.

UML Object Diagrams model object structures. UML Class Diagrams model class structures.

Classes form the basis of class diagrams.

Associations are the main connections among the classes in a class diagram.

The most basic class diagram is a bunch of classes with some solid lines among them to represent associations, such as this one.

Example A class diagram showing associations between classes.

In addition, associations can show additional decorations such as association labels, association roles, multiplicity and navigability to add more information to a class diagram.

Example Here is the same class diagram shown earlier but with some additional information included:

UML notes can be used to add more info to any UML model.

A class diagram can also show different types of relationships between classes: inheritance, compositions, aggregations, dependencies.

A class diagram can also show different types of class-like entities:

A class diagram can show association classes too.

UML elements can be further customized using the UML stereotypes mechanism.

Object diagrams use a notation similar to that of class diagrams (as the former are instantiations of the latter).

Sequence diagrams model the interactions between various entities in a system, in a specific scenario. Modeling such scenarios is useful, for example, to verify the design of the internal interactions is able to provide the expected outcomes.

Example Modeling how components of a system interact with each other to respond to a user action.
Example Modeling how objects inside a component interact with each other to respond to a method call it received from another component.

When you write a small program by yourself, you can hold its structure in your head. You know where each piece of functionality lives, and you can usually predict what a change will affect.

That becomes much harder as the software and its team grow. Several people add code to the same program at once, and none of them has read all of it. Questions that once seemed trivial start to matter:

• Where does this new code belong?
• Where does each part run?
• How do the parts communicate?
• Which qualities matter most — ease of change, speed, reliability, security?

Software architecture is the set of significant decisions about a system's overall organization. It identifies the major parts, their responsibilities, how they interact, and how they are deployed.

Example Consider a desktop invoice-management application in which users create invoices, set due dates, and mark invoices as paid. A possible architecture has four parts:

Each arrow in the diagram is a dependency: the part at the tail needs the part at the head.

• Ui: displays information and receives user input
• Logic: interprets user actions and carries out operations
• Model: represents invoices and other data while the program runs
• Storage: reads data from and writes it to persistent storage

An architecture description deliberately leaves out most of what is inside each part. It does not say how many classes are in Logic, which one validates a user command, or which collection holds the invoices. Those are detailed design decisions.

Architecture and detailed design differ in how far a decision reaches, not merely in how big it is. An architectural decision constrains what the other parts can do, shapes the qualities the system can achieve, and is expensive to reverse once the rest of the system is built on it.

The boundary is not absolute. An internal choice becomes architecturally significant when it strongly affects the rest of the system.

Every software system has an architecture, even when nobody designed one deliberately. An unplanned program still has parts and dependencies; they are simply accidental, undocumented, and usually tangled. The value of deciding an architecture on purpose is that the team shares one, understands it, and can reason about it.

An architecture is a shared and evolving technical understanding, not one person's private plan. A team sets an initial architecture early — the decisions are expensive to reverse later — then tests it against real requirements and revises it deliberately when those requirements change. Larger organizations may give one person an architect role to hold the technical vision, but the architecture still has to be understood by everyone building the system.

An architecture is also more than a diagram. Although an architecture is often represented by a diagram (like the one in the example above), a diagram shows one view. The architecture also includes the constraints everyone must work within and the reasons behind the choices.

The definition above is widely quoted in the literature. "Externally visible properties" means what promises to do, not how it does it.

Architecture diagrams have no universally adopted notation. Unlike UML class diagrams, there is no rulebook: different teams use different shapes, colors, and arrows. A reader must first work out what the notation means.

Read an architecture diagram by asking four questions in order:

1. What view is this? Code organization, deployment, communication, or something else — each shows different information.
2. What are the major parts? Usually the boxes. Expect a handful, not thirty.
3. What is each part responsible for? Names, labels, and nearby text should make this clear.
4. What do the relationships mean? Follow each arrow's direction, and check the legend for what an arrow means.

A single diagram need not explain the whole architecture, but it must communicate its chosen view without ambiguity. Judge it against its stated purpose and the documentation it ships with: if the four questions cannot be answered from the diagram, its caption, and the text around it, something is missing — a useful thing to notice when reviewing a teammate's work.

While architecture diagrams have no standard notation, follow these guidelines when drawing them.

• State the view and what the arrows mean. Put the meaning in a legend or caption. If you need two kinds of arrow, make them visually different and label both.
• Name each component by its responsibility, not its current implementation.
  Example Storage stays accurate if the implementation changes; JsonFileHandler becomes a lie the day you switch to a database.
• Show only what is architecturally relevant. If a box maps one-to-one onto a single class, the diagram has drifted into detailed design. A crowded diagram is usually a sign that it has slipped to a lower level of abstraction than it claims.
• Minimize the variety of symbols, and prefer familiar ones e.g., a drum shape is widely understood to represent a database. Explain any symbol whose meaning may not be obvious.
• Avoid the indiscriminate use of double-headed arrows.

Example Consider the two architecture diagrams of the same software given below. Because Diagram 2 uses double-headed arrows everywhere, the important fact that GUI has a genuinely bidirectional dependency with the Logic component is no longer visible — it looks like every other connection.

An architectural style is a reusable way of organizing the major parts of a system (aka architectural pattern), just as building architectures follow recognized styles. Naming a style (e.g., "layered", "client-server") lets developers refer to a familiar arrangement without explaining it from scratch.

Different styles describe different aspects of a system, which is why one system can use several at once. This is the most useful thing to know before learning different architectural styles.

In the layered style, the software is divided into layers whose dependencies all point one way — downward. Higher layers use services provided by lower ones; lower layers know nothing about the layers above.

Layered designs differ in how strictly they enforce the separation. In strict (or closed) layering, a layer may use only the layer immediately below it. In the more common relaxed form, a layer may use any lower layer, skipping intermediate ones. What both share, and what actually matters, is that dependencies never point back up. Because a lower layer depends on nothing above it, you can understand, test, and replace it on its own. The moment Storage calls back into Ui to show an error dialog, that property is lost and the two must be understood together.

Layers are not tiers. A layer is a logical division inside the software; a tier is a part that is deployed separately. The two are often confused, partly because the term n-tier is frequently used to mean layered.

A monolith is a system deployed as a single unit. You build one artifact and release it as a whole. A typical desktop application is a monolith, as is a great deal of successful commercial software.

Being one deployable unit does not mean one running process. A monolith may be launched as several processes, or run as many identical copies behind a load balancer — but they are all copies of the same thing, released together.

A modular monolith is a single deployable unit organized internally into well-defined components. It is still one artifact, but inside it the parts have clear responsibilities, clear interfaces, and disciplined dependencies.

"Monolith" is not a synonym for "badly structured." This is the most common misunderstanding. The word describes how the system is deployed, not how well it is organized. A tangled ball of mud and a disciplined modular monolith share a deployment shape but differ enormously inside; what separates them is whether the internal components and dependencies are real.

Each arrow is a dependency. Both are monoliths — one deployed unit each, identical from the outside. What differs is inside: on the left, responsibilities are mixed and dependencies point both ways; on the right, each component has one job and the dependencies run one way.

The modular monolith is usually the sensible starting point for one team building one product. It keeps building, testing, and debugging simple while still encouraging clear responsibilities.

In the client-server style, a server provides a capability or data, and one or more clients use it.

Sharing data among several installations is the most common reason to reach for client-server, but it is not the only one — clients also use a server for centralized computation, authentication, or coordination. In the shared-data case, the fix is to give the shared data a home of its own: a separate program — the server — becomes the authoritative owner of the invoices, and each desktop application becomes a client, sending a request such as "add this invoice" and receiving a response from the server.

Example Suppose several users need to edit the same set of invoices from their own desktop applications. Local files no longer suffice, because each installation would hold a different copy, and no installation can reach another's hard disk.

Adding a server changes both views of the invoice manager. In the logical view, RemoteStorage now depends on a request handler that owns the shared data; in the deployment view, client and server become separately deployed parts that exchange messages over a network.

In the logical view, each arrow is a dependency. In the deployment view, each arrow is a message sent between separately deployed parts.

Adding a server changes more than the location of data storage (or whatever else the clients need to share). A real split adds architectural elements and concerns:

• a client-side component that sends requests;
• a server-side component that receives and handles them;
• an agreed request and response format, so both sides read messages the same way; and
• handling for timeouts, failures, and version mismatches — concerns that the purely local design did not have.

A good interface limits the impact of moving to a client-server architecture but does not avoid it entirely.

This is also where tiers appear. The client program is one tier and the server another — a tier being a separately deployed part, not necessarily one physical machine.

A network boundary adds costs that local calls never had:

• Requests take far longer, and less predictably. A method call inside a program is orders of magnitude faster than a request that crosses a network, and unlike a local call, a network request takes a different amount of time on each attempt. Users notice both.
• Failures can be partial. A timeout does not reveal whether the server failed before or after doing the work. Retrying carelessly can perform the operation twice.
• Versions must stay compatible. A new server may still receive requests from an old client.
• Security becomes prominent. The server must decide who may read or change the shared data.

Example Client-server is extremely common — online games, email, collaborative applications, and web applications all use it, though it is in no way limited to browser-based software.

In software development, there are certain problems that recur in a certain context.

After repeated attempts at solving such problems, better solutions are discovered and refined over time. These solutions are known as design patterns, a term popularized by the seminal book Design Patterns: Elements of Reusable Object-Oriented Software by the so-called "Gang of Four" (GoF) written by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides.

The common format to describe a pattern consists of the following components:

• Context: The situation or scenario where the design problem is encountered.
• Problem: The main difficulty to be resolved.
• Solution: The core of the solution. It is important to note that the solution presented only includes the most general details, which may need further refinement for a specific context.
• Anti-patterns (optional): Commonly used solutions, which are usually incorrect and/or inferior to the Design Pattern.
• Consequences (optional): Identifying the pros and cons of applying the pattern.
• Other useful information (optional): Code examples, known uses, other related patterns, etc.

Context

Certain classes should have no more than just one instance (e.g. the main controller class of the system). These single instances are commonly known as singletons.

Problem

A normal class can be instantiated multiple times by invoking the constructor.

Solution

Make the constructor of the singleton class private, because a public constructor will allow others to instantiate the class at will. Provide a public class-level method to access the single instance.

Example The Logic class below is a Singleton.

The <<Singleton>> in the class above uses the UML stereotype notation, which is used to (optionally) indicate the purpose or the role played by a UML element. In this example, the class Logic is playing the role of a Singleton class. The general format is <<role/purpose>>.

Here is the typical implementation of how the Singleton pattern is applied to a class:

class Logic {
    private static Logic theOne = null;

    private Logic() {
        ...
    }

    public static Logic getInstance() {
        if (theOne == null) {
            theOne = new Logic();
        }
        return theOne;
    }
}

    

    Copy
    

    


    
    
    
    

    Wrap Text
    

    


    
    
    

Notes:

• The constructor is private, which prevents instantiation from outside the class.
• The single instance of the singleton class is maintained by a private class-level variable.
• Access to this object is provided by a public class-level operation getInstance() which instantiates a single copy of the singleton class when it is executed for the first time. Subsequent calls to this operation return the single instance of the class.

If Logic were not a Singleton class, a Logic object could be created as follows:

Logic m = new Logic();

    

    Copy
    

    


    
    
    
    

    Wrap Text
    

    


    
    
    

But when it is a Singleton class, the single Logic object needs to be accessed as follows:

Logic m = Logic.getInstance();

    

    Copy
    

    


    
    
    
    

    Wrap Text
    

    


    
    
    

Pros:

• easy to apply
• effective in achieving its goal with minimal extra work
• provides an easy way to access the singleton object from anywhere in the codebase

Cons:

• The singleton object acts like a global variable that increases coupling across the codebase.
• In testing, it is difficult to replace Singleton objects with stubs (static methods cannot be overridden).
• In testing, singleton objects carry data from one test to another even when you want each test to be independent of the others.

Given that there are some significant cons, it is recommended that you apply the Singleton pattern when, in addition to requiring only one instance of a class, there is a risk of creating multiple objects by mistake, and creating such multiple objects has real negative consequences.

Context

Components need to access functionality deep inside other components.

Example The UI component of a Library system might want to access functionality of the Book class contained inside the Logic component.

Problem

Access to the component should be allowed without exposing its internal details.
Example The UI component should access the functionality of the Logic component without knowing that it contains a Book class within it.

Solution

Include a class that sits between the component internals and users of the component such that all access to the component happens through the Facade class.

Example The following class diagram applies the Facade pattern to the Library System example. The LibraryLogic class is the Facade class.

Professional software engineers often write code using Integrated Development Environments (IDEs). IDEs support most development-related work within the same tool (hence, the term integrated).

An IDE generally consists of:

• A source code editor that includes features such as syntax coloring, auto-completion, easy code navigation, error highlighting, and code-snippet generation.
• A compiler and/or an interpreter (together with other build automation support) that facilitates the compilation, linking, running, and deployment of a program.
• A debugger that allows the developer to execute the program one step at a time to observe the run-time behavior in order to locate bugs.
• Other tools that aid various aspects of coding, e.g., support for automated testing, drag-and-drop construction of UI components, version management support, simulation of the target runtime platform, modeling support, AI-assisted coding help, and collaborative coding with others.

Examples of popular IDEs:

• Java: Eclipse, IntelliJ IDEA, NetBeans
• C#, C++: Visual Studio
• Swift: Xcode
• Python: PyCharm
• Multiple languages: VS Code

Some experienced developers, in particular those with a UNIX background, prefer lightweight yet powerful text editors with scripting capabilities (e.g., Vim or NeoVim) over heavier IDEs.

This topic is now deprecated.

Debugging is the process of finding the cause of a known problem in a program, and fixing it. It starts after you know something is wrong — whether a test, a user, or monitoring exposed it; finding that the problem exists is a separate activity. The hard part is usually the diagnosis rather than the correction: once you understand why a program misbehaves, the edit itself is often a single character — though choosing which edit is a decision in its own right.

To debug well, distinguish four things that beginners tend to lump together as 'the bug':

• A mistake is the human (or AI) act that started it all.
  Example You misremembered that list indices start at 1.
• A defect is the resulting error in the code. This is what most people mean by 'a bug'.
  Example A loop that starts counting from the wrong index.
• An infection is the resulting error in the program state at run time. When the defective line executes, some variable now holds a wrong value.
• A failure is the externally visible wrong behavior.
  Example A total shown to the user that is too small, or a crash.

These four form a chain, and each link can be far from the next:

mistake → defect → infection → infection → ... → failure
          (code)   (state)      (state)          (behavior)

    

    Copy
    

    


    
    
    
    

    Wrap Text
    

    


    
    
    

Debugging is therefore a search, not a lookup: you observe the failure but must fix the defect. The infection spreads as the wrong value is passed on, stored in a field, or used to compute another wrong value, so where the program crashed is usually not where the mistake was made. The chain also explains why bugs hide: a defect infects the state only when that line executes, and an infection becomes a failure only if it propagates out to something observable. A defect can sit in daily-executed code for months unnoticed.

The chain assumes the fault lies in code — the common case, but not the only one. A failure can equally originate in configuration, in data left by an earlier version, in a dependency, in the deployment, or in a requirement that was wrong to begin with. Sometimes the program is right while the test is wrong — the test may hold its own defect, or the expectation it encodes may never have been correct. Only an error in the code is a defect; where the fault lies elsewhere, call it the cause. Either way the search is the same: locate whatever has to change.

class Cart {
    private final List<Item> items = new ArrayList<>();

    void add(Item item) {
        items.add(item);
    }

    List<Item> getItems() {
        return items;
    }

    int computeTotal() {
        int total = 0;
        List<Item> pending = getItems();
        while (!pending.isEmpty()) {
            total += pending.remove(0).price();
        }
        return total;
    }
}

    

    Copy
    

    


    
    
    
    

    Wrap Text
    

    


    
    
    

Why debugging is hard

Debugging consumes a large share of real development effort, and a single stubborn defect routinely costs more than writing the code it hides in. Beginners tend to read time spent debugging as evidence that they are bad at programming. It is not; debugging is a distinct and learnable engineering skill.

Three things make it hard:

• The distance between defect and failure: the crash site is not the crime scene, so the instinct to study the code around the error message is often the least productive move available.
• You cannot inspect everything — a running program holds an enormous amount of state, changing at every step, and choosing which small part to look at is most of the skill.
• Your mental model of the code is exactly the thing that is wrong: had you understood it correctly you would not have written the defect, so re-reading with the same assumptions reproduces the same blind spot. Hence debugging must be driven by evidence from the running program, not by reasoning alone.

Debugging time is therefore not proportional to the size of the fix. A one-character correction can cost an afternoon. The cost lives in the search, and every debugging technique aims at making that search cheaper.

How not to debug

Most unproductive debugging comes from having no method, rather than from using the wrong tool.

• Bad Stare and hope — reading the code and waiting for the bug to reveal itself. This inspects the code but not the state, using the mental model that wrote the defect. Fine as a 30-second first try; a poor plan for the next two hours.
• Bad Shotgun debugging — changing whatever looks suspicious and re-running to see whether it helped. Each run teaches you nothing: a change that does not fix the problem has neither confirmed nor eliminated any explanation, and unrelated edits accumulate.
• Bad Debugging into existence — mutating the code until the symptom disappears. The symptom often vanishes because a second defect cancels the first, leaving two bugs and a harder problem later. The difference from shotgun debugging is the stopping rule: here you stop when the symptom goes away, having never identified a cause.
• Bad Fixing the symptom instead of the cause. The failure goes away and the defect stays.
  Example Special-casing the input that fails, or wrapping the crash in an empty catch block.
• Bad Keeping no record of what you tried. Without notes you will re-test explanations you already eliminated, lose your place when interrupted, and be unable to hand the problem over.

Adding temporary print statements is not necessarily bad; doing so without a hypothesis is — that is shotgun debugging in another form. A few prints chosen to answer a specific question are legitimate, and in production, embedded, or concurrent settings they are sometimes the only tool available.

What these have in common is that they produce activity without producing information. A productive debugging step is one that rules something out.

Always code as if the person who ends up maintaining your code will be a violent psychopath who knows where you live. _{-- Martin Golding}

Production code needs to be of high quality. Given how the world is becoming increasingly dependent on software, poor quality code is something no one can afford to tolerate.

Programs should be written and polished until they acquire publication quality. _{--Niklaus Wirth}

Among various dimensions of code quality, such as run-time efficiency, security, and robustness, one of the most important is readability (aka understandability). This is because in any non-trivial software project, code needs to be read, understood, and modified by other developers later on. Even if you do not intend to pass the code to someone else, code quality is still important because you will become a 'stranger' to your own code someday.

Avoid long methods as they often contain more information than what the reader can process at a time. Consider if shortening is possible when a method goes beyond 30 . The bigger the haystack, the harder it is to find a needle.

If you need more than 3 levels of indentation, you're screwed anyway, and should fix your program. _{--Linux 1.3.53 Coding Style}

Avoid deep nesting -- the deeper the nesting, the harder it is for the reader to keep track of the logic.

In particular, avoid arrowhead style code.

int subsidy() {
    int subsidy;
    if (!age) {
        if (!sub) {
            if (!notFullTime) {
                subsidy = 500;
            } else {
                subsidy = 250;
            }
        } else {
            subsidy = 250;
        }
    } else {
        subsidy = -1;
    }
    return subsidy;
}

    

    Copy
    

    


    
    
    
    

    Wrap Text
    

    


    
    
    

int calculateSubsidy() {
    int subsidy;
    if (isSenior) {
        subsidy = REJECT_SENIOR;
    } else if (isAlreadySubsidized) {
        subsidy = SUBSIDIZED_SUBSIDY;
    } else if (isPartTime) {
        subsidy = FULLTIME_SUBSIDY * RATIO;
    } else {
        subsidy = FULLTIME_SUBSIDY;
    }
    return subsidy;
}

    

    Copy
    

    


    
    
    
    

    Wrap Text
    

    


    
    
    

def calculate_subs():
    if not age:
        if not sub:
            if not not_fulltime:
                subsidy = 500
            else:
                subsidy = 250
        else:
            subsidy = 250
    else:
        subsidy = -1
    return subsidy

    

    Copy
    

    


    
    
    
    

    Wrap Text
    

    


    
    
    

def calculate_subsidy():
    if is_senior:
        return REJECT_SENIOR
    elif is_already_subsidized:
        return SUBSIDIZED_SUBSIDY
    elif is_parttime:
        return FULLTIME_SUBSIDY * RATIO
    else:
        return FULLTIME_SUBSIDY

    

    Copy
    

    


    
    
    
    

    Wrap Text
    

    


    
    
    

Avoid complicated expressions, especially those having many negations and nested parentheses. If you must evaluate complicated expressions, have them done in steps (i.e., calculate some intermediate values first and use them to calculate the final value).

return ((length < MAX_LENGTH) || (previousSize != length))
        && (typeCode == URGENT);

    

    Copy
    

    


    
    
    
    

    Wrap Text
    

    


    
    
    

boolean isWithinSizeLimit = length < MAX_LENGTH;
boolean isSameSize = previousSize != length;
boolean isValidCode = isWithinSizeLimit || isSameSize;

boolean isUrgent = typeCode == URGENT;

return isValidCode && isUrgent;

    

    Copy
    

    


    
    
    
    

    Wrap Text
    

    


    
    
    

return ((length < MAX_LENGTH) or (previous_size != length)) and (type_code == URGENT)

    

    Copy
    

    


    
    
    
    

    Wrap Text
    

    


    
    
    

is_within_size_limit = length < MAX_LENGTH
is_same_size = previous_size != length
is_valid_code = is_within_size_limit or is_same_size

is_urgent = type_code == URGENT

return is_valid_code and is_urgent

    

    Copy
    

    


    
    
    
    

    Wrap Text
    

    


    
    
    

The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility, and among other things he avoids clever tricks like the plague. _{-- Edsger Dijkstra}

Avoid magic numbers in your code. When the code has a number that does not explain the meaning of the number, it is called a "magic number" (as in "the number appears as if by magic"). Using a makes the code easier to understand because the name tells us more about the meaning of the number.

return 3.14236;
...
return 9;

    

    Copy
    

    


    
    
    
    

    Wrap Text
    

    


    
    
    

static final double PI = 3.14236;
static final int MAX_SIZE = 10;
...
return PI;
...
return MAX_SIZE - 1;

    

    Copy
    

    


    
    
    
    

    Wrap Text
    

    


    
    
    

return 3.14236
...
return 9

    

    Copy
    

    


    
    
    
    

    Wrap Text
    

    


    
    
    

PI = 3.14236
MAX_SIZE = 10
...
return PI
...
return MAX_SIZE - 1

    

    Copy
    

    


    
    
    
    

    Wrap Text
    

    


    
    
    

Similarly, you can have ‘magic’ values of other data types.

return "Error 1432"; // A magic string!

    

    Copy
    

    


    
    
    
    

    Wrap Text
    

    


    
    
    

return "Error 1432" # A magic string!

    

    Copy
    

    


    
    
    
    

    Wrap Text
    

    


    
    
    

Avoid any magic literals in general, not just magic numbers.

Make the code as explicit as possible, even if the language syntax allows it to be implicit. Here are some examples:

• [Java] Use explicit type conversion instead of implicit type conversion.
• [Java, Python] Use parentheses/braces to show groupings even when they can be skipped.
• [Java, Python] Use enumerations when a certain variable can take only a small number of finite values. For example, instead of declaring the variable 'state' as an integer and using values 0, 1, 2 to denote the states 'starting', 'enabled', and 'disabled' respectively, declare 'state' as type SystemState and define an enumeration SystemState that has values 'STARTING', 'ENABLED', and 'DISABLED'.

Lay out the code so that it adheres to the logical structure. The code should read like a story. Just as you use section breaks, chapters, and paragraphs to organize a story, use classes, methods, indentation, and line spacing in your code to group related segments of the code. For example, you can use blank lines to separate groups of related statements.

Sometimes, the correctness of your code does not depend on the order in which you perform certain intermediary steps. Nevertheless, this order may affect the clarity of the story you are trying to tell. Choose the order that makes the story most readable.