# Open-Closed Principle

Published on Jul 21st 2021Duration: 26:48Watch on YouTube

Jason, Huiqi and I discuss the open-closed principle while relating it to the law of leaky abstractions. We use Uncle Bob Martin's paper as a reference. We introduce the concept as well as talk about where its applicable as well as its limitations. If you are following along, I strongly encourage you to read the paper yourself: https://drive.google.com/file/d/0BwhCYaYDn8EgN2M5MTkwM2EtNWFkZC00ZTI3LWFjZTUtNTFhZGZiYmUzODc1/view?resourcekey=0-FsS837CGML599A_o5D-nAw Part 2 of this conversation can be found here: https://youtu.be/VIdJ-XcQcKY.

## Transcript

The following transcript was automatically generated by an algorithm.

• 00:00 : hi there uh in this video i'm going to
• 00:03 : chat with
• 00:04 : jason bonninger and huiji joe my friends
• 00:08 : and colleagues
• 00:09 : about the open close principle in
• 00:11 : particular
• 00:12 : we're going to be discussing a paper by
• 00:14 : robert martin called the open close
• 00:17 : principle and was published in the c
• 00:19 : plus plus report if you want to follow
• 00:21 : along
• 00:22 : and read this paper yourself i i
• 00:24 : recommend you
• 00:25 : go to the wikipedia article for the open
• 00:29 : close principle and then
• 00:33 : list and click into here
• 00:37 : and there you can read this paper for
• 00:40 : yourself and decide
• 00:42 : for yourself uh what your opinions are
• 00:45 : uh without further ado enjoy our
• 00:47 : conversation
• 00:48 : huichi and i we had a couple of
• 00:55 : and the last time we kind of left off
• 00:58 : with
• 00:59 : um hey what can we do about leaky
• 01:03 : abstractions
• 01:04 : if it is a problem and then we
• 01:09 : we went in the direction of
• 01:13 : hey there's this thing called the open
• 01:15 : close principle
• 01:16 : and i think that would be a good thing
• 01:18 : to talk about because it is
• 01:19 : an approach that is trying to address
• 01:22 : some of the issues of leaky
• 01:23 : abstractions but before we start i kind
• 01:25 : of want to get
• 01:27 : get jason's thoughts about
• 01:30 : this concept of leaky abstractions what
• 01:35 : think
• 01:35 : it means for us as developers i really
• 01:38 : like the article i think it's like a
• 01:40 : great problem statement
• 01:42 : um because it's very real like the http
• 01:45 : issue
• 01:47 : definitely strikes home where you
• 01:50 : you know we don't understand a lot of
• 01:52 : what's happening and it's
• 01:53 : pretty crazy but most of the time it
• 01:55 : just kind of magically works
• 01:56 : and that's really great to be able to
• 01:58 : trust that yeah i really liked it i
• 02:00 : think
• 02:01 : it is one of the fundamental challenges
• 02:03 : of writing software that you just don't
• 02:05 : really get away from like you don't
• 02:06 : learn out of it
• 02:08 : it's just something that we always have
• 02:09 : to deal with and decide
• 02:11 : how best to compromise on and that
• 02:14 : i think is like kind of what makes us a
• 02:17 : good or not good
• 02:18 : developer because you're always having
• 02:20 : to do it
• 02:21 : so let's let's dig into the
• 02:25 : this paper by uh
• 02:28 : bob martin um called the
• 02:31 : open closed principle so at software
• 02:33 : entities
• 02:35 : uh classes modules functions etc should
• 02:38 : be open for
• 02:39 : extension but closed for modification
• 02:42 : i first read this um i don't know if i
• 02:46 : ever got
• 02:50 : his solid principles and this is
• 02:53 : one of his five solid principles
• 02:56 : is the o of the solid the open close
• 03:00 : principles and there's four
• 03:01 : others but this one kind of stood
• 03:05 : in my mind the most i i like the way
• 03:09 : that
• 03:09 : this statement reads it's like open for
• 03:13 : extension but close for
• 03:15 : modification why do you think this is a
• 03:17 : good idea first of all
• 03:19 : for me it makes me think of like a
• 03:22 : probably an even higher level concept of
• 03:25 : you know when you
• 03:26 : create any kind of public api you
• 03:30 : really ultimately then can't change what
• 03:32 : you've released publicly
• 03:34 : because if you change the way that
• 03:35 : behavior works
• 03:37 : then or remove it then you just you
• 03:39 : break dependencies
• 03:41 : you kind of have to design that way and
• 03:42 : i think this is like really expanding
• 03:44 : that
• 03:44 : so it makes sense to me so like yeah
• 03:48 : you publish an api or you publish a
• 03:51 : library that other people are gonna
• 03:54 : and if you republish it and break stuff
• 03:58 : it could be a problem from a point of
• 04:00 : view of your own
• 04:01 : code base what would it give you to
• 04:05 : within your own private code base are
• 04:08 : there any benefits
• 04:09 : to using this by yourself when i see a
• 04:12 : git diff
• 04:13 : where it's like all green that usually
• 04:15 : feels like pretty good
• 04:17 : in general because you've
• 04:21 : added some feature functionality to your
• 04:23 : code
• 04:24 : but you haven't changed any lines
• 04:27 : i mean in general um
• 04:31 : and i think again that's kind of what
• 04:32 : this is touting is if you can
• 04:35 : if you can make your code base you can
• 04:37 : build it in such a way where you only
• 04:39 : add to it but you don't actually change
• 04:41 : what's there in theory
• 04:42 : you would have a very reliable code base
• 04:45 : because
• 04:46 : you're only adding more and more
• 04:47 : functionality but the existing stuff
• 04:50 : you're not tweaking or changing so you
• 04:52 : don't risk introducing bugs
• 04:54 : so what you're pointing to is that when
• 04:56 : you change existing code you can break
• 04:58 : stuff
• 04:59 : yeah sweat so yeah
• 05:02 : that's a like if you see a lot of red
• 05:04 : well you're modifying
• 05:06 : a lot of code so that risks break stuff
• 05:10 : and
• 05:10 : would you just say it's fair that like
• 05:12 : the the mo the motivation for not
• 05:14 : modifying anything is you just don't
• 05:18 : want to
• 05:18 : introduce any breakage and i think to be
• 05:20 : even maybe
• 05:21 : a little bit more specific about it like
• 05:23 : breakage is obviously bad but also
• 05:26 : even just a change of behavior like
• 05:28 : maybe it's not throwing an error
• 05:29 : or maybe it's even acting relatively
• 05:31 : correctly but
• 05:33 : previously it was doing it this way and
• 05:35 : now it's doing it just a little bit
• 05:36 : different and if any of your
• 05:37 : dependencies
• 05:38 : you know have made that assumption then
• 05:40 : you can obviously mess with them
• 05:43 : unintentional or not yeah to me
• 05:46 : to me i i guess i kind of questioning
• 05:49 : like what does
• 05:50 : modification mean because the
• 05:53 : modification can mean modification of an
• 05:56 : interface which as from what jason said
• 05:59 : it's like oh once you publish the
• 06:00 : interface
• 06:01 : of course you can change it otherwise
• 06:03 : you would break the
• 06:05 : uh compatibility but what if if i don't
• 06:08 : change the
• 06:09 : interface but i just modif modify
• 06:11 : internally for whatever reason
• 06:13 : does that count as this it counts as
• 06:15 : modification
• 06:20 : i'll just read this part that says when
• 06:22 : a single change
• 06:24 : to a program results in a cascade of
• 06:27 : changes to dependent modules
• 06:30 : that program exhibits the undesirable
• 06:33 : attributes that we have
• 06:35 : come to associate with bad design
• 06:39 : but if you change the internal of the
• 06:41 : layer you wouldn't
• 06:43 : cascade the change because your
• 06:45 : interface
• 06:46 : doesn't change that's a good point he
• 06:48 : doesn't explicitly say
• 06:50 : he's avoiding modification because he
• 06:53 : wants to
• 06:54 : avoid bugs actually and if you
• 06:57 : saw him say that please let me know but
• 07:00 : i don't think he actually says that
• 07:02 : but but i i still get the feeling that
• 07:06 : implicitly that's a big part of it
• 07:09 : so i'm i'm reading between the lines but
• 07:12 : what he points to more specifically is
• 07:15 : like
• 07:16 : well you change this one thing then you
• 07:17 : have to go change that other thing and
• 07:19 : then you have to go change that other
• 07:20 : thing
• 07:24 : is
• 07:24 : that's sort of what he's proposing he's
• 07:26 : saying we can come up with a design
• 07:28 : where you can extend it but you
• 07:31 : you don't have to change the internals
• 07:33 : basically
• 07:35 : um and then one way of doing that is by
• 07:37 : using
• 07:38 : interfaces as the protocols where the
• 07:42 : different components are going to talk
• 07:43 : to each other but there are different
• 07:45 : ways as well
• 07:46 : i want to say two things uh the first is
• 07:48 : this uh statement
• 07:50 : uh made me feel like uh
• 07:53 : software developer development that's
• 07:55 : different from like other things like
• 07:57 : say
• 07:57 : engineering and car is software changes
• 07:59 : so fast
• 08:01 : so i think this statement is there is
• 08:03 : because we change things so fast so we
• 08:05 : need to come up with a way to
• 08:08 : we can easily adjust to like a change
• 08:12 : request uh that's why we have that but i
• 08:15 : feel like
• 08:15 : the limitation is also always there is
• 08:18 : like how do you know how do you
• 08:20 : see what is the change request because
• 08:22 : of course you can
• 08:24 : try your best to predict what the change
• 08:26 : is and then you can leave that
• 08:27 : open but i feel like you can never
• 08:30 : predict
• 08:31 : everything so there will always be the
• 08:34 : case that you possibly you have to make
• 08:35 : the modification
• 08:37 : yeah yeah that's one dot and then the
• 08:40 : second dot is not related to the first
• 08:42 : stop the second dot is
• 08:43 : there is like a popular uh concern of
• 08:46 : using libraries versus
• 08:48 : using like a server which uh which is
• 08:51 : like say if you use certain code as a
• 08:54 : library
• 08:55 : you have to think more about how the
• 08:58 : code connect to each other
• 09:00 : because say if the library
• 09:06 : like the library got changed and your
• 09:08 : code might have to change because so
• 09:10 : if you use a piece of code as libraries
• 09:12 : that then
• 09:13 : the uh the connection point is much
• 09:16 : larger than say if you just use
• 09:18 : something as
• 09:19 : pure service because the service only
• 09:21 : have
• 09:22 : a abstract api say if you make an api
• 09:26 : call to
• 09:27 : do something then this interface is
• 09:30 : relatively small
• 09:31 : but sometimes the library because you're
• 09:34 : using the code itself
• 09:36 : so the interface is uh i shouldn't say
• 09:38 : that in
• 09:39 : because this interface it doesn't mean
• 09:41 : that like interface in terms of coding
• 09:45 : point is much more complicated so you
• 09:47 : have to think more about
• 09:49 : backward compatibility and things like
• 09:50 : that but if it's just calling service i
• 09:52 : don't care
• 09:53 : how the other end works yeah
• 09:56 : okay uh you're basically saying when you
• 10:00 : bring in a library
• 10:03 : you tend to depend on the library
• 10:06 : more yeah there also tells me like um
• 10:09 : the library tends to have a larger
• 10:11 : surface area in the like
• 10:14 : the amount that you're touching the
• 10:16 : library yeah i have
• 10:18 : examples yeah in my current work
• 10:21 : situation
• 10:21 : so we have an automation testing like
• 10:24 : team
• 10:25 : those people are using java
• 10:29 : and then each team will also use
• 10:32 : java to write your own automation
• 10:34 : testing for
• 10:35 : your app and then this automation
• 10:38 : testing team
• 10:39 : will use their java code to bring
• 10:42 : our say my team's java code as a sub
• 10:45 : module
• 10:46 : which means their code is going to
• 10:47 : directly call
• 10:49 : my code well then one day
• 10:53 : we decided saying hey i want to upgrade
• 10:55 : my java version to
• 10:58 : a higher java version and they break and
• 11:00 : their code can never call
• 11:02 : our java code anymore unless they modify
• 11:05 : their code
• 11:06 : so that is the problem but if they call
• 11:08 : us as a service
• 11:10 : they just and then we will run our code
• 11:13 : on
• 11:14 : our own and then they don't they
• 11:15 : wouldn't care
• 11:17 : which java version we're in and things
• 11:19 : like that
• 11:21 : okay yeah so that's the example
• 11:24 : this is more dependencies yeah um
• 11:27 : there's more point to failure that
• 11:30 : you're more
• 11:30 : intimately dependent on that library
• 11:34 : uh and and that tends to happen more
• 11:37 : with code libraries than api
• 11:41 : calls yeah although you there are code
• 11:43 : libraries that have
• 11:44 : a small surface area as well i would i
• 11:47 : would say
• 11:48 : like like if you if you just bring in a
• 11:50 : library
• 11:52 : that generates uuids for you that
• 11:55 : that's a very small service area for a
• 11:58 : library so
• 11:59 : it's dependent on what the library is
• 12:02 : trying to do
• 12:02 : or how many features the library is
• 12:05 : trying to provide for you
• 12:06 : coming back to your first point we're
• 12:08 : always gonna have new
• 12:10 : change requests that cause
• 12:13 : you to have to change something you can
• 12:16 : never predict
• 12:17 : everything that's going to happen but at
• 12:19 : the same time you want to have
• 12:21 : relative stability because if everything
• 12:24 : is unstable that means
• 12:27 : you're gonna have to change a lot of
• 12:29 : code all the time
• 12:31 : to to implement any new feature
• 12:34 : and that that's gonna be very costly
• 12:38 : so the relative stability is i think
• 12:40 : what
• 12:41 : this open close principle is going for
• 12:43 : right you want
• 12:44 : stability despite the fast-paced
• 12:48 : changes in requirement so basically what
• 12:50 : we're saying is we're going to give you
• 12:53 : these extension points with which you
• 12:56 : can
• 12:56 : sort of plug in these these placeholders
• 12:59 : right um for functionality and and this
• 13:03 : example is like
• 13:05 : i have a square or a circle how to draw
• 13:08 : a square
• 13:09 : or how to draw a circle that
• 13:12 : that depends on what shape it is how to
• 13:14 : draw the thing depends on what shape it
• 13:16 : is
• 13:16 : and that's going to be a different piece
• 13:18 : of code
• 13:20 : to draw a square which is draw a circle
• 13:22 : so what you could do
• 13:24 : is do a switch statement and see which
• 13:26 : one
• 13:27 : it is and then call the appropriate
• 13:29 : function
• 13:30 : or you can make the drawing part
• 13:34 : an extension point that that is like a
• 13:36 : placeholder
• 13:38 : and the implementation of the shape
• 13:40 : whoever is going to come in and
• 13:42 : implement the shape
• 13:44 : will provide the draw function
• 13:47 : which i believe is what the next one is
• 13:50 : yeah so
• 13:51 : if you're gonna implement the square
• 13:52 : you're gonna have to provide
• 13:54 : how to draw the square if you're gonna
• 13:56 : implement the circle you're gonna have
• 13:58 : to provide how to
• 13:59 : draw the circle and if later on somebody
• 14:01 : provides a triangle
• 14:03 : they would have to provide how to draw
• 14:05 : the triangle that's the solution
• 14:10 : what do you think does that solve our
• 14:12 : problems actually
• 14:14 : uh circle back to what jason said about
• 14:16 : earlier
• 14:18 : we just we have this function called
• 14:21 : draw all
• 14:21 : shapes and that function is going to be
• 14:24 : stable
• 14:26 : for any new instances of shapes that you
• 14:30 : add to the code that you add a triangle
• 14:33 : this function doesn't have to change at
• 14:35 : all
• 14:36 : because because the triangle is going to
• 14:38 : provide its own draw
• 14:40 : method and that just kind of plugs
• 14:43 : right into here to to jason's point like
• 14:46 : you're just gonna see green right you're
• 14:49 : just gonna see
• 14:50 : a file that's all addition uh
• 14:53 : relative to the logic that's needed for
• 14:56 : the triangle but the existing stuff
• 14:57 : didn't change
• 14:59 : uh so my question is does that solve our
• 15:01 : problem i
• 15:02 : i have a thought yeah
• 15:06 : i think it's the main thing that is like
• 15:09 : to me the
• 15:10 : uh the opposite of this issue i guess
• 15:12 : that's probably going bad to leaky
• 15:14 : abstractions which is why that's the
• 15:16 : other subject we're talking about
• 15:18 : is that this open close principle says
• 15:21 : well if you just if you abstract it
• 15:23 : then we never have to change because
• 15:26 : everybody just implements their draw
• 15:27 : method
• 15:28 : and that's great and and then we just
• 15:29 : call the draw method you can implement
• 15:31 : whatever you want
• 15:32 : on the flip side i think that is
• 15:33 : actually a huge negative that you can
• 15:35 : implement
• 15:36 : whatever you want um because
• 15:39 : even though it would be wonderful if our
• 15:41 : code was just incredibly modular
• 15:44 : only did exactly one thing all the time
• 15:46 : and we're always striving for that
• 15:48 : oftentimes in reality the fact is that
• 15:50 : draw method is going to have to be a lot
• 15:52 : more complex
• 15:54 : than just this perfect little unit of
• 15:57 : i'm going to draw something
• 15:58 : and you know you always have the risk of
• 16:01 : other developers
• 16:02 : perhaps less experienced developers but
• 16:04 : perhaps more experienced developers who
• 16:05 : have a need
• 16:06 : you know doing something around that
• 16:09 : abstraction
• 16:10 : that you know it works for every shape
• 16:12 : but it doesn't work for this one
• 16:14 : and that can be a very like difficult to
• 16:17 : track down bug and also very difficult
• 16:19 : to manage because all you've said
• 16:21 : is you get to execute some code at this
• 16:24 : time
• 16:25 : i just want to add to jason's point
• 16:27 : which is
• 16:28 : how do you draw the line of what
• 16:32 : kind of code you want to put in the draw
• 16:34 : all shapes and what
• 16:36 : code you want to put in each for each
• 16:40 : module to take out for example if draw
• 16:42 : has
• 16:42 : a validation of some sort you can't draw
• 16:45 : more than
• 16:47 : 60 square feet where do you put that
• 16:50 : okay all the shapes need to have same
• 16:55 : validation now what
• 16:56 : do you put in draw all shapes or do you
• 16:58 : put it as another interface or like what
• 17:00 : do you do yeah
• 17:02 : camera yeah
• 17:06 : in my ui framework i actually had to
• 17:09 : come up with something to solve that
• 17:11 : problem
• 17:11 : and what i came up with is a concept
• 17:15 : called
• 17:15 : the region and basically the region has
• 17:18 : the job of
• 17:18 : checking the bounds checking if you're
• 17:22 : correctly drawing within the bounds that
• 17:24 : you're allowed to draw in
• 17:26 : and you're going to have to use a method
• 17:28 : on the region object to draw
• 17:31 : so that so that the checking is
• 17:33 : completely enforced
• 17:35 : by the region so so the draw method
• 17:38 : would take a region
• 17:39 : and the shape that needs to draw needs
• 17:41 : to ask the region to draw
• 17:43 : the thing but i think the point is
• 17:45 : though
• 17:46 : when jason was saying hey there might be
• 17:50 : some special case
• 17:52 : where this way of
• 17:55 : specifying the boundaries of what is
• 17:58 : your responsibility versus what is the
• 18:00 : engine's responsibility
• 18:02 : that scheme may not work out for
• 18:05 : whatever reason
• 18:06 : developer has to get it working somehow
• 18:08 : so they're going to cheat
• 18:10 : like in the draw case it may be there
• 18:12 : there's they have
• 18:14 : in addition to drawing they also do
• 18:17 : something that's a side effect
• 18:19 : inside the draw method or something
• 18:21 : weird like that and then
• 18:23 : maybe it works for them the first time
• 18:25 : but later they found out that causes a
• 18:27 : bug somewhere i don't know
• 18:28 : cheating yeah can lead to problems
• 18:35 : would probably say
• 18:37 : well you should introduce another
• 18:39 : extension point
• 18:43 : points
• 18:44 : is not enough to satisfy the new
• 18:48 : requirement and therefore you should
• 18:50 : probably add a new
• 18:51 : extension point to satisfy your scenario
• 18:55 : so that you don't have to cheat does
• 18:57 : that sound right to you jason
• 18:58 : so yes full agreement yeah maybe every
• 19:01 : shape has a
• 19:02 : can draw method that returns a boolean
• 19:04 : and so the loop first calls
• 19:07 : cash can i draw the shape and then if
• 19:08 : they can then it draws
• 19:11 : for for the example but like your
• 19:13 : solution of
• 19:14 : well instead i should actually pass a
• 19:16 : dependency that helps the shape draw
• 19:18 : itself into the draw method
• 19:20 : um is much more elegant and not just
• 19:23 : spit out in two seconds off the cuff and
• 19:25 : like i think that kind of represents the
• 19:27 : challenges
• 19:28 : like you said that developer who maybe
• 19:31 : is less experienced maybe isn't as
• 19:33 : familiar with the architecture
• 19:35 : like then that challenge is to
• 19:38 : like how do you do you even know to
• 19:41 : extend it and if you are extending it
• 19:44 : like if you just throw in a can draw
• 19:46 : method now we have this kandra method
• 19:48 : that everything has to deal with
• 19:49 : whereas it would have been far better to
• 19:51 : implement in a different way
• 19:52 : and now you are talking about making a
• 19:54 : change to everything possibly later
• 19:57 : because you have to because this kandra
• 19:59 : method just isn't doing it
• 20:00 : what you really need to do is like pass
• 20:02 : in a dependency like you're saying
• 20:04 : i mean i i wouldn't necessarily say like
• 20:07 : my method is more correct or anything it
• 20:10 : depends on situation to situation and
• 20:14 : everything is a trade-off but you're
• 20:16 : saying if you
• 20:17 : add a sort of extension point then all
• 20:20 : the existing classes
• 20:21 : have to also add that extension point
• 20:24 : and that's
• 20:25 : that's a cost it becomes a very like
• 20:28 : it's
• 20:28 : very meaningful changing this interface
• 20:32 : which i i think is hard to avoid it's
• 20:35 : not
• 20:35 : just meaningful it's it's a cost in that
• 20:39 : all the existing things have to uh
• 20:42 : adhere to the new standard and all the
• 20:45 : future things
• 20:46 : also have to adhere to the standard and
• 20:49 : also
• 20:49 : in this case you introduce a change to
• 20:52 : the engine as well you have to
• 20:53 : put if can draw in the draw all shapes
• 20:58 : in this case but if you introduce
• 21:02 : is toby's solution can can toby solution
• 21:06 : avoid a change of draw all shapes
• 21:08 : no no because okay i'm proposing add
• 21:12 : a parameter to the draw method
• 21:15 : okay so you in this case yours but you
• 21:17 : don't have to change
• 21:19 : the inner uh implementation
• 21:23 : of draw all shapes do you oh yeah yeah
• 21:26 : you do
• 21:27 : because you have to take the region and
• 21:30 : supply it to
• 21:31 : all of the calls gotcha
• 21:34 : toby i like what you said about you it's
• 21:37 : a cost because it's a cost you're paying
• 21:38 : now
• 21:39 : and in the future and i think we're all
• 21:42 : pretty good at looking at that now cost
• 21:44 : but that future cost is what's scary
• 21:47 : because yeah it's not that your method
• 21:49 : is right or that can draw a method is
• 21:51 : right or some other method of doing it
• 21:52 : is
• 21:52 : right it's just that whatever you decide
• 21:56 : you're gonna yeah so you're gonna have
• 21:58 : an experience
• 21:59 : yeah and because of that cause you're
• 22:01 : kind of worried like what if i make the
• 22:03 : wrong call
• 22:05 : what if i what if i yeah well i make
• 22:08 : this decision
• 22:09 : i have to make the decision today
• 22:11 : because the software is going out on
• 22:13 : friday
• 22:14 : so i have to make a call right now but
• 22:17 : if i
• 22:18 : make a sub optimal call later on i'm
• 22:20 : going to regret it
• 22:22 : and then i want to change it i want to
• 22:23 : remove this one and add a different one
• 22:25 : maybe
• 22:26 : and that's another cost that we're gonna
• 22:28 : have to incur
• 22:30 : so it gives you pause to do something
• 22:33 : like this
• 22:34 : is a developer that's not as experienced
• 22:37 : that they probably wouldn't even think
• 22:40 : of
• 22:41 : extending the protocol they're not
• 22:44 : experienced with
• 22:45 : doing that kind of thing this higher
• 22:48 : level design
• 22:49 : um that they're just more used to you
• 22:51 : know adhering to whatever the current
• 22:53 : standard is
• 22:56 : so they're not gonna want to do that and
• 22:58 : they're just gonna try to
• 23:01 : cheat and uh and somehow implement it
• 23:04 : with the current standard oh one thing i
• 23:07 : wanted to mention
• 23:09 : that bob did it should be clear that
• 23:13 : no significant program can be 100
• 23:17 : closed and what he means by closed
• 23:21 : is protected from modification
• 23:25 : like he would use the word close in the
• 23:28 : context of
• 23:30 : hey by by adding this extension point
• 23:34 : uh letting you sort of freely extend
• 23:38 : how to draw any shape you want i have
• 23:41 : closed off my draw or shapes method
• 23:45 : because my draw or shapes will never
• 23:47 : have to change
• 23:49 : as long as this current uh protocol
• 23:53 : works out so we've closed the draw all
• 23:56 : shapes
• 23:57 : but but then right after that he says it
• 24:00 : should be clear that no
• 24:01 : significant program can be 100 closed
• 24:05 : so he's saying you always have possible
• 24:09 : feature requests that causes
• 24:12 : changes that you did not foresee so that
• 24:16 : you still have to change this code
• 24:18 : because of some of the things we said
• 24:20 : earlier
• 24:21 : toby would you say it's fair in general
• 24:24 : to say that
• 24:25 : open close principle the the closed
• 24:27 : piece is focusing
• 24:29 : like on implementation but if you're
• 24:32 : actually talking about
• 24:33 : architecturally redesigning or adding
• 24:35 : architectural features
• 24:36 : to a program you know you're you are
• 24:39 : that's what he's kind of talking about
• 24:40 : you have to step out of it you can't
• 24:42 : just have code that magically doesn't
• 24:43 : change
• 24:44 : forever i would say this is like if code
• 24:47 : can be closed can be protected from
• 24:50 : modification as long as the
• 24:54 : extension points you came up with all
• 24:57 : happen to match the future requirement
• 25:00 : yeah that's true if you are really good
• 25:03 : at predicting
• 25:04 : what variations are going to come
• 25:07 : to the code in the future then you can
• 25:10 : you can be really good at closing off
• 25:15 : but all that depends on the correctness
• 25:19 : of your prediction it depends on whether
• 25:22 : the change requirement is
• 25:24 : to add the functionality of draw stuff
• 25:26 : in order
• 25:27 : versus like oh if i want to change the
• 25:30 : exact order uh which one orders
• 25:33 : uh goes first so that maybe is what
• 25:35 : jason said about implementation
• 25:37 : but this whole functionality is that
• 25:40 : like
• 25:41 : that that is the source of changing the
• 25:44 : engine
• 25:45 : because you still have to put the order
• 25:47 : stuff in the engine
• 25:49 : when this new requirement comes in since
• 25:51 : closure cannot be
• 25:53 : complete it must be strategic so the
• 25:55 : designer must choose
• 25:57 : the kinds of changes against which
• 26:00 : to close his design so yeah
• 26:04 : you have to try to predict well this
• 26:07 : takes a certain
• 26:08 : amount of pre
• 26:11 : what is this word that's precedence
• 26:14 : prescience
• 26:15 : what what is that it's kind of just
• 26:17 : another word for like awareness
• 26:20 : awareness but but more of like a future
• 26:23 : facing awareness okay
• 26:27 : yeah future vision yeah exactly exactly
• 26:29 : what i was saying like
• 26:30 : you need to be good at predicting the
• 26:32 : future
• 26:33 : uh derived from experience yeah that's
• 26:36 : that's fair yeah yeah
• 26:37 : i do agree that with more experience
• 26:40 : you're
• 26:40 : more able to predict the future