Hello and welcome back to my blog! In this blog, I want to discuss YAGNI, which stands for “Ya ain’t gonna need it” or “You aren’t gonna need it.” My professor for CS-343 briefly mentioned it in class one day and I wanted to go over it more in depth. In the past, I’ve done something in my projects where I should have followed the concept of YAGNI instead. I made several methods to change a variable before I actually made the main methods of what that variable would do. In the end, it turns out the methods I made were useless toward my goal and I lost a lot of time. I hope to start applying the concept of YAGNI to my future programming in order to not waste time.

YAGNI is a really important concept in programming. Basically it means programmers and developers should only implement classes, methods, or whatever things they need only when they need them. By doing this, you can avoid doing unnecessary work and save a lot of time. When you think ahead and try to code a class or method that you think you will need in the future, it can be hard to know what exactly you need to include in it. The programmer has to do a lot of guessing and for a lot of the times, they guess incorrectly and end up not needing the feature that they spent some time on in the end. By following the concept of YAGNI instead, you don’t have to do all that guessing work and are also more focused on your current task. You should only develop things that you need once they become relevant. In a large project, YAGNI is especially beneficial for programmers and developers. Let’s say a programmer wants to design a feature they know they might need but aren’t sure if they need it or are unclear of how to implement it. By postponing the development of that feature, it can be more clear to the programmer/developer what they exactly need to do for that feature once it becomes relevant again. You should always ask yourself if the feature you are working on is really needed at the current moment. If it’s not needed, then you can take a note of it instead and come back to it later once it becomes relevant again. That way, you keep the project more simple and you program the features better since they are relevant and you have a more clear understanding of what to implement. And the most important thing, you save a lot of time with YAGNI.

Source: http://c2.com/xp/YouArentGonnaNeedIt.html

From the blog Comfy Blog by Angus Cheng and used with permission of the author. All other rights reserved by the author.

Hello and welcome back to my blog! In this blog, I want to discuss YAGNI, which stands for “Ya ain’t gonna need it” or “You aren’t gonna need it.” My professor for CS-343 briefly mentioned it in class one day and I wanted to go over it more in depth. In the past, I’ve done something in my projects where I should have followed the concept of YAGNI instead. I made several methods to change a variable before I actually made the main methods of what that variable would do. In the end, it turns out the methods I made were useless toward my goal and I lost a lot of time. I hope to start applying the concept of YAGNI to my future programming in order to not waste time.

YAGNI is a really important concept in programming. Basically it means programmers and developers should only implement classes, methods, or whatever things they need only when they need them. By doing this, you can avoid doing unnecessary work and save a lot of time. When you think ahead and try to code a class or method that you think you will need in the future, it can be hard to know what exactly you need to include in it. The programmer has to do a lot of guessing and for a lot of the times, they guess incorrectly and end up not needing the feature that they spent some time on in the end. By following the concept of YAGNI instead, you don’t have to do all that guessing work and are also more focused on your current task. You should only develop things that you need once they become relevant. In a large project, YAGNI is especially beneficial for programmers and developers. Let’s say a programmer wants to design a feature they know they might need but aren’t sure if they need it or are unclear of how to implement it. By postponing the development of that feature, it can be more clear to the programmer/developer what they exactly need to do for that feature once it becomes relevant again. You should always ask yourself if the feature you are working on is really needed at the current moment. If it’s not needed, then you can take a note of it instead and come back to it later once it becomes relevant again. That way, you keep the project more simple and you program the features better since they are relevant and you have a more clear understanding of what to implement. And the most important thing, you save a lot of time with YAGNI.

Source: http://c2.com/xp/YouArentGonnaNeedIt.html

From the blog Comfy Blog by Angus Cheng and used with permission of the author. All other rights reserved by the author.

Do not repeat yourself

This term was coined in 1999 by Dave Thomas and Andy Hunt in the book they created The Programmatic Programmer. The definition they made was like “Every piece of knowledge or logic must have a single, clear representation within a system.” DRY in the use of software engineering, is the principle that has to do with reducing duplication in code, having as main source or “fragment” – that has reusable code in the moments when we need it.

If we are writing a module or even a code, we need to keep in mind the design principles of today and use them wisely. We have to make them our habit, so that we do not have to remember them every time. This will save development time, but also make our software software strong, and in this way we will have it even easier to maintain and expand this software.

DRY Violations- “We enjoy pressing” (or in other words, “Losing everyone ‘s time.”). This phrase means that we can write the same code or logic over and over again.

How to get dry- Less code is good: This saves effort and time for it, it is much easier to maintain, but above all, it reduces the chances of any defect.

Kiss: Keep It Simple, Stupid-KISS Principle is an indicator that shows you how to keep the code clear and simple, to make it as easy to understand as possible. However in general programming languages should be as understandable as possible by humans, because computers the only way they can understand is only with 0 and 1. Therefore we must keep the coding as simple as possible but also direct. We should keep our methods no matter how small, but these methods should not always contain more than 40-50 lines.

KISS Violations – It is very likely that we have all experienced a situation where we need to work on a project and have found a code written incorrectly. This makes us wonder why we wrote these unnecessary lines.

How to reach KISS- To avoid violations of the KISS principle, we should try to write a code as simple as possible and transform it into our code.

The benefit of KISS- If we have some functionalities written by a developer if it is written in irregular code, and at the same time we want another developer to make the modification in the same code, then first they have to understand the code.

If we have not yet discovered a productivity system, most of these may sound familiar.  The only difference here is that we have a process approach with a laser focus that is in unnecessary duplication.

Some of the tasks that rarely come up are:

-Increase tasks that are similar but unplanned, such as handling a customer complaint.

-Let’s not forget the annual tasks (or even the monthly ones, in cases when they are followed for a single week): such as billing, inspections, audits, greater maintenance.

– Ask others about their routine tasks. This helps us to fill the gaps.

References

https://henriquesd.medium.com/dry-kiss-yagni-principles-1ce09d9c601f

https://ardalis.com/don%E2%80%99t-repeat-yourself/

https://blog.softhints.com/programming-principles-and-best-practices-dry-kiss/#kisskeepitshortandsimple

From the blog CS@worcester – Xhulja's Blogs by xmurati and used with permission of the author. All other rights reserved by the author.

Hello and welcome back to my blog! In this blog, I want to discuss YAGNI, which stands for “Ya ain’t gonna need it” or “You aren’t gonna need it.” My professor for CS-343 briefly mentioned it in class one day and I wanted to go over it more in depth. In the past, I’ve done something in my projects where I should have followed the concept of YAGNI instead. I made several methods to change a variable before I actually made the main methods of what that variable would do. In the end, it turns out the methods I made were useless toward my goal and I lost a lot of time. I hope to start applying the concept of YAGNI to my future programming in order to not waste time.

YAGNI is a really important concept in programming. Basically it means programmers and developers should only implement classes, methods, or whatever things they need only when they need them. By doing this, you can avoid doing unnecessary work and save a lot of time. When you think ahead and try to code a class or method that you think you will need in the future, it can be hard to know what exactly you need to include in it. The programmer has to do a lot of guessing and for a lot of the times, they guess incorrectly and end up not needing the feature that they spent some time on in the end. By following the concept of YAGNI instead, you don’t have to do all that guessing work and are also more focused on your current task. You should only develop things that you need once they become relevant. In a large project, YAGNI is especially beneficial for programmers and developers. Let’s say a programmer wants to design a feature they know they might need but aren’t sure if they need it or are unclear of how to implement it. By postponing the development of that feature, it can be more clear to the programmer/developer what they exactly need to do for that feature once it becomes relevant again. You should always ask yourself if the feature you are working on is really needed at the current moment. If it’s not needed, then you can take a note of it instead and come back to it later once it becomes relevant again. That way, you keep the project more simple and you program the features better since they are relevant and you have a more clear understanding of what to implement. And the most important thing, you save a lot of time with YAGNI.

Source: http://c2.com/xp/YouArentGonnaNeedIt.html

From the blog Comfy Blog by Angus Cheng and used with permission of the author. All other rights reserved by the author.

Hello and welcome back to my blog! In this blog, I want to discuss YAGNI, which stands for “Ya ain’t gonna need it” or “You aren’t gonna need it.” My professor for CS-343 briefly mentioned it in class one day and I wanted to go over it more in depth. In the past, I’ve done something in my projects where I should have followed the concept of YAGNI instead. I made several methods to change a variable before I actually made the main methods of what that variable would do. In the end, it turns out the methods I made were useless toward my goal and I lost a lot of time. I hope to start applying the concept of YAGNI to my future programming in order to not waste time.

YAGNI is a really important concept in programming. Basically it means programmers and developers should only implement classes, methods, or whatever things they need only when they need them. By doing this, you can avoid doing unnecessary work and save a lot of time. When you think ahead and try to code a class or method that you think you will need in the future, it can be hard to know what exactly you need to include in it. The programmer has to do a lot of guessing and for a lot of the times, they guess incorrectly and end up not needing the feature that they spent some time on in the end. By following the concept of YAGNI instead, you don’t have to do all that guessing work and are also more focused on your current task. You should only develop things that you need once they become relevant. In a large project, YAGNI is especially beneficial for programmers and developers. Let’s say a programmer wants to design a feature they know they might need but aren’t sure if they need it or are unclear of how to implement it. By postponing the development of that feature, it can be more clear to the programmer/developer what they exactly need to do for that feature once it becomes relevant again. You should always ask yourself if the feature you are working on is really needed at the current moment. If it’s not needed, then you can take a note of it instead and come back to it later once it becomes relevant again. That way, you keep the project more simple and you program the features better since they are relevant and you have a more clear understanding of what to implement. And the most important thing, you save a lot of time with YAGNI.

Source: http://c2.com/xp/YouArentGonnaNeedIt.html

From the blog Comfy Blog by Angus Cheng and used with permission of the author. All other rights reserved by the author.

Hello and welcome back to my blog! In this blog, I want to discuss YAGNI, which stands for “Ya ain’t gonna need it” or “You aren’t gonna need it.” My professor for CS-343 briefly mentioned it in class one day and I wanted to go over it more in depth. In the past, I’ve done something in my projects where I should have followed the concept of YAGNI instead. I made several methods to change a variable before I actually made the main methods of what that variable would do. In the end, it turns out the methods I made were useless toward my goal and I lost a lot of time. I hope to start applying the concept of YAGNI to my future programming in order to not waste time.

YAGNI is a really important concept in programming. Basically it means programmers and developers should only implement classes, methods, or whatever things they need only when they need them. By doing this, you can avoid doing unnecessary work and save a lot of time. When you think ahead and try to code a class or method that you think you will need in the future, it can be hard to know what exactly you need to include in it. The programmer has to do a lot of guessing and for a lot of the times, they guess incorrectly and end up not needing the feature that they spent some time on in the end. By following the concept of YAGNI instead, you don’t have to do all that guessing work and are also more focused on your current task. You should only develop things that you need once they become relevant. In a large project, YAGNI is especially beneficial for programmers and developers. Let’s say a programmer wants to design a feature they know they might need but aren’t sure if they need it or are unclear of how to implement it. By postponing the development of that feature, it can be more clear to the programmer/developer what they exactly need to do for that feature once it becomes relevant again. You should always ask yourself if the feature you are working on is really needed at the current moment. If it’s not needed, then you can take a note of it instead and come back to it later once it becomes relevant again. That way, you keep the project more simple and you program the features better since they are relevant and you have a more clear understanding of what to implement. And the most important thing, you save a lot of time with YAGNI.

Source: http://c2.com/xp/YouArentGonnaNeedIt.html

From the blog Comfy Blog by Angus Cheng and used with permission of the author. All other rights reserved by the author.

Hello,

I am doing some class activities and looking over some questions ahead to save time for a thing or two. I came across the word “Behavioral Patterns” in class Act. 4 (Model 8); I got curious and looked it up. I found two articles that helped me understand the purposes, Problems with solutions, Real-World Analogy, Structure, Pseudo-code, Applicability, How to Implement, Pros and Cons, Relations with Other Patterns.

The Behavioral Patterns are concerned with providing solutions. It is about object interaction – how they communicate, how some are dependent on others, how to separate them to be both dependent and independent, and give both flexibility and testing capabilities—also, the assignment of responsibilities between objects.

The Behavioral Patterns cover many small parts to form the full extend of patterns. Like Interpreter, Template Method/Pattern, Chain of Responsibility, Command, Iterator, Mediator, Memento, Observer, State, Strategy, and Visitor.

Interpreter

The Interpreter pattern: Evaluate any language grammar or expressions. An excellent example; this pattern would be Google Translate, which deciphers the input, and shows us the output in another language. Another example would be the Java compiler. The compiler interprets Java code and translates it into byte-code that the JVM uses to perform operations on the device it runs on. Also, it represents a great way to write simple programs that understand human-like syntax. 

Chain of Responsibility – pass requests along a chain of handlers. Upon receiving a request, each handler processes the requestor gives it to the next handler in the chain. 

Command – Turns a request into a stand-alone object that contains all information about the proposal. This transformation lets pass requests as a method arguments, delay or queue a request’s execution, and support undo-able operations. 

Iterator – traverse elements of a collection without exposing its underlying representation (list, stack, tree, etc.)

Mediator – it reduces chaotic dependencies between objects. The pattern restricts direct communications between the entities and forces them to collaborate only via a mediator object.

Memento – it saves and restores the previous state of an object without revealing the details of its implementation.

Observer – define a subscription mechanism to notify multiple objects about any events to the observed entity.

State – lets an object alter its behavior when its internal state changes. It appears as if the thing changed its class.

Strategy – define a family of algorithms, put them into a separate class, and make their objects interchangeable.

Template Method – the outline of an algorithm in the super-class but lets sub-classes revoke exact steps of the algorithm without modifying its structure.

Visitor – It separates algorithms from the objects on which they operate.

From the blog Andrew Lam’s little blog by Andrew Lam and used with permission of the author. All other rights reserved by the author.

Hello,

I am doing some class activities and looking over some questions ahead to save time for a thing or two. I came across the word “Behavioral Patterns” in class Act. 4 (Model 8); I got curious and looked it up. I found two articles that helped me understand the purposes, Problems with solutions, Real-World Analogy, Structure, Pseudo-code, Applicability, How to Implement, Pros and Cons, Relations with Other Patterns.

The Behavioral Patterns are concerned with providing solutions. It is about object interaction – how they communicate, how some are dependent on others, how to separate them to be both dependent and independent, and give both flexibility and testing capabilities—also, the assignment of responsibilities between objects.

The Behavioral Patterns cover many small parts to form the full extend of patterns. Like Interpreter, Template Method/Pattern, Chain of Responsibility, Command, Iterator, Mediator, Memento, Observer, State, Strategy, and Visitor.

Interpreter

The Interpreter pattern: Evaluate any language grammar or expressions. An excellent example; this pattern would be Google Translate, which deciphers the input, and shows us the output in another language. Another example would be the Java compiler. The compiler interprets Java code and translates it into byte-code that the JVM uses to perform operations on the device it runs on. Also, it represents a great way to write simple programs that understand human-like syntax. 

Chain of Responsibility – pass requests along a chain of handlers. Upon receiving a request, each handler processes the requestor gives it to the next handler in the chain. 

Command – Turns a request into a stand-alone object that contains all information about the proposal. This transformation lets pass requests as a method arguments, delay or queue a request’s execution, and support undo-able operations. 

Iterator – traverse elements of a collection without exposing its underlying representation (list, stack, tree, etc.)

Mediator – it reduces chaotic dependencies between objects. The pattern restricts direct communications between the entities and forces them to collaborate only via a mediator object.

Memento – it saves and restores the previous state of an object without revealing the details of its implementation.

Observer – define a subscription mechanism to notify multiple objects about any events to the observed entity.

State – lets an object alter its behavior when its internal state changes. It appears as if the thing changed its class.

Strategy – define a family of algorithms, put them into a separate class, and make their objects interchangeable.

Template Method – the outline of an algorithm in the super-class but lets sub-classes revoke exact steps of the algorithm without modifying its structure.

Visitor – It separates algorithms from the objects on which they operate.

From the blog Andrew Lam’s little blog by Andrew Lam and used with permission of the author. All other rights reserved by the author.

Hello,

I am doing some class activities and looking over some questions ahead to save time for a thing or two. I came across the word “Behavioral Patterns” in class Act. 4 (Model 8); I got curious and looked it up. I found two articles that helped me understand the purposes, Problems with solutions, Real-World Analogy, Structure, Pseudo-code, Applicability, How to Implement, Pros and Cons, Relations with Other Patterns.

The Behavioral Patterns are concerned with providing solutions. It is about object interaction – how they communicate, how some are dependent on others, how to separate them to be both dependent and independent, and give both flexibility and testing capabilities—also, the assignment of responsibilities between objects.

The Behavioral Patterns cover many small parts to form the full extend of patterns. Like Interpreter, Template Method/Pattern, Chain of Responsibility, Command, Iterator, Mediator, Memento, Observer, State, Strategy, and Visitor.

Interpreter

The Interpreter pattern: Evaluate any language grammar or expressions. An excellent example; this pattern would be Google Translate, which deciphers the input, and shows us the output in another language. Another example would be the Java compiler. The compiler interprets Java code and translates it into byte-code that the JVM uses to perform operations on the device it runs on. Also, it represents a great way to write simple programs that understand human-like syntax. 

Chain of Responsibility – pass requests along a chain of handlers. Upon receiving a request, each handler processes the requestor gives it to the next handler in the chain. 

Command – Turns a request into a stand-alone object that contains all information about the proposal. This transformation lets pass requests as a method arguments, delay or queue a request’s execution, and support undo-able operations. 

Iterator – traverse elements of a collection without exposing its underlying representation (list, stack, tree, etc.)

Mediator – it reduces chaotic dependencies between objects. The pattern restricts direct communications between the entities and forces them to collaborate only via a mediator object.

Memento – it saves and restores the previous state of an object without revealing the details of its implementation.

Observer – define a subscription mechanism to notify multiple objects about any events to the observed entity.

State – lets an object alter its behavior when its internal state changes. It appears as if the thing changed its class.

Strategy – define a family of algorithms, put them into a separate class, and make their objects interchangeable.

Template Method – the outline of an algorithm in the super-class but lets sub-classes revoke exact steps of the algorithm without modifying its structure.

Visitor – It separates algorithms from the objects on which they operate.

From the blog Andrew Lam’s little blog by Andrew Lam and used with permission of the author. All other rights reserved by the author.

Hello,

I am doing some class activities and looking over some questions ahead to save time for a thing or two. I came across the word “Behavioral Patterns” in class Act. 4 (Model 8); I got curious and looked it up. I found two articles that helped me understand the purposes, Problems with solutions, Real-World Analogy, Structure, Pseudo-code, Applicability, How to Implement, Pros and Cons, Relations with Other Patterns.

The Behavioral Patterns are concerned with providing solutions. It is about object interaction – how they communicate, how some are dependent on others, how to separate them to be both dependent and independent, and give both flexibility and testing capabilities—also, the assignment of responsibilities between objects.

The Behavioral Patterns cover many small parts to form the full extend of patterns. Like Interpreter, Template Method/Pattern, Chain of Responsibility, Command, Iterator, Mediator, Memento, Observer, State, Strategy, and Visitor.

Interpreter

The Interpreter pattern: Evaluate any language grammar or expressions. An excellent example; this pattern would be Google Translate, which deciphers the input, and shows us the output in another language. Another example would be the Java compiler. The compiler interprets Java code and translates it into byte-code that the JVM uses to perform operations on the device it runs on. Also, it represents a great way to write simple programs that understand human-like syntax. 

Chain of Responsibility – pass requests along a chain of handlers. Upon receiving a request, each handler processes the requestor gives it to the next handler in the chain. 

Command – Turns a request into a stand-alone object that contains all information about the proposal. This transformation lets pass requests as a method arguments, delay or queue a request’s execution, and support undo-able operations. 

Iterator – traverse elements of a collection without exposing its underlying representation (list, stack, tree, etc.)

Mediator – it reduces chaotic dependencies between objects. The pattern restricts direct communications between the entities and forces them to collaborate only via a mediator object.

Memento – it saves and restores the previous state of an object without revealing the details of its implementation.

Observer – define a subscription mechanism to notify multiple objects about any events to the observed entity.

State – lets an object alter its behavior when its internal state changes. It appears as if the thing changed its class.

Strategy – define a family of algorithms, put them into a separate class, and make their objects interchangeable.

Template Method – the outline of an algorithm in the super-class but lets sub-classes revoke exact steps of the algorithm without modifying its structure.

Visitor – It separates algorithms from the objects on which they operate.

From the blog Andrew Lam’s little blog by Andrew Lam and used with permission of the author. All other rights reserved by the author.