1 files changed, 67 insertions, 0 deletions
diff --git a/usth/ICT2.7/P4L5 Software Refactoring Subtitles/8 - Collapse Hierarchy - lang_en_vs4.srt b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/8 - Collapse Hierarchy - lang_en_vs4.srt
new file mode 100644
index 0000000..8711182
--- /dev/null
+++ b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/8 - Collapse Hierarchy - lang_en_vs4.srt
@@ -0,0 +1,67 @@
+1
+00:00:00,110 --> 00:00:03,080
+The first refactoring we're going to see is the collapse hierarchy
+
+2
+00:00:03,080 --> 00:00:06,340
+refactoring. When a software system undergoes a number of changes, over
+
+3
+00:00:06,340 --> 00:00:09,730
+time the collapse hierarchy may become, let's say, sub-optimal. There are
+
+4
+00:00:09,730 --> 00:00:11,300
+several refactorings that address this
+
+5
+00:00:11,300 --> 00:00:13,200
+issue for example, refactorings that allow
+
+6
+00:00:13,200 --> 00:00:15,900
+you to move methods and fields up and down the class
+
+7
+00:00:15,900 --> 00:00:18,360
+hierarchy. So what happens when you apply a number of these
+
+8
+00:00:18,360 --> 00:00:22,360
+refactorings, is that a subclass might become too similar to its
+
+9
+00:00:22,360 --> 00:00:25,878
+superclass and might not be adding much value to the system.
+
+10
+00:00:25,878 --> 00:00:28,010
+In this case, it is a good idea to merge
+
+11
+00:00:28,010 --> 00:00:31,300
+the classes together. That's exactly what the Collapse Hierarchy refactoring
+
+12
+00:00:31,300 --> 00:00:34,600
+does. Imagine, for instance, that we have two classes: employee
+
+13
+00:00:34,600 --> 00:00:38,210
+and salesman. And that salesman is just so similar to
+
+14
+00:00:38,210 --> 00:00:40,380
+employee that it does not make sense to keep them
+
+15
+00:00:40,380 --> 00:00:43,870
+separated. In this case, you could merge the two classes,
+
+16
+00:00:43,870 --> 00:00:46,730
+so that at the end of the refactoring, only employee
+
+17
+00:00:46,730 --> 00:00:50,070
+is left. And the resulting structure of the system is improved.