Тем не менее те студенты, которые планируют стать программистами, учитывают это, и в своих собственных решениях подобная ересь потихоньку уступает место современным методам разработки.
Всю мощь и нужность рефакторинга понимаешь тогда, когда начинаешь заниматься поддержкой проекта, который писали человек 10 до тебя, обладали разной квалификацией и придерживались разных стилей, подходов и технологий.
клиент который приобрел продукт для использования по редкому не стандартному сценарию
Насколько я понимаю, продукт разрабатывается под клиента (исключение составляют серийные продукты). В этом случае сценарий, который нужен клиенту, является базовым, и никак не может быть отнесен к редким и нестандартным.
Если не в моих силах что-либо изменить, то я просто соглашаюсь с этим и сразу думаю о том, что делать дальше. Я не думаю о том, плохо это или хорошо — оно уже есть, с фактами не спорят, а тратить время на переживания — не только потеря времени, но также и эмоциональный дисбаланс, в итоге — ничего хорошего.
Не все это понимают, особенно когда я где-то прокосячил, и от меня ждут обычной реакции типа «извиняюсь», «был не прав» с соответствующим настроением. Извинения — да, конечно, это нужно, но вот позволять наносить себе вред на эмоциональном фоне неполезно. Никому. Лушче взять и поправить, либо принять меры, чтобы не повторилось — гораздо продуктивнее.
Важно не на чем, а как :-)
В текстовом парсинге я тоже склоняюсь к потоковому побайтному чтению, но ООП тоже использую — очень уж легко подменять обработчики в зависимости от контекста ) накладные расходы не такие уж большие (не более 50 служебных объектов-парсеров для случая XML).
Кстати, эту концепцию легко расширить на любые типы атрибутов фигур.
Иерархия интерфейсов при этом может сколь угодно отличаться от иерархии классов реализаций.
В итоге с точки зрения чтения (через интерфейс) имеем все плюсы наследования.
А с точки зрения записи (через конкретную реализацию) можем менять только то, что является параметром данного вида фигуры.
Код, который будет управлять параметрами фигуры, будет хранить ссылку типа конкретного класса, остальные же работают с интерфейсом.
По-моему все очень хорошо решается, если сделать так:
public interface Ellipse {
double getA();
double getB();
}
public interface Circle extends Ellipse {
double getR();
}
public class EllipseImpl implements Ellipse {
public double getA() {...}
public void setA(double a) {...}
public double getB() {...}
public void setB(double b) {...}
}
public class CircleImpl implements Circle {
public double getA() {...}
public double getB() {...}
public double getR() {...}
public void setR(double r) {...}
}
Я бы использовал объект-значение для обоих классов ) тогда круг можно реализовать как подкласс эллипса, и это будет корректно с точки зрения наследования в ООП.
Я лично использую final с приватным конструктором для утилитных классов и singleton'ов. Удобно тем, что IDE в списке классов помечает final-классы особым значком, что удобно при просмотре дерева иерархии классов.
Также в Java можно увидеть использование protected final переменных (не только static!). Это облегчает работу с ними в наследующих классах, но не дает изменять, чтобы не разрушить логику базового класса.
В любом проекте программист над какой-то частью кода работает больше, чем над другой. И чем чаще он с ней работает, тем лучше он ее помнит — где у него там классы, а где интерфейсы. А если с этой частью он работает редко — ему все равно необходимо будет посмотреть определение. Так что семантическая примесь к имени не нужна.
Кстати, а Вы в курсе, из-за чего большинство (если не все) программистов перестали использовать венгерскую нотацию? :-)
Если это не внешний интерфейс, то у него всегда есть шансы стать абстрактным классом в результате рефакторинга :-) А лишнее переименование при этом — это дополнительная нагрузка на гарантию корректности рефакторинга.
:-) Фактически, уважаемые спорщики говорят об одном и том же разными словами и терминами, имея свое субъективное мнение об их назначении.
Легко убедиться, что они хорошо владеют терминологией, пусть с небольшими погрешностями в понимании.
Проблема состоит в стыковке: если одинаковые понятия имеют разные формулировки, бывает довольно сложно понять, что это одно и то же.
Насколько я понимаю, продукт разрабатывается под клиента (исключение составляют серийные продукты). В этом случае сценарий, который нужен клиенту, является базовым, и никак не может быть отнесен к редким и нестандартным.
Если не в моих силах что-либо изменить, то я просто соглашаюсь с этим и сразу думаю о том, что делать дальше. Я не думаю о том, плохо это или хорошо — оно уже есть, с фактами не спорят, а тратить время на переживания — не только потеря времени, но также и эмоциональный дисбаланс, в итоге — ничего хорошего.
Не все это понимают, особенно когда я где-то прокосячил, и от меня ждут обычной реакции типа «извиняюсь», «был не прав» с соответствующим настроением. Извинения — да, конечно, это нужно, но вот позволять наносить себе вред на эмоциональном фоне неполезно. Никому. Лушче взять и поправить, либо принять меры, чтобы не повторилось — гораздо продуктивнее.
В текстовом парсинге я тоже склоняюсь к потоковому побайтному чтению, но ООП тоже использую — очень уж легко подменять обработчики в зависимости от контекста ) накладные расходы не такие уж большие (не более 50 служебных объектов-парсеров для случая XML).
Иерархия интерфейсов при этом может сколь угодно отличаться от иерархии классов реализаций.
А с точки зрения записи (через конкретную реализацию) можем менять только то, что является параметром данного вида фигуры.
Код, который будет управлять параметрами фигуры, будет хранить ссылку типа конкретного класса, остальные же работают с интерфейсом.
public interface Ellipse {
double getA();
double getB();
}
public interface Circle extends Ellipse {
double getR();
}
public class EllipseImpl implements Ellipse {
public double getA() {...}
public void setA(double a) {...}
public double getB() {...}
public void setB(double b) {...}
}
public class CircleImpl implements Circle {
public double getA() {...}
public double getB() {...}
public double getR() {...}
public void setR(double r) {...}
}
Кстати, а Вы в курсе, из-за чего большинство (если не все) программистов перестали использовать венгерскую нотацию? :-)
Разрабатывалось ПО для автоматической удаленной установки различных ОС в заданной конфигурации.
Демка работала следующим образом:
И — как это ни странно — ОСь действительно стояла.
Легко убедиться, что они хорошо владеют терминологией, пусть с небольшими погрешностями в понимании.
Проблема состоит в стыковке: если одинаковые понятия имеют разные формулировки, бывает довольно сложно понять, что это одно и то же.