ООП: Когда создать производные классы, и когда реализовать опции с условными выражениями?
Еще одна возможность:
ap %>%
group_by(examName) %>%
mutate(temp = n()) %>%
ungroup() %>%
mutate(temp = dense_rank(desc(temp))) %>%
filter(temp %in% c(1,2)) %>%
select(-temp) %>%
count(year, examName) %>%
ggplot(aes(x = year, y = n, group = examName)) +
geom_line() +
facet_wrap(~ examName)
Он подсчитывает количество случаев по «examName» и ранжирует количество. Затем он фильтрует случаи с наибольшим и вторым наибольшим числом.
4 ответа
Можно хотеть рассмотреть использование стратегической модели вместо обоих подходов и инкапсулировать поведения во внешних классах. Затем поведения могут быть введены в Ракетный класс для создания этого GuidedMissile или SpaceRocket или независимо от того, что Вам нужно.
Таким образом, чрезмерного ветвления логики в Ракетном классе можно было избежать, и Вы не должны будете входить в логические сложности, связанные с глубоким наследованием.
Википедия имеет набор образцов использования шаблона на нескольких языках: http://en.wikipedia.org/wiki/Strategy_pattern
interface INavigable {
Course calcCourse (Position current, Destination dest);
}
Class GeoStationaryRocketCPU implements INavigable {
Course calcCourse (Position current, Destination dest) {
return dest.getShortestRouteTo (current).getCourse();
};
}
Class GuidedMissileCPU implements INavigable {
Course calcCourse (Position current, Destination dest) {
return dest.getLowestAltRouteTo (current).getCourse();
};
}
class Missile {
INavigable CPU;
void setCPU (INavigable CPU) {
this.CPU = CPU;
}
void fly ()
{
...
course = this.CPU.calcCourse (pos, dest);
...
}
}
Как предложил другой коллега, Вы могли рассмотреть использование Шаблона "декоратор" также. Только для выделения нескольких вопросов проектирования, которые могли бы быть важными в контексте, если бы необходимо было следовать тем маршрутом:
- Для замены просто определенного аспекта поведения объекта, необходимо было бы украсить весь класс.
- Если открытый интерфейс украшенного класса (позволяют, говорит, что ракета), чтобы быть когда-либо измененным (даже некоторая функциональность, не связанная с ее аспектом навигации), необходимо было бы изменить все классы украшения (т.е. GuidedMissile, Ракета, FireworkRocket и т.д.) для передачи интерфейса.
- В Декораторе Вы ожидали бы, что декоратор добавит функциональность, не заменит ее. Это работает путем добавления вызова его функций, затем называя метод базового класса. В сценарии выше этого привел бы к способности иметь GuidedMissileCPU, который украшает GeoStationaryRocketCPU - ясно это не то, что Вы хотите. Вы хотите, чтобы это выбрало другую стратегию навигации не стратегии навигации слоя друг сверху друга.
Тем не менее, при предоставлении готовую неизменную реализацию Ракетного художественного оформления мог быть ключ к "разблокированию" его и реализации стратегической модели, для предоставления Ракете все виды необходимых поведений.
Наследование зависит от языка/технологии, который Вы используете, например, в C++, можно получить класс из нескольких классов, но такая конструкция не доступна в Java, C#, PHP и т.д., но вместо этого у Вас есть абстрактные классы и интерфейсы, что я пытаюсь сказать, то, что, если у Вас есть класс, например, программное обеспечение Вашей компании будет использовать несколько систем управления базами данных и до Вас для разработки независимого набора классов для такой конструкции, и можно сделать это при помощи абстрактного класса и реализовать полиморфизм к набору, например:
public abstract class Database
{
public virtual void Connect();
public virtual int GetNumberOfTables();
}
и затем можно получить класс для определенного SQL Server или внедрения продуктов Oracle
public class SQLServerDatabase : Database
{
public override void Connect()
{
// SQL Implementation
}
public override int GetNumberOfTables()
{
// SQL Implementation
}
}
public class OracleDatabase : Database
{
public override void Connect()
{
// Oracle Implementation
}
public override int GetNumberOfTables()
{
// Oracle Implementation
}
}
В такой конструкции можно использовать наследование, но предотвращение логической сложности класса, поскольку я видел в примере выше.
Что касается условных выражений можно использовать для теста при уничтожении объектного или сборщика "мусора", устанавливает объект в очереди завершения, что это не доступно Вам больше.
Я думаю, что в этом случае Вы должны Шаблон "декоратор". Каждая новая функциональность, которую Вы добавляете, является художественным оформлением на исходном Ракетном классе. Например, Вы могли создать новый украшенный Ракетный класс, который может Вестись (GuidedMissile), и это может пойти подводное (UnderwaterMissile), просто украшающий tha Ракетный класс. Польза - то, что Шаблон "декоратор" работает во времени выполнения, и Вы не должны создавать все, что классы со статическим поведением кроме Вас могут составить необходимое поведение во времени выполнения. Взгляните здесь: http://en.wikipedia.org/wiki/Decorator_pattern http://www.dofactory.com/Patterns/PatternDecorator.aspx
Просто спросите себя, как было бы легче:
- прочитайте и поймите код (маленькая часть проекта и целый проект)
- измените код в будущем (быть очень осторожным при предсказании будущих потребностей, обычно лучше не адаптировать код к, "возможно", изменениям заранее),
Также существуют некоторые действительно редкие случаи, когда иерархия классов может серьезно влиять на производительность.
Поэтому сделайте производные классы, когда это будет лучше для указанных выше критериев.