Если я правильно понял, вы хотите заменить несколько +
только на одну.
Я полагаю, что это позволит вам найти то, что вы ищете:
String regex = "[+](?=[+])";
String text = "122+1+3";
assertEquals("122+1+3", text.replaceAll(regex, ""));
text = "1++2+++4+123";
assertEquals("1+2+4+123", text.replaceAll(regex, ""));
Это моя первая Java-программа, извините, если она кого-то обидит.
Прочитав Ваши комментарии в ответе Mehrdad, я думаю, что понимаю Вашу проблему немного лучше.
Кажется, что Вы обеспокоены способностью разработчика получить доступ к частному состоянию в классе, который они пишут, обходя Вашу логику проверки, и т.д. Это предлагает, чтобы состояние не содержалось в классе вообще.
Я предложил бы следующую стратегию. Запишите универсальный класс, который представляет ValidatedValue. Этот класс содержит только отступающее значение и только предоставляет доступ через, добираются и методы установки. Делегат передается ValidatedValue для представления логики проверки:
public class ValidatedValue< T >
{
private T m_val;
public ValidationFn m_validationFn;
public delegate bool ValidationFn( T fn );
public ValidatedValue( ValidationFn validationFn )
{
m_validationFn = validationFn;
}
public T get()
{
return m_val;
}
public void set(T v)
{
if (m_validationFn(v))
{
m_val = v;
}
}
}
Вы могли, конечно, добавить больше делегатов как требуется (например, для поддержки пред/сообщение уведомление об изменении).
Ваш класс теперь использовал бы ValidatedValue вместо запоминающего устройства для Вашего свойства.
Пример ниже показывает класс, MyClass, с целым числом, которое проверено, чтобы быть меньше чем 100. Обратите внимание, что логика для выдачи исключения находится в MyClass, не ValidatedValue. Это позволяет Вам делать сложные правила проверки, которые зависят от другого состояния, содержавшегося в MyClass. Нотация лямбды использовалась для построения делегата проверки - Вы, возможно, связали с функцией членства вместо этого.
public partial class MyClass
{
private ValidatedValue<int> m_foo;
public MyClass()
{
m_foo = new ValidatedValue<int>(
v =>
{
if (v >= 100) RaiseError();
return true;
}
);
}
private void RaiseError()
{
// Put your logic here....
throw new NotImplementedException();
}
public int Foo
{
get { return m_foo.get(); }
set { m_foo.set(value); }
}
}
Надежда, которая помогает - несколько от исходной темы, но я думаю, что это - больше встроенное с Вашими фактическими проблемами. То, что мы сделали, устранено логика проверки у свойства и поместило его на данные, которые являются точно, где Вы хотели это.
Нет нет. Если Вы хотите получить доступ к отступающему полю, то не используйте автоматические свойства и самокрутку.
Я соглашаюсь, что было бы замечательно иметь поле, которое было только доступно свойством а не остальной частью класса. Я использовал бы это все время.
Нет, но Вы можете в подклассе:
public class Base
{
public string Name
{
get;
virtual set;
}
}
public class Subclass : Base
{
// FIXME Unsure as to the exact syntax.
public string Name
{
override set
{
if (value != base.Name)
{
RaiseEvent();
}
base.Name = value;
}
}
}
Если Вы собираетесь делать так, почему Вы используете автоматические свойства?!
Простое свойство сделало это путь назад в 1,0. Я не думаю, что имеет смысл добавлять сложность к языку для каждого особого случая. Вам или нужно свойство, чтобы сделать, плоскость хранит/получает модель или нуждается в больше, чем это. В последнем случае нормальное свойство сделает.
Поскольку MSDN указывает:
"В C# 3.0 и позже, автореализованные свойства делают объявление свойства более кратким, когда никакая дополнительная логика не требуется в средствах доступа свойства. Они также позволяют клиентскому коду создать объекты, Когда Вы объявляете свойство как показано в следующем примере, компилятор создает частное, анонимное поле поддержки, может только быть получен доступ через свойство, получают и устанавливают средства доступа".
Так как у Вас есть дополнительная логика в Вас средства доступа, использование автореализованных свойств не является соответствующим в Вашем сценарии.
В то время как отступающее поле действительно существует, ему дают скорректированное имя для остановки Вас ссылающийся на него легко - идея состоит в том, что Вы никогда не ссылаетесь на поле непосредственно. Для пользы интересов можно использовать Отражатель, чтобы демонтировать код и обнаружить имя поля, но я рекомендовал бы не использовать поле непосредственно, поскольку это имя может действительно быть энергозависимо, таким образом, код мог повредиться в любое время.
Вы не можете сделать этого, я боюсь. Это - одна из причин, которые я начал писать Бесполезным утилитам MoXAML, обеспечивать способность преобразовать автоматические свойства в свойства Notify.