1 files changed, 0 insertions, 67 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
deleted file mode 100644
index 8711182..0000000
--- a/usth/ICT2.7/P4L5 Software Refactoring Subtitles/8 - Collapse Hierarchy - lang_en_vs4.srt
+++ /dev/null
@@ -1,67 +0,0 @@
-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.