Contracts.

Introduction.

Design by Contract is the Software Collaboration Method.

Contract / between class user and class author / should state under which condition class will provide it's services to class user, and what these services are.


Contract.

There are Preconditions, Postconditions and Invariants that regulate contract.

Precondition is a condition that is required for something to happen. Precondition can be simple or complex, complex precondition consists of multiple simple or complex preconditions as well.

Postcondition is something that is guaranteed to happen if preconditions are met & program behaves correctly.

Invariants is something that is guaranteed to hold, at least in observable moments in time, or perhaps even all the time.


If class user provides 'correct' / or using alternative wording: 'legal' / preconditions to object, methods will ensure that postconditions are met.

Invariants are always met / though some disagree, for there's 'observable moment' argument /, or contract is broken.


Examples for Preconditions:

- requirements for method arguments allowed values,
- concurrency requirements,
- perhaps more.


Examples for Postconditions:

- program's process(-es) will compute and provide results correctly,
- program will finish within the agreed time frame in at least 90% of situations,
- perhaps more.


Examples for Invariants:

- heat in Reactor will never go above the Critical Value,
- variable 'divisor' will never have '0' value,
- variable 'divisor' will never have '0' value during computations phase,
- perhaps more.


Inheritance / in simple words /.

To not break contract, following conditions must be met:

1. subclasses must require no more than it's neccessary for superclass to work correctly / but can require less /.

2. subclasses must meet all requirements of superclass / but perhaps can give more /.

This is related with the Liskov's Substitution Principle / LSP /.


Exceptions in Java.

When contract is broken during Runtime, an Exception should be thrown.

Software Development & Quality.

Introduction.

There are many methods for ensuring that software development proceeds smoothly, and there are methods for ensuring and measuring software artifacts' quality.

Artifacts are documents:
- design model,
- application code,
- automated tests code,
- documentation,
- configuration files,
- resource files as art or other data,
- ...


Code's Quality.

For a code quality's practices, see if You wish:
- A few thoughts on code quality...


Teamwork vs. Showoff.

Teamwork is Professional, needless showoff is NOT Professional.

Code should be written & documented in a simple way, so other co-workers can understand it with ease.

This friendly approach - of making teamwork easier helps the most newcomers - either beginner programmers, or programmers who worked with different Programming Language(s), Tools, Ecosystem, Technology(-ies).


Automated Testing.

For automated testing article, see if You wish:
- Automated Tests.


Design & Modelling.

Software models, often presented in a graphical way, are tools to look at software's design from a 'bird's view', to grasp whole picture.

Software modelling and design's goal is to abstract & simplify project.

Designs should be as simple and as abstract as possible - as this allows for easier code modifications as reality and customer's needs change.

... but of course modelling a single object with name 'idea' is too unreasonable interpretation of above words.

There are 'views' of a model as well - each view serves a purpose - each of views is a transformed model, both reduced and filled with details, to emphasize it's purpose.

For example we can have model consisting of every of car's parts, then we can produce a view of engine - fuel interaction. Unneccessary parts for this view are omitted, and more details about heat, and other aspects can be provided in view's documentation.

Models and views can be more or less exhaustive and detailed, and always should be unambiguous.