Борьба с использованием чистого функционального программирования для решения повседневных задач

Да, вы действительно сделали бы это совсем по-другому, используя функциональный подход.

Вот скетч с использованием типизированного, по умолчанию чистого, функционального языка программирования Haskell. Мы создаем новые типы для ключевых понятий вашей проблемы и разбиваем работу на отдельные функции, выполняющие одну задачу за раз. IO и другие побочные эффекты (например, создание символической ссылки) ограничены определенными функциями и обозначены типом. Чтобы различать два режима работы, мы используем тип суммы.

--
-- User can request an image or a thumbnail of the image.
-- If the user requests the thumbnail of the image, and it doesn't yet exist, create it using
-- python's PIL module. Also create a symbolic link to the original or
-- thumbnail with a human readable path, because the original image name is a
-- hashcode, and not descriptive of it's contents. Finally, redirect to the
-- symbolic link of that image.
--

module ImageEvent where

import System.FilePath
import System.Posix.Files

-- Request types
data ImgRequest = Thumb ImgName | Full ImgName

-- Hash of image 
type ImgName = String

-- Type of redirects
data Redirect

request :: ImgRequest -> IO Redirect
request (Thumb img) = do
    f <- createThumbnail img
    let f' = normalizePath f
    createSymbolicLink f f'
    return (urlOf f)

request (Full img)  = do
    createSymbolicLink f f'
    return (urlOf f)
    where
        f  = lookupPath img
        f' = normalizePath f

Наряду с некоторыми помощниками, определение которых я оставлю на ваше усмотрение.

-- Creates a thumbnail for a given image at a path, returns new filepath
createThumbnail :: ImgName -> IO FilePath
createThumbnail f = undefined
    where
        p = lookupPath f

-- Create absolute path from image hash
lookupPath :: ImgName -> FilePath
lookupPath f = "/path/to/img" </> f <.> "png"

-- Given an image, construct a redirect to that image url
urlOf :: FilePath -> Redirect
urlOf = undefined

-- Compute human-readable path from has
normalizePath :: FilePath -> FilePath
normalizePath = undefined

По-настоящему красивым решением было бы абстрагировать модель запроса/ответа структурой данных, представляющей последовательность выполняемых команд. Приходит запрос, создается структура исключительно для представления того, какую работу необходимо выполнить, и она передается механизму выполнения, который выполняет такие действия, как создание файлов и так далее. Тогда основная логика будет полностью чистыми функциями (не то чтобы в этой задаче было много основной логики). В качестве примера такого стиля действительно чисто функционального программирования с эффектами я рекомендую статью Воутера Свистры, ``Красота в чудовище: функциональная семантика для отряда неуклюжих''

Лично я думаю, что проблема в том, что вы пытаетесь использовать функциональное программирование для решения проблем, которые разработаны/установлены для императивного программирования. 3 популярные парадигмы (функциональная, императивная, объектно-ориентированная) имеют разные сильные стороны:

• Функциональное программирование делает акцент на описании того, ЧТО нужно сделать, обычно с точки зрения ввода/результата.
• Императивное программирование делает акцент на том, КАК что-то делать, обычно с точки зрения списка и порядка шагов, которые нужно предпринять, и состояний, которые нужно изменить.
• Объектно-ориентированное программирование делает акцент на ОТНОШЕНИЯХ между сущностями в системе.

Таким образом, когда вы подходите к проблеме, в первую очередь нужно перефразировать ее так, чтобы предполагаемая парадигма могла ее правильно решить. Кстати, в качестве побочного узла, насколько мне известно, не существует такого понятия, как "чистое ООП". Код в методах ваших ООП-классов (будь то Java, C#, C++, Python или Objective C) императивен.

Вернемся к вашему примеру: то, как вы формулируете свою проблему (сначала, потом также, наконец), носит императивный характер. Таким образом, создание функционального решения практически невозможно (без использования таких трюков, как побочный эффект или монады). Точно так же, даже если вы создадите кучу классов, эти классы сами по себе бесполезны. Чтобы использовать их, вы должны написать императивный код (хотя эти коды встроены в классы), который шаг за шагом решает проблему.

Чтобы переформулировать проблему:

• Входные данные: тип изображения (полное или миниатюрное), имя изображения, файловая система.
• Вывод: запрошенный образ, файловая система с запрошенным образом

Из новой постановки задачи вы можете решить ее следующим образом:

def requestImage(type, name, fs) : 
    if type == "full" :
        return lookupImage(name, fs), fs
    else:
        thumb = lookupThumb(name, fs)
        if(thumb) :
            return thumb, fs
        else:
            thumb = createThumbnail(lookupImage(name, fs))
            return thumb, addThumbnailToFs(fs, name, thumb)

Конечно, это неполный вариант, но мы всегда можем рекурсивно решать задачи lookupImage, lookupThumb, createThumbnail и addThumbnailToF примерно таким же образом.

Важное примечание: создание новой файловой системы звучит грандиозно, но так быть не должно. Например, если это модуль на более крупном веб-сервере, «новая файловая система» может быть такой же простой, как инструкция о том, где должна быть новая миниатюра. Или, в худшем случае, это может быть монада IO, чтобы поместить миниатюру в нужное место.

Единственный способ изменить свой образ мышления — это изменить свой образ мышления. Я могу сказать вам, что сработало для меня:

Я хотел работать над личным проектом, который требовал параллелизма. Я осмотрелся и нашел erlang. Я выбрал его, потому что считал, что он обеспечивает наилучшую поддержку параллелизма, а не по какой-либо другой причине. Я никогда раньше не работал с функциональными языками (просто для сравнения, я начал заниматься объектно-ориентированным программированием в начале 1990-х).

Я читал книгу Армстронга об эрланге. Это было тяжело. У меня был небольшой проект, над которым нужно было поработать, но я продолжал над ним работать.

Проект потерпел неудачу, но через пару месяцев я достаточно наметил все в своей голове, чтобы больше не думать объектами, как раньше.

Я прошел этап, когда я сопоставлял объекты с процессами erlang, но это было не слишком долго, и я вышел из него.

Теперь смена парадигмы похожа на смену языка или переход с одной машины на другую. Вождение машины моего отца отличается от моего грузовика, но мне не нужно много времени, чтобы снова привыкнуть к этому.

Я думаю, что работа на Python может вас сдерживать, и я настоятельно рекомендую вам проверить erlang. Его синтаксис очень чужд, но это тоже хорошо, так как более традиционный синтаксис (по крайней мере, для меня) привел бы к попыткам запрограммировать его по-старому и разочарованию.