Кто-то может дать лучший пример проблем хрупкого базового класса?

Ваш скрипт содержит ряд неуклюжих или неэффективных антипаттернов. Вот рефакторинг. Единственное реальное изменение - это пропуск любых *.gz файлов.

#!/bin/bash

logsDirectory="/test//logs/" 
email="" 
backupDirectory="/test/backup" 
pid="/data/test/scripts/backup.pid"
# Avoid useless use of grep -- awk knows how to match a regex
# Better still run df /data/logs
usage=$(df /data/logs/ | awk '{ print $2 }') 
space=450000000

getBackup () 
{
    # Quote variables
    if [[ ! -e "$pid" ]]; then
        if [[ "$usage" -le "$space" ]]; then
            touch "$pid"
            find "$backupDirectory" -mtime +15 -type f  -delete;
            # Exclude *.gz files
            # This is still not robust against file names with spaces or wildcards in their names
            for i in $(find "$logsDirectory" -type f -not -path "*/irws/*" -not -name '*.gz')
            do
                # Avoid useless use of $?
                if /sbin/fuser "$i" > /dev/null 2>&1
                then
                        gzip  "$i"
                        mv -v "$i.gz" "$backupDirectory"
                # no need for do-nothing else
                fi
            done
            [[ ! -z "$email" ]] &&
            echo "Backup is ready" | mas"Backup" "$email"
            rm -f "$pid"
        fi
    fi
}
getBackup

С немного более навязчивым рефакторингом правильное исправление цикла find, возможно, будет выглядеть примерно как

            find "$logsDirectory" -type f \
              -not -path "*/irws/*" -not -name '*.gz' \
              -exec sh -c '
                for i; do
                    if /sbin/fuser "$i" > /dev/null 2>&1
                    then
                        gzip  "$i"
                        mv -v "$i.gz" "$backupDirectory"
                    fi
                done' _ {} +

, где секретный соус должен передать find ... -exec + в аргументах к сценарию sh -c таким образом, чтобы вообще не включать в себя аргументы текущей оболочки.

9
задан Péter Török 28 June 2010 в 15:49
поделиться

1 ответ

Да - java.util. Свойства являются болью для получения из.

В настоящий момент давайте не примем во внимание то, что это происходит из java.util. Хеш-таблица для запуска с (то, что означает это, имеет get(Object) и put(Object, Object) несмотря на то, что свойства всегда являются строками...

Я когда-то разделил java.util на подклассы. Свойства для обеспечения своего рода иерархической структуры - в файле свойств я имел:

x.y.z = 10
a.b.c = 10

и Вы могли попросить у "основных" свойств "x" (с новым вызовом метода), и он даст Вам другой объект свойств, который эффективно содержал бы "y.z = 10" и т.д. Было удобно разделить java.util на подклассы. Свойства как много других частей кода уже знали используемые свойства. Если бы это реализовало интерфейс, то я не разделил бы на подклассы, и у меня не было бы проблем :(

Так или иначе я должен был переопределить getProperty (), чтобы вернуться к родительским свойствам при необходимости. Но существует две перегрузки - который я должен переопределить? getProperty (Представляет вызов в виде строки) getProperty (Строка, Строка) или наоборот? Возможно, я только должен переопределить, добираются ()? Это не документируется, и если бы я только переопределил одного из них, то реализация могла бы измениться в более поздней версии для переключения вещей вокруг - таким образом, я должен был переопределить их обоих.

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

Так или иначе это было определенным примером, где состав и представление интерфейса, на который будут полагаться клиенты, были бы намного лучше.

7
ответ дан 4 December 2019 в 23:08
поделиться