Это корректно для наследования встроенным классам?

Согласно Документации JMeter :

Если параметр функции содержит запятую, то обязательно избегайте этого с помощью «\», в противном случае JMeter будет рассматривать его как параметр разделитель.

blockquote>

У этого ограничения есть побочный эффект: если вам нужно передать обратную косую черту - вам нужно экранировать ее с другой обратной косой чертой

Так что в основном, если вы передадите "a" своей функции, вы будете в результате получите \"a\":

enter image description here

Пока ваш сервер ожидает, что он будет экранирован двойной косой чертой, то есть \\"a\\"

Я предполагаю, что вам нужно будет добавить еще несколько обратных слешей, чтобы соответствовать синтаксису функций JMeter и тому, что ожидает ваш сервер. Результирующий синтаксис будет выглядеть следующим образом:

${__strReplace(${C_Create_Escape},",\\\\\\\",)}

enter image description here

Ознакомьтесь с функциями Apache JMeter - статья для более подробной информации информация о концепции функций JMeter.

6
задан Igor Katson 13 November 2008 в 23:06
поделиться

6 ответов

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

Существует по крайней мере две причины этого:

  1. Делегация уменьшает связь, например, вместо объектов файла, что можно использовать любой другой объект, который реализует a readline метод (утиный ввод происходит удобный сюда).
  2. При наследовании из файла открытый интерфейс класса становится излишне широким. Это включает все методы, определенные в файл, даже если эти методы не имеют смысла в случае журнала Apache.
15
ответ дан 8 December 2019 в 04:56
поделиться

Я происхожу из среды Java, но я довольно уверен, что те же принципы будут применяться в Python. Как показывает опыт, Вы никогда не должны наследоваться классу, реализацию которого Вы не понимаете и управляете, если тот класс не был специально разработан для наследования. Если это было разработано таким образом, это должно описать это ясно в его документации.

Причина этого состоит в том, что наследование может потенциально связать Вас с деталями реализации класса, которому Вы наследовались.

Использовать пример из книги Josh Bloch 'Эффективный Java'

Если мы должны были расширить класс ArrayList класс, чтобы смочь считать количество объектов, которые были добавлены к нему в течение его времени жизни (не обязательно число это в настоящее время содержит) мы можем испытать желание записать что-то вроде этого.

public class CountingList extends ArrayList {
    int counter = 0;

    public void add(Object o) {
        counter++;
        super.add(0);
    }

    public void addAll(Collection c) {
        count += c.size();
        super.addAll(c);
    }

    // Etc.
}

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

Это, конечно, в дополнение к недостатку неспособности использовать другие реализации List с нашим CountingList класс. Плюс недостатки наследования от реального класса, которые обсуждены выше.

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

6
ответ дан 8 December 2019 в 04:56
поделиться

Совершенно приемлемо наследоваться созданному в классе. В этом случае я сказал бы, что Вы правы на деньгах.
Журнал "является" файлом так, чтобы сказал Вам, что наследование в порядке..

Общее правило.
Собака "" n животное, поэтому наследуйтесь животному.
Владелец "имеет" n, животное поэтому не наследовались животному.

1
ответ дан 8 December 2019 в 04:56
поделиться

Необходимо быть довольно безопасным наследованием от "встроенного" класса, поскольку более поздние модификации к этим классам обычно будут совместимы с текущей версией.

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

Как пример того, почему избежать наследования, если Вам не нужно оно, можно посмотреть на java.util. Класс стека. Поскольку это расширяет Вектор, это наследовало все методы на Векторе. Большинство этих методов нарушает условия контракта, подразумеваемые Стеком, например, LIFO. Было бы намного лучше реализовать Стек с помощью Вектора внутренне, только выставив методы Стека как API. Затем было бы легко изменить реализацию на ArrayList или что-то еще позже, ни один из которого не возможен теперь из-за наследования.

1
ответ дан 8 December 2019 в 04:56
поделиться

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

1
ответ дан 8 December 2019 в 04:56
поделиться

Вы, кажется, нашли свой ответ, который в этой делегации случая является лучшей стратегией. Тем не менее, я хотел бы добавить что, за исключением делегации, нет ничего неправильно с расширением встроенного класса, особенно если Ваша альтернатива, в зависимости от языка, "исправление обезьяны" (см. http://en.wikipedia.org/wiki/Monkey_patch),

0
ответ дан 8 December 2019 в 04:56
поделиться
Другие вопросы по тегам:

Похожие вопросы: