début du cours d'algorithmique pour le CESI
This commit is contained in:
gwen
parent
d7a4bcc466
commit
9cbe2e337a
|
|
@ -0,0 +1,216 @@
|
||||||
|
# Makefile for Sphinx documentation
|
||||||
|
#
|
||||||
|
|
||||||
|
# You can set these variables from the command line.
|
||||||
|
SPHINXOPTS =
|
||||||
|
SPHINXBUILD = sphinx-build
|
||||||
|
PAPER =
|
||||||
|
BUILDDIR = _build
|
||||||
|
|
||||||
|
# User-friendly check for sphinx-build
|
||||||
|
ifeq ($(shell which $(SPHINXBUILD) >/dev/null 2>&1; echo $$?), 1)
|
||||||
|
$(error The '$(SPHINXBUILD)' command was not found. Make sure you have Sphinx installed, then set the SPHINXBUILD environment variable to point to the full path of the '$(SPHINXBUILD)' executable. Alternatively you can add the directory with the executable to your PATH. If you don't have Sphinx installed, grab it from http://sphinx-doc.org/)
|
||||||
|
endif
|
||||||
|
|
||||||
|
# Internal variables.
|
||||||
|
PAPEROPT_a4 = -D latex_paper_size=a4
|
||||||
|
PAPEROPT_letter = -D latex_paper_size=letter
|
||||||
|
ALLSPHINXOPTS = -d $(BUILDDIR)/doctrees $(PAPEROPT_$(PAPER)) $(SPHINXOPTS) .
|
||||||
|
# the i18n builder cannot share the environment and doctrees with the others
|
||||||
|
I18NSPHINXOPTS = $(PAPEROPT_$(PAPER)) $(SPHINXOPTS) .
|
||||||
|
|
||||||
|
.PHONY: help
|
||||||
|
help:
|
||||||
|
@echo "Please use \`make <target>' where <target> is one of"
|
||||||
|
@echo " html to make standalone HTML files"
|
||||||
|
@echo " dirhtml to make HTML files named index.html in directories"
|
||||||
|
@echo " singlehtml to make a single large HTML file"
|
||||||
|
@echo " pickle to make pickle files"
|
||||||
|
@echo " json to make JSON files"
|
||||||
|
@echo " htmlhelp to make HTML files and a HTML help project"
|
||||||
|
@echo " qthelp to make HTML files and a qthelp project"
|
||||||
|
@echo " applehelp to make an Apple Help Book"
|
||||||
|
@echo " devhelp to make HTML files and a Devhelp project"
|
||||||
|
@echo " epub to make an epub"
|
||||||
|
@echo " latex to make LaTeX files, you can set PAPER=a4 or PAPER=letter"
|
||||||
|
@echo " latexpdf to make LaTeX files and run them through pdflatex"
|
||||||
|
@echo " latexpdfja to make LaTeX files and run them through platex/dvipdfmx"
|
||||||
|
@echo " text to make text files"
|
||||||
|
@echo " man to make manual pages"
|
||||||
|
@echo " texinfo to make Texinfo files"
|
||||||
|
@echo " info to make Texinfo files and run them through makeinfo"
|
||||||
|
@echo " gettext to make PO message catalogs"
|
||||||
|
@echo " changes to make an overview of all changed/added/deprecated items"
|
||||||
|
@echo " xml to make Docutils-native XML files"
|
||||||
|
@echo " pseudoxml to make pseudoxml-XML files for display purposes"
|
||||||
|
@echo " linkcheck to check all external links for integrity"
|
||||||
|
@echo " doctest to run all doctests embedded in the documentation (if enabled)"
|
||||||
|
@echo " coverage to run coverage check of the documentation (if enabled)"
|
||||||
|
|
||||||
|
.PHONY: clean
|
||||||
|
clean:
|
||||||
|
rm -rf $(BUILDDIR)/*
|
||||||
|
|
||||||
|
.PHONY: html
|
||||||
|
html:
|
||||||
|
$(SPHINXBUILD) -b html $(ALLSPHINXOPTS) $(BUILDDIR)/html
|
||||||
|
@echo
|
||||||
|
@echo "Build finished. The HTML pages are in $(BUILDDIR)/html."
|
||||||
|
|
||||||
|
.PHONY: dirhtml
|
||||||
|
dirhtml:
|
||||||
|
$(SPHINXBUILD) -b dirhtml $(ALLSPHINXOPTS) $(BUILDDIR)/dirhtml
|
||||||
|
@echo
|
||||||
|
@echo "Build finished. The HTML pages are in $(BUILDDIR)/dirhtml."
|
||||||
|
|
||||||
|
.PHONY: singlehtml
|
||||||
|
singlehtml:
|
||||||
|
$(SPHINXBUILD) -b singlehtml $(ALLSPHINXOPTS) $(BUILDDIR)/singlehtml
|
||||||
|
@echo
|
||||||
|
@echo "Build finished. The HTML page is in $(BUILDDIR)/singlehtml."
|
||||||
|
|
||||||
|
.PHONY: pickle
|
||||||
|
pickle:
|
||||||
|
$(SPHINXBUILD) -b pickle $(ALLSPHINXOPTS) $(BUILDDIR)/pickle
|
||||||
|
@echo
|
||||||
|
@echo "Build finished; now you can process the pickle files."
|
||||||
|
|
||||||
|
.PHONY: json
|
||||||
|
json:
|
||||||
|
$(SPHINXBUILD) -b json $(ALLSPHINXOPTS) $(BUILDDIR)/json
|
||||||
|
@echo
|
||||||
|
@echo "Build finished; now you can process the JSON files."
|
||||||
|
|
||||||
|
.PHONY: htmlhelp
|
||||||
|
htmlhelp:
|
||||||
|
$(SPHINXBUILD) -b htmlhelp $(ALLSPHINXOPTS) $(BUILDDIR)/htmlhelp
|
||||||
|
@echo
|
||||||
|
@echo "Build finished; now you can run HTML Help Workshop with the" \
|
||||||
|
".hhp project file in $(BUILDDIR)/htmlhelp."
|
||||||
|
|
||||||
|
.PHONY: qthelp
|
||||||
|
qthelp:
|
||||||
|
$(SPHINXBUILD) -b qthelp $(ALLSPHINXOPTS) $(BUILDDIR)/qthelp
|
||||||
|
@echo
|
||||||
|
@echo "Build finished; now you can run "qcollectiongenerator" with the" \
|
||||||
|
".qhcp project file in $(BUILDDIR)/qthelp, like this:"
|
||||||
|
@echo "# qcollectiongenerator $(BUILDDIR)/qthelp/Algorithmique.qhcp"
|
||||||
|
@echo "To view the help file:"
|
||||||
|
@echo "# assistant -collectionFile $(BUILDDIR)/qthelp/Algorithmique.qhc"
|
||||||
|
|
||||||
|
.PHONY: applehelp
|
||||||
|
applehelp:
|
||||||
|
$(SPHINXBUILD) -b applehelp $(ALLSPHINXOPTS) $(BUILDDIR)/applehelp
|
||||||
|
@echo
|
||||||
|
@echo "Build finished. The help book is in $(BUILDDIR)/applehelp."
|
||||||
|
@echo "N.B. You won't be able to view it unless you put it in" \
|
||||||
|
"~/Library/Documentation/Help or install it in your application" \
|
||||||
|
"bundle."
|
||||||
|
|
||||||
|
.PHONY: devhelp
|
||||||
|
devhelp:
|
||||||
|
$(SPHINXBUILD) -b devhelp $(ALLSPHINXOPTS) $(BUILDDIR)/devhelp
|
||||||
|
@echo
|
||||||
|
@echo "Build finished."
|
||||||
|
@echo "To view the help file:"
|
||||||
|
@echo "# mkdir -p $$HOME/.local/share/devhelp/Algorithmique"
|
||||||
|
@echo "# ln -s $(BUILDDIR)/devhelp $$HOME/.local/share/devhelp/Algorithmique"
|
||||||
|
@echo "# devhelp"
|
||||||
|
|
||||||
|
.PHONY: epub
|
||||||
|
epub:
|
||||||
|
$(SPHINXBUILD) -b epub $(ALLSPHINXOPTS) $(BUILDDIR)/epub
|
||||||
|
@echo
|
||||||
|
@echo "Build finished. The epub file is in $(BUILDDIR)/epub."
|
||||||
|
|
||||||
|
.PHONY: latex
|
||||||
|
latex:
|
||||||
|
$(SPHINXBUILD) -b latex $(ALLSPHINXOPTS) $(BUILDDIR)/latex
|
||||||
|
@echo
|
||||||
|
@echo "Build finished; the LaTeX files are in $(BUILDDIR)/latex."
|
||||||
|
@echo "Run \`make' in that directory to run these through (pdf)latex" \
|
||||||
|
"(use \`make latexpdf' here to do that automatically)."
|
||||||
|
|
||||||
|
.PHONY: latexpdf
|
||||||
|
latexpdf:
|
||||||
|
$(SPHINXBUILD) -b latex $(ALLSPHINXOPTS) $(BUILDDIR)/latex
|
||||||
|
@echo "Running LaTeX files through pdflatex..."
|
||||||
|
$(MAKE) -C $(BUILDDIR)/latex all-pdf
|
||||||
|
@echo "pdflatex finished; the PDF files are in $(BUILDDIR)/latex."
|
||||||
|
|
||||||
|
.PHONY: latexpdfja
|
||||||
|
latexpdfja:
|
||||||
|
$(SPHINXBUILD) -b latex $(ALLSPHINXOPTS) $(BUILDDIR)/latex
|
||||||
|
@echo "Running LaTeX files through platex and dvipdfmx..."
|
||||||
|
$(MAKE) -C $(BUILDDIR)/latex all-pdf-ja
|
||||||
|
@echo "pdflatex finished; the PDF files are in $(BUILDDIR)/latex."
|
||||||
|
|
||||||
|
.PHONY: text
|
||||||
|
text:
|
||||||
|
$(SPHINXBUILD) -b text $(ALLSPHINXOPTS) $(BUILDDIR)/text
|
||||||
|
@echo
|
||||||
|
@echo "Build finished. The text files are in $(BUILDDIR)/text."
|
||||||
|
|
||||||
|
.PHONY: man
|
||||||
|
man:
|
||||||
|
$(SPHINXBUILD) -b man $(ALLSPHINXOPTS) $(BUILDDIR)/man
|
||||||
|
@echo
|
||||||
|
@echo "Build finished. The manual pages are in $(BUILDDIR)/man."
|
||||||
|
|
||||||
|
.PHONY: texinfo
|
||||||
|
texinfo:
|
||||||
|
$(SPHINXBUILD) -b texinfo $(ALLSPHINXOPTS) $(BUILDDIR)/texinfo
|
||||||
|
@echo
|
||||||
|
@echo "Build finished. The Texinfo files are in $(BUILDDIR)/texinfo."
|
||||||
|
@echo "Run \`make' in that directory to run these through makeinfo" \
|
||||||
|
"(use \`make info' here to do that automatically)."
|
||||||
|
|
||||||
|
.PHONY: info
|
||||||
|
info:
|
||||||
|
$(SPHINXBUILD) -b texinfo $(ALLSPHINXOPTS) $(BUILDDIR)/texinfo
|
||||||
|
@echo "Running Texinfo files through makeinfo..."
|
||||||
|
make -C $(BUILDDIR)/texinfo info
|
||||||
|
@echo "makeinfo finished; the Info files are in $(BUILDDIR)/texinfo."
|
||||||
|
|
||||||
|
.PHONY: gettext
|
||||||
|
gettext:
|
||||||
|
$(SPHINXBUILD) -b gettext $(I18NSPHINXOPTS) $(BUILDDIR)/locale
|
||||||
|
@echo
|
||||||
|
@echo "Build finished. The message catalogs are in $(BUILDDIR)/locale."
|
||||||
|
|
||||||
|
.PHONY: changes
|
||||||
|
changes:
|
||||||
|
$(SPHINXBUILD) -b changes $(ALLSPHINXOPTS) $(BUILDDIR)/changes
|
||||||
|
@echo
|
||||||
|
@echo "The overview file is in $(BUILDDIR)/changes."
|
||||||
|
|
||||||
|
.PHONY: linkcheck
|
||||||
|
linkcheck:
|
||||||
|
$(SPHINXBUILD) -b linkcheck $(ALLSPHINXOPTS) $(BUILDDIR)/linkcheck
|
||||||
|
@echo
|
||||||
|
@echo "Link check complete; look for any errors in the above output " \
|
||||||
|
"or in $(BUILDDIR)/linkcheck/output.txt."
|
||||||
|
|
||||||
|
.PHONY: doctest
|
||||||
|
doctest:
|
||||||
|
$(SPHINXBUILD) -b doctest $(ALLSPHINXOPTS) $(BUILDDIR)/doctest
|
||||||
|
@echo "Testing of doctests in the sources finished, look at the " \
|
||||||
|
"results in $(BUILDDIR)/doctest/output.txt."
|
||||||
|
|
||||||
|
.PHONY: coverage
|
||||||
|
coverage:
|
||||||
|
$(SPHINXBUILD) -b coverage $(ALLSPHINXOPTS) $(BUILDDIR)/coverage
|
||||||
|
@echo "Testing of coverage in the sources finished, look at the " \
|
||||||
|
"results in $(BUILDDIR)/coverage/python.txt."
|
||||||
|
|
||||||
|
.PHONY: xml
|
||||||
|
xml:
|
||||||
|
$(SPHINXBUILD) -b xml $(ALLSPHINXOPTS) $(BUILDDIR)/xml
|
||||||
|
@echo
|
||||||
|
@echo "Build finished. The XML files are in $(BUILDDIR)/xml."
|
||||||
|
|
||||||
|
.PHONY: pseudoxml
|
||||||
|
pseudoxml:
|
||||||
|
$(SPHINXBUILD) -b pseudoxml $(ALLSPHINXOPTS) $(BUILDDIR)/pseudoxml
|
||||||
|
@echo
|
||||||
|
@echo "Build finished. The pseudo-XML files are in $(BUILDDIR)/pseudoxml."
|
||||||
Binary file not shown.
|
After Width: | Height: | Size: 59 KiB |
|
|
@ -0,0 +1,355 @@
|
||||||
|
# -*- coding: utf-8 -*-
|
||||||
|
#
|
||||||
|
# Algorithmique documentation build configuration file, created by
|
||||||
|
# sphinx-quickstart on Thu Mar 16 16:07:00 2017.
|
||||||
|
#
|
||||||
|
# This file is execfile()d with the current directory set to its
|
||||||
|
# containing dir.
|
||||||
|
#
|
||||||
|
# Note that not all possible configuration values are present in this
|
||||||
|
# autogenerated file.
|
||||||
|
#
|
||||||
|
# All configuration values have a default; values that are commented out
|
||||||
|
# serve to show the default.
|
||||||
|
|
||||||
|
import sys
|
||||||
|
import os
|
||||||
|
|
||||||
|
# If extensions (or modules to document with autodoc) are in another directory,
|
||||||
|
# add these directories to sys.path here. If the directory is relative to the
|
||||||
|
# documentation root, use os.path.abspath to make it absolute, like shown here.
|
||||||
|
#sys.path.insert(0, os.path.abspath('.'))
|
||||||
|
|
||||||
|
# -- General configuration ------------------------------------------------
|
||||||
|
|
||||||
|
# If your documentation needs a minimal Sphinx version, state it here.
|
||||||
|
#needs_sphinx = '1.0'
|
||||||
|
|
||||||
|
# Add any Sphinx extension module names here, as strings. They can be
|
||||||
|
# extensions coming with Sphinx (named 'sphinx.ext.*') or your custom
|
||||||
|
# ones.
|
||||||
|
extensions = [
|
||||||
|
'sphinx.ext.pngmath',
|
||||||
|
]
|
||||||
|
|
||||||
|
# Add any paths that contain templates here, relative to this directory.
|
||||||
|
templates_path = ['_templates']
|
||||||
|
|
||||||
|
# The suffix(es) of source filenames.
|
||||||
|
# You can specify multiple suffix as a list of string:
|
||||||
|
# source_suffix = ['.rst', '.md']
|
||||||
|
source_suffix = '.txt'
|
||||||
|
|
||||||
|
# The encoding of source files.
|
||||||
|
#source_encoding = 'utf-8-sig'
|
||||||
|
|
||||||
|
# The master toctree document.
|
||||||
|
master_doc = 'index'
|
||||||
|
|
||||||
|
# General information about the project.
|
||||||
|
project = u'Algorithmique'
|
||||||
|
copyright = u'2017, Gwen'
|
||||||
|
author = u'Gwen'
|
||||||
|
|
||||||
|
# The version info for the project you're documenting, acts as replacement for
|
||||||
|
# |version| and |release|, also used in various other places throughout the
|
||||||
|
# built documents.
|
||||||
|
#
|
||||||
|
# The short X.Y version.
|
||||||
|
version = u'1'
|
||||||
|
# The full version, including alpha/beta/rc tags.
|
||||||
|
release = u'1'
|
||||||
|
|
||||||
|
# The language for content autogenerated by Sphinx. Refer to documentation
|
||||||
|
# for a list of supported languages.
|
||||||
|
#
|
||||||
|
# This is also used if you do content translation via gettext catalogs.
|
||||||
|
# Usually you set "language" from the command line for these cases.
|
||||||
|
language = 'fr'
|
||||||
|
|
||||||
|
# There are two options for replacing |today|: either, you set today to some
|
||||||
|
# non-false value, then it is used:
|
||||||
|
#today = ''
|
||||||
|
# Else, today_fmt is used as the format for a strftime call.
|
||||||
|
#today_fmt = '%B %d, %Y'
|
||||||
|
|
||||||
|
# List of patterns, relative to source directory, that match files and
|
||||||
|
# directories to ignore when looking for source files.
|
||||||
|
exclude_patterns = ['_build']
|
||||||
|
|
||||||
|
# The reST default role (used for this markup: `text`) to use for all
|
||||||
|
# documents.
|
||||||
|
default_role = 'literal'
|
||||||
|
|
||||||
|
# If true, '()' will be appended to :func: etc. cross-reference text.
|
||||||
|
#add_function_parentheses = True
|
||||||
|
|
||||||
|
# If true, the current module name will be prepended to all description
|
||||||
|
# unit titles (such as .. function::).
|
||||||
|
#add_module_names = True
|
||||||
|
|
||||||
|
# If true, sectionauthor and moduleauthor directives will be shown in the
|
||||||
|
# output. They are ignored by default.
|
||||||
|
#show_authors = False
|
||||||
|
|
||||||
|
# The name of the Pygments (syntax highlighting) style to use.
|
||||||
|
pygments_style = 'sphinx'
|
||||||
|
|
||||||
|
# A list of ignored prefixes for module index sorting.
|
||||||
|
#modindex_common_prefix = []
|
||||||
|
|
||||||
|
# If true, keep warnings as "system message" paragraphs in the built documents.
|
||||||
|
#keep_warnings = False
|
||||||
|
|
||||||
|
# If true, `todo` and `todoList` produce output, else they produce nothing.
|
||||||
|
todo_include_todos = False
|
||||||
|
|
||||||
|
|
||||||
|
# -- Options for HTML output ----------------------------------------------
|
||||||
|
|
||||||
|
# The theme to use for HTML and HTML Help pages. See the documentation for
|
||||||
|
# a list of builtin themes.
|
||||||
|
html_theme = 'alabaster'
|
||||||
|
|
||||||
|
# Theme options are theme-specific and customize the look and feel of a theme
|
||||||
|
# further. For a list of options available for each theme, see the
|
||||||
|
# documentation.
|
||||||
|
#html_theme_options = {}
|
||||||
|
|
||||||
|
# Add any paths that contain custom themes here, relative to this directory.
|
||||||
|
#html_theme_path = []
|
||||||
|
|
||||||
|
# The name for this set of Sphinx documents. If None, it defaults to
|
||||||
|
# "<project> v<release> documentation".
|
||||||
|
#html_title = None
|
||||||
|
|
||||||
|
# A shorter title for the navigation bar. Default is the same as html_title.
|
||||||
|
#html_short_title = None
|
||||||
|
|
||||||
|
# The name of an image file (relative to this directory) to place at the top
|
||||||
|
# of the sidebar.
|
||||||
|
#html_logo = None
|
||||||
|
|
||||||
|
# The name of an image file (relative to this directory) to use as a favicon of
|
||||||
|
# the docs. This file should be a Windows icon file (.ico) being 16x16 or 32x32
|
||||||
|
# pixels large.
|
||||||
|
#html_favicon = None
|
||||||
|
|
||||||
|
# Add any paths that contain custom static files (such as style sheets) here,
|
||||||
|
# relative to this directory. They are copied after the builtin static files,
|
||||||
|
# so a file named "default.css" will overwrite the builtin "default.css".
|
||||||
|
html_static_path = ['_static']
|
||||||
|
|
||||||
|
# Add any extra paths that contain custom files (such as robots.txt or
|
||||||
|
# .htaccess) here, relative to this directory. These files are copied
|
||||||
|
# directly to the root of the documentation.
|
||||||
|
#html_extra_path = []
|
||||||
|
|
||||||
|
# If not '', a 'Last updated on:' timestamp is inserted at every page bottom,
|
||||||
|
# using the given strftime format.
|
||||||
|
#html_last_updated_fmt = '%b %d, %Y'
|
||||||
|
|
||||||
|
# If true, SmartyPants will be used to convert quotes and dashes to
|
||||||
|
# typographically correct entities.
|
||||||
|
#html_use_smartypants = True
|
||||||
|
|
||||||
|
# Custom sidebar templates, maps document names to template names.
|
||||||
|
#html_sidebars = {}
|
||||||
|
|
||||||
|
# Additional templates that should be rendered to pages, maps page names to
|
||||||
|
# template names.
|
||||||
|
#html_additional_pages = {}
|
||||||
|
|
||||||
|
# If false, no module index is generated.
|
||||||
|
#html_domain_indices = True
|
||||||
|
|
||||||
|
# If false, no index is generated.
|
||||||
|
#html_use_index = True
|
||||||
|
|
||||||
|
# If true, the index is split into individual pages for each letter.
|
||||||
|
#html_split_index = False
|
||||||
|
|
||||||
|
# If true, links to the reST sources are added to the pages.
|
||||||
|
#html_show_sourcelink = True
|
||||||
|
|
||||||
|
# If true, "Created using Sphinx" is shown in the HTML footer. Default is True.
|
||||||
|
html_show_sphinx = False
|
||||||
|
|
||||||
|
# If true, "(C) Copyright ..." is shown in the HTML footer. Default is True.
|
||||||
|
html_show_copyright = False
|
||||||
|
|
||||||
|
# If true, an OpenSearch description file will be output, and all pages will
|
||||||
|
# contain a <link> tag referring to it. The value of this option must be the
|
||||||
|
# base URL from which the finished HTML is served.
|
||||||
|
#html_use_opensearch = ''
|
||||||
|
|
||||||
|
# This is the file name suffix for HTML files (e.g. ".xhtml").
|
||||||
|
#html_file_suffix = None
|
||||||
|
|
||||||
|
# Language to be used for generating the HTML full-text search index.
|
||||||
|
# Sphinx supports the following languages:
|
||||||
|
# 'da', 'de', 'en', 'es', 'fi', 'fr', 'hu', 'it', 'ja'
|
||||||
|
# 'nl', 'no', 'pt', 'ro', 'ru', 'sv', 'tr'
|
||||||
|
#html_search_language = 'en'
|
||||||
|
|
||||||
|
# A dictionary with options for the search language support, empty by default.
|
||||||
|
# Now only 'ja' uses this config value
|
||||||
|
#html_search_options = {'type': 'default'}
|
||||||
|
|
||||||
|
# The name of a javascript file (relative to the configuration directory) that
|
||||||
|
# implements a search results scorer. If empty, the default will be used.
|
||||||
|
#html_search_scorer = 'scorer.js'
|
||||||
|
|
||||||
|
# Output file base name for HTML help builder.
|
||||||
|
htmlhelp_basename = 'Algorithmiquedoc'
|
||||||
|
|
||||||
|
# -- Options for LaTeX output ---------------------------------------------
|
||||||
|
|
||||||
|
latex_elements = {
|
||||||
|
# The paper size ('letterpaper' or 'a4paper').
|
||||||
|
'papersize': 'a4paper',
|
||||||
|
|
||||||
|
# The font size ('10pt', '11pt' or '12pt').
|
||||||
|
#'pointsize': '10pt',
|
||||||
|
|
||||||
|
# Additional stuff for the LaTeX preamble.
|
||||||
|
#'preamble': '',
|
||||||
|
|
||||||
|
# Latex figure (float) alignment
|
||||||
|
#'figure_align': 'htbp',
|
||||||
|
}
|
||||||
|
|
||||||
|
# Grouping the document tree into LaTeX files. List of tuples
|
||||||
|
# (source start file, target name, title,
|
||||||
|
# author, documentclass [howto, manual, or own class]).
|
||||||
|
latex_documents = [
|
||||||
|
(master_doc, 'Algorithmique.tex', u'Cours d\'algorithmique',
|
||||||
|
u'promotion GMSI B3', 'manual'),
|
||||||
|
]
|
||||||
|
|
||||||
|
# The name of an image file (relative to this directory) to place at the top of
|
||||||
|
# the title page.
|
||||||
|
latex_logo = '_static/cesi.jpg'
|
||||||
|
|
||||||
|
# For "manual" documents, if this is true, then toplevel headings are parts,
|
||||||
|
# not chapters.
|
||||||
|
latex_use_parts = True
|
||||||
|
|
||||||
|
# If true, show page references after internal links.
|
||||||
|
#latex_show_pagerefs = False
|
||||||
|
|
||||||
|
# If true, show URL addresses after external links.
|
||||||
|
#latex_show_urls = False
|
||||||
|
|
||||||
|
# Documents to append as an appendix to all manuals.
|
||||||
|
#latex_appendices = []
|
||||||
|
|
||||||
|
# If false, no module index is generated.
|
||||||
|
#latex_domain_indices = False
|
||||||
|
|
||||||
|
|
||||||
|
# -- Options for manual page output ---------------------------------------
|
||||||
|
|
||||||
|
# One entry per manual page. List of tuples
|
||||||
|
# (source start file, name, description, authors, manual section).
|
||||||
|
man_pages = [
|
||||||
|
(master_doc, 'algorithmique', u'Algorithmique Documentation',
|
||||||
|
[author], 1)
|
||||||
|
]
|
||||||
|
|
||||||
|
# If true, show URL addresses after external links.
|
||||||
|
#man_show_urls = False
|
||||||
|
|
||||||
|
|
||||||
|
# -- Options for Texinfo output -------------------------------------------
|
||||||
|
|
||||||
|
# Grouping the document tree into Texinfo files. List of tuples
|
||||||
|
# (source start file, target name, title, author,
|
||||||
|
# dir menu entry, description, category)
|
||||||
|
texinfo_documents = [
|
||||||
|
(master_doc, 'Algorithmique', u'Algorithmique Documentation',
|
||||||
|
author, 'Algorithmique', 'One line description of project.',
|
||||||
|
'Miscellaneous'),
|
||||||
|
]
|
||||||
|
|
||||||
|
# Documents to append as an appendix to all manuals.
|
||||||
|
#texinfo_appendices = []
|
||||||
|
|
||||||
|
# If false, no module index is generated.
|
||||||
|
#texinfo_domain_indices = True
|
||||||
|
|
||||||
|
# How to display URL addresses: 'footnote', 'no', or 'inline'.
|
||||||
|
#texinfo_show_urls = 'footnote'
|
||||||
|
|
||||||
|
# If true, do not generate a @detailmenu in the "Top" node's menu.
|
||||||
|
#texinfo_no_detailmenu = False
|
||||||
|
|
||||||
|
|
||||||
|
# -- Options for Epub output ----------------------------------------------
|
||||||
|
|
||||||
|
# Bibliographic Dublin Core info.
|
||||||
|
epub_title = project
|
||||||
|
epub_author = author
|
||||||
|
epub_publisher = author
|
||||||
|
epub_copyright = copyright
|
||||||
|
|
||||||
|
# The basename for the epub file. It defaults to the project name.
|
||||||
|
#epub_basename = project
|
||||||
|
|
||||||
|
# The HTML theme for the epub output. Since the default themes are not
|
||||||
|
# optimized for small screen space, using the same theme for HTML and epub
|
||||||
|
# output is usually not wise. This defaults to 'epub', a theme designed to save
|
||||||
|
# visual space.
|
||||||
|
#epub_theme = 'epub'
|
||||||
|
|
||||||
|
# The language of the text. It defaults to the language option
|
||||||
|
# or 'en' if the language is not set.
|
||||||
|
#epub_language = ''
|
||||||
|
|
||||||
|
# The scheme of the identifier. Typical schemes are ISBN or URL.
|
||||||
|
#epub_scheme = ''
|
||||||
|
|
||||||
|
# The unique identifier of the text. This can be a ISBN number
|
||||||
|
# or the project homepage.
|
||||||
|
#epub_identifier = ''
|
||||||
|
|
||||||
|
# A unique identification for the text.
|
||||||
|
#epub_uid = ''
|
||||||
|
|
||||||
|
# A tuple containing the cover image and cover page html template filenames.
|
||||||
|
#epub_cover = ()
|
||||||
|
|
||||||
|
# A sequence of (type, uri, title) tuples for the guide element of content.opf.
|
||||||
|
#epub_guide = ()
|
||||||
|
|
||||||
|
# HTML files that should be inserted before the pages created by sphinx.
|
||||||
|
# The format is a list of tuples containing the path and title.
|
||||||
|
#epub_pre_files = []
|
||||||
|
|
||||||
|
# HTML files that should be inserted after the pages created by sphinx.
|
||||||
|
# The format is a list of tuples containing the path and title.
|
||||||
|
#epub_post_files = []
|
||||||
|
|
||||||
|
# A list of files that should not be packed into the epub file.
|
||||||
|
epub_exclude_files = ['search.html']
|
||||||
|
|
||||||
|
# The depth of the table of contents in toc.ncx.
|
||||||
|
#epub_tocdepth = 3
|
||||||
|
|
||||||
|
# Allow duplicate toc entries.
|
||||||
|
#epub_tocdup = True
|
||||||
|
|
||||||
|
# Choose between 'default' and 'includehidden'.
|
||||||
|
#epub_tocscope = 'default'
|
||||||
|
|
||||||
|
# Fix unsupported image types using the Pillow.
|
||||||
|
#epub_fix_images = False
|
||||||
|
|
||||||
|
# Scale large images.
|
||||||
|
#epub_max_image_width = 0
|
||||||
|
|
||||||
|
# How to display URL addresses: 'footnote', 'no', or 'inline'.
|
||||||
|
#epub_show_urls = 'inline'
|
||||||
|
|
||||||
|
# If false, no index is generated.
|
||||||
|
#epub_use_index = True
|
||||||
|
|
@ -0,0 +1,99 @@
|
||||||
|
Présentation de l'art de programmer
|
||||||
|
====================================
|
||||||
|
|
||||||
|
Le processus d'abstraction
|
||||||
|
--------------------------
|
||||||
|
|
||||||
|
Débuter en programmation n'est pas une chose aisée. Aujourd'hui, la tendance est au
|
||||||
|
"bas niveau". Souvent, on se jette dans le grand bain :
|
||||||
|
|
||||||
|
- soit en s'approchant au maximum de la machine (admin système et réseau, noyau
|
||||||
|
linux, langage C)
|
||||||
|
|
||||||
|
- soit en faisant du dev web côté backend, ce qui ramène à une administration réseau
|
||||||
|
de bas niveau (microservices, monde nodeJS/javascript, etc...)
|
||||||
|
|
||||||
|
Soit on suit un cursus scolaire traditionnel qui commence souvent par une
|
||||||
|
explication du fonctionnement d'une machine abstraite de bas niveau, puis en
|
||||||
|
allant de plus en plus haut, mais étant sous-entendu qu'il faut rester connecté au
|
||||||
|
bas niveau (comprendre comment ça se passe derrière la scène).
|
||||||
|
|
||||||
|
Dans ces deux cas, il est sous-entendu qu'on apprend plus de choses et plus
|
||||||
|
rapidement en mettant les mains dans le cambouis, ce qui vrai bien sûr. Mais cela
|
||||||
|
sous-entend qu'un développeur doit rester le nez dans le guidon, ou au moins qu'il
|
||||||
|
se doit d'être un expert du système dans lequel il évolue (connaissance du système
|
||||||
|
d'exploitation, binding avec le C, du ramasse miette (garbage collector),
|
||||||
|
interaction avec les différentes librairies, gestion et optimisation de la mémoire,
|
||||||
|
architecture par microservices, threads...)
|
||||||
|
|
||||||
|
L'approche algorithmique consiste en exactement le contraire : elle commence par se
|
||||||
|
placer du côté de l'esprit humain et de ses capacités de compréhension et
|
||||||
|
d'abstraction.
|
||||||
|
|
||||||
|
Le lien est fait ensuite avec le plus bas niveau grâce une implémentation effective
|
||||||
|
des langages à partir des paradigmes de rationalisation de la penseée (modules,
|
||||||
|
objects, généricité, polymorphisme paramétrique...) et d'un outil de communication
|
||||||
|
avec la machine qu'on appelle compilateur (dont la description est en dehors de
|
||||||
|
l'objectif de ce cours).
|
||||||
|
|
||||||
|
La tendance générale de l'évolution des languages est de se libérer de ces
|
||||||
|
contraintes de bas niveau, un peu comme en sciences physiques où les lois physiques
|
||||||
|
dépendent de l'échelle d'en dessous (du niveau microscopique/quantique) mais qu'à
|
||||||
|
l'échelle du dessus, on n'a pas affaire à des effets de bas niveau (pas d'effets
|
||||||
|
quantiques à un niveau macroscopique en général). Ce processus d'évolution est vrai
|
||||||
|
aussi dans le monde de la technique informatique lui-même (modèle OSI, comment est
|
||||||
|
construite une trame IP, indépendances de chaque couche (transport, payload) entre
|
||||||
|
elles). Même la tendance système est à la virtualisation qui accentue encore la
|
||||||
|
tendance à s'affranchir du bas niveau (le niveau système), le séparer nettement du
|
||||||
|
haut niveau (le niveau applicatif).
|
||||||
|
|
||||||
|
Il apparaît régulièrement de nouveaux langages. Comment s'orienter ? Quel(s)
|
||||||
|
langage(s) choisir pour un projet de développement ? Au delà de leurs disparités, la
|
||||||
|
conception et la genèse de chacun d'eux procèdent d'une motivation partagée : la
|
||||||
|
volonté d'abstraire.
|
||||||
|
|
||||||
|
- **s'abstraire de la machine** : un langage de programmation permet de
|
||||||
|
négliger l'aspect *mécanique* de l'ordinateur. On oublie le modèle du
|
||||||
|
microprocesseur, jusqu'au système d'exploitation sur lequel sera exécuté
|
||||||
|
le programme.
|
||||||
|
|
||||||
|
- **abstraire les erreurs** : Il s'agit ici de garantir la sûreté d'exécution; un
|
||||||
|
programme ne doit pas se terminer brutalement ou devenir incohérent en cas d'erreur.
|
||||||
|
Un des moyens pour y parvenir est le typage des programmes et la mise
|
||||||
|
en oeuvre d'un mécanisme d'exceptions.
|
||||||
|
|
||||||
|
- **abstraire le mode opératoire** : Il s'agit de choisir une représentation, un
|
||||||
|
paradigme d'implémentation qui est indépendant du domaine considéré (paradigme
|
||||||
|
objet, modulaire, générique, composants...)
|
||||||
|
|
||||||
|
- **abstraire les composants** : Les langages de programmation donnent la
|
||||||
|
possibilité de découper une application en différents composants logiciels, plus ou
|
||||||
|
moins indépendants et autonomes. La modularité permet une structuration de plus haut
|
||||||
|
niveau de l'ensemble d'une application complexe. Les langages à objets constituent
|
||||||
|
une autre approche de la réutilisabilité permettant la réalisation très rapide de
|
||||||
|
prototypes.
|
||||||
|
|
||||||
|
Détails des niveaux d'abstraction par rapport à la machine
|
||||||
|
-----------------------------------------------------------
|
||||||
|
|
||||||
|
L'extrème déploiement des langages (plusieurs milliers de langages différents)
|
||||||
|
est dû au succès de l'ordinateur.
|
||||||
|
|
||||||
|
- **niveau 0** : le langage machine. Illisible, c'est une suite d'optcode.
|
||||||
|
impossible de coder dans ce langage.
|
||||||
|
|
||||||
|
- **niveau 1** : langage d'assemblage. Il reste très dépendant de la machine
|
||||||
|
et aujourd'hui il est rare d'en faire, sauf si on code un bootloader par exemple,
|
||||||
|
la gestion de l'accès à la mémoire est en réel (le mode protégé n'apparaît que après).
|
||||||
|
Il faut gérer les ressources,le langage est très optimisé mais presque impossible
|
||||||
|
à maintenir et rendre générique. Aujourd'hui plus personne ne code en assembleur.
|
||||||
|
|
||||||
|
- **niveau 2** : langages dits de **bas niveau** : (exemple : le C, le C++)
|
||||||
|
indépendance par rapport à la machine, grande structuration mais très verbeux
|
||||||
|
|
||||||
|
- **niveau 3** : langages dits de **haut niveau** : le raisonnement dans ces
|
||||||
|
langages ne dépent plus de la machine, et ils implémentent des paradigmes de
|
||||||
|
programmation indépendant de l'état de la mémoire de l'ordinateur,
|
||||||
|
ils sont indépendant même du système d'exploitation.
|
||||||
|
|
||||||
|
|
||||||
|
|
@ -0,0 +1,30 @@
|
||||||
|
.. Algorithmique documentation master file, created by
|
||||||
|
sphinx-quickstart on Thu Mar 16 16:07:00 2017.
|
||||||
|
You can adapt this file completely to your liking, but it should at least
|
||||||
|
contain the root `toctree` directive.
|
||||||
|
|
||||||
|
Introduction à l'algorithmique
|
||||||
|
================================
|
||||||
|
|
||||||
|
Contents:
|
||||||
|
|
||||||
|
.. toctree::
|
||||||
|
:maxdepth: 2
|
||||||
|
|
||||||
|
fondement
|
||||||
|
langage
|
||||||
|
modularite
|
||||||
|
|
||||||
|
|
||||||
|
.. algorithmique
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Indices and tables
|
||||||
|
==================
|
||||||
|
|
||||||
|
* :ref:`genindex`
|
||||||
|
* :ref:`modindex`
|
||||||
|
* :ref:`search`
|
||||||
|
|
||||||
|
|
@ -0,0 +1,220 @@
|
||||||
|
Les langages de programmation
|
||||||
|
=============================
|
||||||
|
|
||||||
|
Approche historique et chronologique
|
||||||
|
-------------------------------------
|
||||||
|
|
||||||
|
- début des langages vers les années 1950 (A0, Fortran(impératif),
|
||||||
|
Lisp(impératif et fonctionnel), Cobol)
|
||||||
|
- années 60 : Simula (classes), CPL (compilation séparée)
|
||||||
|
- années 70 : C (référence du langage impératif de bas niveau), Pascal
|
||||||
|
(procédures), Smalltalk (programmation orientée objects), Prolog
|
||||||
|
(programmation logique), Scheme (programmation fonctionnelle pure), Modula,
|
||||||
|
C++, Ada, Turbo Pascal, Common Lisp, Eiffel (programmation par contrats)
|
||||||
|
- années 80 : ML, CAML (langages fonctionnels)
|
||||||
|
- années 90 : Perl, Python, Ruby (languages de scripting multi-paradigmes)
|
||||||
|
Haskell (fonctionnel pur), Lua, Delphi, Java (orienté objet, machine
|
||||||
|
virtuelle), PHP (impératif, dédié au web), Erlang (fonctionnel+
|
||||||
|
programmation concurrente), javascript (orienté web, objets par
|
||||||
|
prototypage), OCaml (multi-paradigme, fortement typé, orienté sécurité,
|
||||||
|
programmation générique, fonctionnelle et objets, modulaire et fonctorielle)
|
||||||
|
- 2009 : go (google, compilé, typage statique, objets par prototypage,
|
||||||
|
prgrammation concurrente), Rust (fondation mozilla, multiparadigme, programmation concurrente)
|
||||||
|
|
||||||
|
Les langages actuellement les plus utilisés dans le monde de l'entreprise sont :
|
||||||
|
|
||||||
|
- javascript/NodeJS (70% du code dans le dépôt github) mais victime de son
|
||||||
|
succès (chaos complet des librairies)
|
||||||
|
- le go est de plus en plus utilisé, c'est **le** langage qui monte
|
||||||
|
actuellement
|
||||||
|
- Python, Ruby, lua, autres langages de scripting (de plus en plus utilisés)
|
||||||
|
- PHP, Java (stagnants)
|
||||||
|
- C, C++ (de moins en moins utilisés)
|
||||||
|
|
||||||
|
Approche par typologie des langages
|
||||||
|
-----------------------------------
|
||||||
|
|
||||||
|
- **A0 (1954)** : possibilité de découpage de programmes en
|
||||||
|
sous-programmes ;
|
||||||
|
|
||||||
|
- **ALGOL (1958)** : concept de bloc de code (pas forcément nommé) et d'imbrication
|
||||||
|
de blocs de code ;
|
||||||
|
|
||||||
|
- **C (1971)** : syntaxe claire et simple, programme fortement structuré ;
|
||||||
|
|
||||||
|
- **C (1980)** : le **code objet**, qui consiste à essayer de faire fonctionner
|
||||||
|
un seul jeu d'instructions sur des machines différentes. Avant, le code
|
||||||
|
d'assemblage dépendait du processeur, donc il n'y avait pas un seul et unique
|
||||||
|
jeu d'instructions ;
|
||||||
|
|
||||||
|
- **1980** : déploiement et succès des langages à objets ;
|
||||||
|
|
||||||
|
- **1983** : turbo pascal (Borland) qui fut le tournant du C,
|
||||||
|
propose un IDE (Environnement de Développement Intégré).
|
||||||
|
aujourd'hui le turbo pascal a pratiquement disparu mais pas totalement,
|
||||||
|
il est soutenu par une communauté open source autour de **Lazarus** ;
|
||||||
|
|
||||||
|
- **depuis les années 90** : deux grands groupes de langages. Les langages à
|
||||||
|
objets, et les langages fonctionnels. Les deux mondes s'interpénètrent (les
|
||||||
|
avancées actuelles du web, les microservices (Erlang, Haskell),
|
||||||
|
viennent du monde fonctionnel, le NoSQL, etc).
|
||||||
|
Les grandes avancées architecturales (système d'exploitation, linux, etc...)
|
||||||
|
viennent du monde de l'impératif.
|
||||||
|
|
||||||
|
|
||||||
|
Approches par modèles de programmation
|
||||||
|
--------------------------------------
|
||||||
|
|
||||||
|
- **le mécanisme d'exceptions** : il est possible de rompre l'exécution normale d'un
|
||||||
|
programme à un endroit et de la reprendre à un autre endroit du programme prévu à
|
||||||
|
cet effet. Ce mécanisme permet de gérer les situations exceptionnelles.
|
||||||
|
|
||||||
|
- **le paradigme impératif** : les entrées-sorties, les modifications physiques de
|
||||||
|
valeurs et les structures de contrôle itératives sont possibles.
|
||||||
|
|
||||||
|
- **le paradigme fonctionnel** : manipule les fonctions comme étant des valeurs du
|
||||||
|
langage. Celles-ci peuvent être utilisées en tant que paramètres d'autres fonctions
|
||||||
|
ou être retournées comme résultat d'un appel de fonction.
|
||||||
|
|
||||||
|
- **le paradigme objet** : La représentation du programme colle à la réalité en
|
||||||
|
reproduisant des entités relativement proches des objets réel. Attention, le piège
|
||||||
|
est de croire qu'il s'agit *du* paradigme universel puisqu'il reproduit en miroir le
|
||||||
|
réel. **C'est en fait un processus d'abstraction comme un autre**.
|
||||||
|
|
||||||
|
Sûreté du langage, typage
|
||||||
|
~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
Tri par ordre de sûreté croissant :
|
||||||
|
|
||||||
|
0. typage très faible (presque inexistant aujourd'hui) : 42 == "42" == 42.0...
|
||||||
|
1. typage dynamique faible : (javascript) (possibilité de changer le prototype
|
||||||
|
d'un objet pendant l'éxécution du programme, c'est la fête on peut faire
|
||||||
|
n'importe quoi)
|
||||||
|
2. typage dynamique fort inféré par le comportement (behavior, duck typing)
|
||||||
|
(python, ruby, PHP) Le contenu de la variable détermine le choix du typage
|
||||||
|
`var = 0 -> type int`
|
||||||
|
3. typage statique déclaré fort (Java)
|
||||||
|
`int var = 0 ;` (pas mal mais super lourd, pas **agile** du tout)
|
||||||
|
4. langages à types statiques muni d'un moteur d'inférence de types (Ocaml)
|
||||||
|
sûreté d'exécution, agilité, sécurité.
|
||||||
|
|
||||||
|
|
||||||
|
La syntaxe, la lisibilité
|
||||||
|
~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
Importance de la lisibilité (notamment par rapport aux méthodes agiles).
|
||||||
|
|
||||||
|
- courte (python)
|
||||||
|
- verbeuse (C)
|
||||||
|
- l'importance des mots clef du langage
|
||||||
|
- délimiteur de phrase, de blocs (parenthèses, accolades, tabulations, blocs...)
|
||||||
|
|
||||||
|
Langages compilés ou interprétés ?
|
||||||
|
-----------------------------------
|
||||||
|
|
||||||
|
- **le typage statique** : la vérification de la compatibilité entre les types des
|
||||||
|
paramètres formels et des paramètres d'appel est effectuée au moment de la
|
||||||
|
compilation du programme. Dès lors, il n'est pas nécessaire de faire ces
|
||||||
|
vérifications durant l'exécution du programme ce qui accroît son efficacité. En
|
||||||
|
outre, la vérification de type permet d'éliminer la plupart des erreurs introduites
|
||||||
|
par maladresse ou étourderie et contribue à la sûreté de l'exécution.
|
||||||
|
|
||||||
|
- **le typage dynamique** : la vérification de la compatibilité entre les types des
|
||||||
|
paramètres formels et des paramètres d'appel est effectuée au moment de l'exécution
|
||||||
|
ou de l'appel à certaines parties de codes du programme.
|
||||||
|
|
||||||
|
- **le polymorphisme paramétrique** : une fonction ou un objet qui n'explore pas la
|
||||||
|
totalité de la structure d'un de ses arguments accepte que celui-ci ait un type non
|
||||||
|
entièrement déterminé. Ce paramètre est alors dit polymorphe. Cette particularité
|
||||||
|
permet de développer un code générique utilisable pour des structures de données
|
||||||
|
différentes tant que la représentation exacte de cette structure n'a pas besoin
|
||||||
|
d'être connue par le code en question. L'algorithme de typage est à même de faire
|
||||||
|
cette distinction.
|
||||||
|
|
||||||
|
- **l'inférence de types** : le programmeur n'a besoin de donner aucune information
|
||||||
|
de type à l'intérieur de son programme. Le langage se charge seul de déduire du code
|
||||||
|
le type le plus général des expressions et des déclarations qui y figurent. Cette
|
||||||
|
inférence est effectuée conjointement à la vérification, lors de la compilation du
|
||||||
|
programme.
|
||||||
|
|
||||||
|
Les grands paradigmes de programmation
|
||||||
|
---------------------------------------
|
||||||
|
|
||||||
|
Le paradigme des objets
|
||||||
|
~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
- 1962 (SIMULA) : premières notions de classes ;
|
||||||
|
|
||||||
|
Pui, une dizaine d'années plus tard :
|
||||||
|
|
||||||
|
- C++ : intégration des classes pour le C ;
|
||||||
|
- turbo pascal : intégration des classes pour le pascal ;
|
||||||
|
|
||||||
|
Tous les langages actuels ont intégré des traits objets mais de manière très
|
||||||
|
différentes :
|
||||||
|
|
||||||
|
- perl (1987)
|
||||||
|
- python (1991)
|
||||||
|
- Ruby (1993)
|
||||||
|
|
||||||
|
- L'implémentation des objets en python est très proche des notions initiales de
|
||||||
|
classes issues du Smaltalk et présente une tentative très intéressante
|
||||||
|
d'unification des objets et des types depuis python 2.2 ;
|
||||||
|
|
||||||
|
- Java (1995) : très grosse réussite industrielle en surfant sur la vague de la
|
||||||
|
programmation objet, et des machines virtuelles, mais en fait et avec le recul,
|
||||||
|
doté d'un support objet lourd et alambiqué.
|
||||||
|
Le monde Java est lourd, avec des outils consommant beaucoup de mémoire et
|
||||||
|
qui ne satisfont pas à la règle du KISS (Keep It Simple, Stupid) ;
|
||||||
|
|
||||||
|
|
||||||
|
Les supports objets sont riches et variés,
|
||||||
|
|
||||||
|
- objets obligatoirement construits pas des classes (Java, C++, ...)
|
||||||
|
- objets sans définition de classes (javascript, Ocaml, go, rust)
|
||||||
|
- langages à attributs (python)
|
||||||
|
- langages ou le type des objets est défini par leur classe (python, ruby)
|
||||||
|
- langages ou le type des objets est différent du type de leur classe (Ocaml)
|
||||||
|
- objets sans classes mais construits par des prototypes (javascript)
|
||||||
|
- construction d'objets possibles objets sans classe du tout (Ocaml)
|
||||||
|
- encapsulation des attributs des objets (Java, Ocaml, C++, PHP)
|
||||||
|
- pas d'encapsulation des attributs (python, ruby, javascript...)
|
||||||
|
|
||||||
|
Le paradigme impératif
|
||||||
|
~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
Un programme est une suite d'états de la mémoire de l'ordinateur,
|
||||||
|
c'est la suite logique des machines de Turing.
|
||||||
|
La plupart des programmeur aujourd'hui raisonnent suivant ce paradigme,
|
||||||
|
et ont une très faible visibilité par rapport aux autres paradigmes existants.
|
||||||
|
Seuls les programmeurs cultivés sont aujourd'hui capable de raisonner
|
||||||
|
suivant différents paradigmes, ce sont des programmeurs chevronnés et
|
||||||
|
cultivés.
|
||||||
|
|
||||||
|
Le paradigme fonctionnel
|
||||||
|
~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
La notion de fonction que possède sous une forme ou une autre la plupart des
|
||||||
|
langages est empruntée aux mathématiques et non à l'électronique. D'une manière
|
||||||
|
générale, les langages substituent des modèles formels aux conceptions purement
|
||||||
|
calculatoires. Ils y gagnent en expressivité. Certains langages fondent leur
|
||||||
|
paradigme de programmation sur l'abstraction entrée-traitement-sortie, donc sur le
|
||||||
|
**mathème fonctionnel** et pas sur la boite noire électronique. La fonction
|
||||||
|
mathématique apporte un niveau opératoire dans le traitement de l'information.
|
||||||
|
|
||||||
|
|
||||||
|
Approche par fonctionnalités
|
||||||
|
----------------------------
|
||||||
|
|
||||||
|
Plusieurs domaines de l'informatique on proposé/imposé des méthodologies,
|
||||||
|
des manières de faire. Ces modèles de programmation on fortement influencé
|
||||||
|
en retour les langages. On reconnaît aujourd'hui :
|
||||||
|
|
||||||
|
- Le modèle client-serveur
|
||||||
|
- Le modèle de programmation concurrente (exécution de processus légers, threads) :
|
||||||
|
- Le modèle de développement d'une application de bureau (MVC, ergonomie d'interface)
|
||||||
|
- Le modèle de développement web (communiquer sur le réseau Internet, API
|
||||||
|
REST, microservices...)
|
||||||
|
- Le modèle de programmation système et réseau
|
||||||
|
- le modèle **Dev Ops** et les méthodes de développement virtualisés
|
||||||
|
- les langages présentant des **fonctionnalités agiles**
|
||||||
|
|
@ -0,0 +1,51 @@
|
||||||
|
La programmation modulaire
|
||||||
|
==========================
|
||||||
|
|
||||||
|
Structuration d'un programme
|
||||||
|
-----------------------------
|
||||||
|
|
||||||
|
La réalisation d'applications importantes oblige le programmeur ou l'équipe de
|
||||||
|
développement à se poser des questions d'organisation et de structuration.
|
||||||
|
Aujourd'hui, on dispose de deux grands modèles d'organisation dont les avantages et les
|
||||||
|
particularités sont distincts.
|
||||||
|
|
||||||
|
La modularité
|
||||||
|
~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
Les données et les traitements sont regroupés au sein d'une même entité à deux
|
||||||
|
facettes : d'un côté le code proprement dit, de l'autre son interface. La
|
||||||
|
communication entre modules s'effectue via leur interface. La description d'un
|
||||||
|
type peut être masquée en n'apparaissant pas dans l'interface du module. Ces
|
||||||
|
types de données abstraits facilitent les modifications d'implantation à
|
||||||
|
l'intérieur d'un module sans affecter les autres modules qui s'en servent. De
|
||||||
|
plus, les modules peuvent être paramétrés par d'autres modules augmentant
|
||||||
|
ainsi leur réutilisabilité.
|
||||||
|
|
||||||
|
Le paradigme objet
|
||||||
|
~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
Les descriptions des traitements et des données sont regroupées dans des
|
||||||
|
entités appelées **classes**; un objet est une instance (valeur) d'une classe.
|
||||||
|
La communication entre objets est réalisée par envoi de message, l'objet
|
||||||
|
receveur détermine à l'exécution (liaison retardée) le traitement
|
||||||
|
correspondant au message. En cela, la programmation objet est dirigée par
|
||||||
|
les données. La structuration d'un programme provient des relations entre
|
||||||
|
classes, en particulier l'héritage permet de définir une classe par extension
|
||||||
|
d'une autre.
|
||||||
|
|
||||||
|
Comparaison entre les deux paradigmes
|
||||||
|
-------------------------------------
|
||||||
|
|
||||||
|
Il y a dualité entre ces deux modèles.
|
||||||
|
|
||||||
|
- On ne peut pas augmenter les composants d'un type dans un module (pas
|
||||||
|
d'extensibilité des données), mais on peut ajouter de nouveaux traitements
|
||||||
|
(extensibilité des traitements) sur ces données.
|
||||||
|
|
||||||
|
- En objet, on peut ajouter des sous-classes à une classe (extensibilité des
|
||||||
|
données) pour traiter des nouveaux cas, mais on ne peut pas ajouter de nouveaux
|
||||||
|
traitements visibles de la classe ancêtre (pas d'extensibilité des traitements).
|
||||||
|
|
||||||
|
**La combinaison des deux paradigmes offre de nouvelles extensibilités pour les
|
||||||
|
traitements et les données.**
|
||||||
|
|
||||||
Loading…
Reference in New Issue