What’s up fellow coders and welcome to Geekific! I’m Ed, a full-time software developer and coding enthusiast. Join me on this never-ending learning journey as we dive into the fascinating world of coding. Whether you're a beginner or an experienced programmer, this channel is dedicated to providing you with valuable insights, tips, and tutorials to help you excel in your coding endeavors. Let's forge a tight-knit community of passionate learners and embark on an exciting coding adventure together!
Now I finally get the reset pointer to start part. We can always assume that the list given to us is defined as such, so that we always have x = z i.e. the distance from head to start of cycle is always the same as distance from meet to start of cycle. So we dont really need to bother with the mathematics or the physics behind it but just accept that its defined as such and whenever there is a cycle, we just reset, move by one and return the meeting point.
Shouldn´t you be returning "this" after every builder method? They all return CarBuilder but then the method is just a setter, this will give an error as "Expected CarBuilder but returned void"
I usually use an interface instead of an abstract class. An Interface means that I am creating a "contract" for all Restaurants and it´s mandatory that all the classes implementing it will implement the createBurguer. An abstract class should be used for generalization of a behaviour, an interface for standardization, this case looks like standardization to me. Meaning: Generalizing: "All these classes seem to work this way, lets sum up common code in a common place" Standardizing: "I want to enforce that all this classes behave this way" What do you think about this approach and why would you favour the use of an abstract class over an interface?
I guess, interfaces enforce a contract, ensuring all implementing classes follow the same methods, making them ideal for standardizing behavior. Abstract classes, however, offer shared code, making them better for generalization when multiple classes need common functionality. They allow partial implementations and can be more flexible when evolving over time. So, imo choose interfaces when you need consistency across classes and abstract classes when you want to combine shared logic with enforced structure. Does this answer your question?
I think you missed the part where the command pattern can be used to undo or redo an operation. Great clips though, I use them as quick summerization guide in addition to the design pattern book (gang of 4).
the first example also violate dependency inversion since the 2 class must depend on abstraction instead of each others .. reducing coupling between the 2 classes
i have rewatched so many times to make sure i have comprehend whats in the 8 mins :). Seasonal devs might grasp quick. Crisp and highly informative videos! thanks.
Great tutorial! I don't think we'll need this pattern as much compared to other structural design patterns like Facade or Bridge. However, the strategy behind this pattern is quite important.
Hello! This video has been helpful! I do wonder if it is better to make createBurger method protected instead of public since the main method can access it and be able to create a burger without ordering it?
I'm slightly confused, so is the metaspace, was the permGeneration, part of the heap? Because you mentioned something about permGen space of the heap, at 6:05.
