Когда я должен использовать Perl OO?
У меня была такая же проблема некоторое время назад. Мне приходилось обновлять DataTable всякий раз, когда данные менялись, и вот как я решил это в своей программе:
public ObservableCollection<KeyStroke> keyList = new ObservableCollection<KeyStroke>();
public class KeyStroke : INotifyPropertyChanged
{
// KeyStroke class storing data about each key and how many types it received
private int id;
private int numPress;
public KeyStroke(int id, int numPress)
{
Id = id;
NumPress = numPress;
}
public int Id
{
get => id;
set
{
id = value;
NotifyPropertyChanged("Id");
}
}
public int NumPress
{
get { return this.numPress; }
set
{
this.numPress = value;
NotifyPropertyChanged("NumPress");
}
}
public event PropertyChangedEventHandler PropertyChanged; //This handle the propertyChanged
private void NotifyPropertyChanged(String propertyName)
{
PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(propertyName)); //This is the WPF code for the DataGrid but you can replace it by whatever you need
}
}
Это должно помочь вам. Вы также можете помещать условия в методы получения / установки свойств, но я думаю, что это не очень красиво
5 ответов
10 критериев знания, когда использовать объектно-ориентированный дизайн
Дизайн является большим, или, вероятно, станет большим
Когда данные агрегированы в очевидные структуры, особенно если существует много данных в каждом агрегате
Например, IP-адрес не является хорошим кандидатом: существует только 4 байта информации, связанной с IP-адресом. У иммигранта, проходящего таможню, есть много данных, связанных с ним, таких как имя, страна происхождения, багаж, который несут, место назначения, и т.д.
Когда типы данных формируют естественную иерархию, которая позволяет нам использовать наследование.
Наследование является одной из наиболее мощной функции OO, и способность использовать его является флагом.
Когда операции на данных варьируются на типе данных
GIFs и JPGs можно было бы сделать их обрезку по-другому, даже при том, что они - оба графика.
Когда вероятно, что необходимо будет добавить типы данных позже
OO дает Вам комнату для расширения в будущем.
Когда взаимодействия между данными лучше всего показывают операторы
Некоторые отношения лучше всего показывают при помощи операторов, которые могут быть перегружены.
Когда реализация компонентов, вероятно, изменится, особенно в той же программе
Когда проектирование системы уже объектно-ориентировано
Когда огромное число клиентов использует Ваш код
Если Ваш код будет распределен другим, которые будут использовать его, стандартный интерфейс сделает maintenence и безопасность легче.
Когда у Вас есть часть данных, на которые применяются много различных операций
Графические изображения, например, могли бы быть размыты, обрезаны, повернуты и скорректированы.
Когда виды операций имеют стандартные имена (проверка, процесс, и т.д.)
Объекты позволяют Вам иметь a
DB::check,ISBN::check,Shape::check, и т.д. не имея конфликтов между типами проверки.
Существует хорошая дискуссия о том же предмете PerlMonks.
Наличие Американского лося, конечно, помогает всегда использовать OO от слова, идут. Единственное реальное исключение - то, если запуск компиляции является проблемой (У американского лося действительно в настоящее время есть время компиляции наверху).
Я не думаю, что необходимо измерить его строками кода.
Вы правы, часто когда Вы просто пишете простой сценарий, OO является, вероятно, слишком много служебным, но я думаю, что необходимо быть более гибкими относительно этих 10 подходов строк.
Во всех случаях, когда Вы используете Perl OO Rememebr для использования Американского лося (или Мышь)
Этот вопрос не имеет так многого, чтобы сделать с Perl. Вопрос, "когда, учитывая выбор я должен использовать OO?" Это, "учитывая выбор" укусило, то, потому что на некоторых языках (Java, например), у Вас действительно нет выбора.
Ответ, "когда он имеет смысл". Думайте о проблеме, которую Вы пытаетесь решить. Проблема вписывается в понятие OO классов и объекта? Если это делает, большой, используйте OO. Иначе используйте некоторую другую парадигму.
Perl довольно гибок, и можно легко записать процедурный, функциональный, или Perl OO, или даже смешать их. Не становитесь одержимыми выполнением OO, потому что все остальные. Учитесь использовать правильный подход для каждой задачи.
Все это берет опыт и практику, поэтому удостоверьтесь, что испытали все эти подходы, и возможно даже взяли некоторые меньшие проблемы и решили их несколькими способами видеть, как каждый работает.
У Damian Conway есть проход в Лучших практиках Perl об этом. Это не правило, что необходимо следовать за ним, но это - вероятно, лучший совет, который я могу дать, не зная много о том, что Вы делаете.
Вот страница издателя, если это - лучшее место для соединения с книгой.