Hyppää sisältöön

Ohjelmointiperiaatteita

Moneen asiaan liittyy periaatteita tai nyrkkisääntöjä. Tässä on yksi joukko olio-ohjelmointiin liittyviä periaatteita.

SOLID

The Single-Responsibility Principle (SRP)

A class should have only one reason to change.

[Martin03]

The Open-Closed Principle (OCP)

Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.

[Martin96a]

The Liskov Substitution Principle (LSP)

Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.

[Martin96b]

The Interface Segregation Principle (ISP)

Clients should not be forced to depend upon interfaces that they do not use.

[Martin96d]

The Dependency Inversion Principle (DIP)

High level modules should not depend upon low level modules. Both should depend upon abstractions.

Abstractions should not depend upon details. Details should depend upon abstactions.

[Martin96c]

Cohesion

The Reuse/Release Equivalence Principle (REP)

The granule of reuse is the granule of release. Only components that are released through a tracking system can be effectively reused. This granule is the package.

[Martin96e]

The Common Reuse Principle (CRP)

The classes in a package are reused together. If you reuse one of the classes in a package, you reuse them all.

[Martin96e]

The Common Closure Principle (CCP)

The classes in a package should be closed together against the same kinds of changes. A change that affects a package affects all the classes in that package.

[Martin96e]

Coupling

The Acyclic Dependencies Principle (ADP)

The dependency structure between packages must be a Directed Acyclic Graph (DAG). That is, there must be no cycles in the dependency structure.

[Martin96e]

The Stable Dependencies Principle (SDP)

The dependencies between packages in a design should be in the direction of the stability of the packages. A package should only depend upon packages that are more stable that it is.

[Martin97]

The Stable Abstraction Principle (SAP)

Packages that are maximally stable should be maximally abstract. Instable packages should be concrete. The abstraction of a package should be in proportion to its stability.

[Martin97]


Lähdeaineistoa

[Martin95] Robert C. Martin, Designing Object-Oriented C++ Applications Using The Booch Method, (Prentice Hall, 1995, ISBN 0-13-203837-4)
[Martin96a] Robert C. Martin, The Open Closed Principle, (C++ Report, Jan, 1996)
[Martin96b] Robert C. Martin, The Liskov Substitution Principle, (C++ Report, March 1996)
[Martin96c] Robert C. Martin, The Dependency Inversion Principle, (C++ Report, May 1996)
[Martin96d] Robert C. Martin, The Interface Segregation Principle, (C++ Report, Aug 1996)
[Martin96e] (1, 2, 3, 4) Robert C. Martin, Granularity, (C++ Report, Nov-Dec 1996)
[Martin97] (1, 2) Robert C. Martin, Stability, (C++ Report, Feb, 1997)
[Martin03] Robert C. Martin, Agile software development: principles, patterns, and pactices, (Prentice Hall, 2003, ISBN 0-13-597444-5)
[ObjectMentor] Object Mentor Publications, http://www.objectmentor.com/resources/publishedArticles.html, 14.4.2013
[c2com] Principles Of Object Oriented Design, http://c2.com/cgi/wiki?PrinciplesOfObjectOrientedDesign, 14.4.2013

Ystävällisin terveisin

Timo Kankare

PS. Keräsin tällaisen listan ohjelmointiperiaatteista joskus aikoinani vanhoille sivuilleni lähinnä omiksi muistiinpanoikseni. Täydensin tähän listaan nyt SRP:n ja ryhmittelin niitä (SOLID, Cohesion ja Coupling).

Kommentit