W programowaniu i projektowaniu komputerów zasada pojedynczej odpowiedzialności jest koncepcją, która opowiada się za poglądem, że każda klasa w programie powinna wykonywać tylko jedną funkcję w większej aplikacji. Pomysł ten częściowo promuje niektóre ideały programowania obiektowego, takie jak enkapsulacja, ponieważ cała klasa będzie skoncentrowana na wykonywaniu jednej odpowiedzialności i będzie w niewielkim stopniu polegać na klasach zewnętrznych. Jednocześnie jest to nieco sprzeczne z niektórymi koncepcjami wczesnego programowania obiektowego, ponieważ funkcja pojedynczego obiektu jest oddzielona od danych, które obiekt obsługuje, co oznacza, że wiele obiektów w połączeniu może wymagać skonstruowania, aby utrzymać niektóre dane centralne. Zasada pojedynczej odpowiedzialności jest podstawą modelu projektowego znanego jako projektowanie oparte na odpowiedzialności.
Przykładem zasady pojedynczej odpowiedzialności może być tradycyjna słuchawka telefoniczna. Niektóre zasady projektowania postrzegają słuchawkę jako pojedynczy obiekt, który obsługuje zarówno wejście z linii telefonicznej, jak i transmisję sygnału wyjściowego z głośnika. W modelu z jedną odpowiedzialnością, w którym jeden obiekt powinien mieć tylko jedną odpowiedzialność, słuchawka składałaby się z kilku oddzielnych obiektów, z których każdy pełnił jedną funkcję, na przykład tylko odbieranie danych wejściowych z linii telefonicznej lub tylko wysyłanie danych za pośrednictwem słuchawka.
Jedną z korzyści, jakie umożliwia stosowanie zasady pojedynczej odpowiedzialności, jest bardzo wysoki poziom abstrakcji i modułowości. W przykładzie ze słuchawką albo wejście z linii telefonicznej, albo sposób, w jaki sygnał jest wysyłany do użytkownika, można zmienić bez wpływu na sąsiednie klasy, o ile przestrzegają one tej samej umowy o interfejsie. Dodatkowo, możliwość ponownego wykorzystania niektórych komponentów może być bardzo wysoka, ponieważ każda klasa jest w pełni hermetyzowana i w bardzo niewielkim stopniu, jeśli w ogóle, opiera się na otaczających obiektach, skupiając się zamiast tego na swojej jedynej odpowiedzialności.
Komplikacją, jaką może stworzyć zasada pojedynczej odpowiedzialności, jest duża liczba klas i obiektów, które działają na tych samych danych. Może to oznaczać duże narzuty i skomplikowany proces projektowania. Może również utrudnić debugowanie dużego programu, ponieważ pojedyncza część programu może składać się z tysięcy małych plików klas.
Gdy zasada pojedynczej odpowiedzialności jest stosowana w projekcie opartym na odpowiedzialności, dane i metody wykorzystywane do manipulowania danymi są rozdzielone do celów projektowych. Chociaż prowadzi to do pewnej swobody, enkapsulacji i modułowości w projektowaniu, może również generować szereg pośrednich wzorców i projektów, które muszą być użyte w celu ułatwienia wielu klasom, które próbują współdziałać z danymi jednocześnie. Z drugiej strony, jeśli dane obiektu i metody używane do manipulowania nimi są połączone w jeden obiekt o wielu obowiązkach, kod może stać się trudniejszy do zmodyfikowania w miarę zwiększania się skali, zmiany lub zwiększania się systemu.