Category Archives: CS-343

Don’t Repeat Yourself (DRY)

Source: https://dotnetcodr.com/2013/10/17/the-dont-repeat-yourself-dry-design-principle-in-net-part-1/

For my last week I decided to write about Don’t Repeat Yourself design principle. I found a blog called dotnetcodr and there was this blog about (DRY) written by Andras Nemes where he talks about (DRY). The idea behind (DRY) is that you should not add repetition of logic in multiple places in the code. He talks about the motto that you should be following “Repetition is the root of all software evil.” Repetition does not just refer to writing the same piece of logic in two different places but also the repetition testing, debugging, deployment, ect.

He then gives an example of repetition where he writes out the person and then where the live as well. In this code he hard codes everyone’s name and address. This way it is a very good example of reputation because since he is just copy and pasting whenever he would need to add or remove a person or address he would have to go back into the code and manually change it himself.

I found this blog to be very informative because it is very true you do not want to repeat yourself and the logic of a certain code in multiple places and multiple times. There are times where I do this a lot because I find it much easier to repeat the code since it is going to be the same every time I want to call something. I think the thing I get out of this the most is that I will start to try and not repeat myself when writing code. Also I can use this for future knowledge when I do write things that do call things multiple times and like it shows in the blog we can make stings that have getter and setters that would make a 40 line code down to a 10 line code which would save much more space and time as well.

From the blog CS@Worcester – The Road of CS by Henry_Tang_blog and used with permission of the author. All other rights reserved by the author.

38. How to be a Programmer: Personal and Team Skills

 

Coding blocks podcast is presented by Joe Zack, Michael outlaw and Allen Underwood. In this podcast episode, the gang talks about what it takes for someone to become a good programmer for his company and his team. One thing that is known to be a problem of the technology world is the lack of people with adequate teamwork and collaboration skills. I picked this particular podcast episode because I felt this would help anyone who reads. They talk about personal skills and practices that just makes one a better programmer in the industry. The main problem that occurs during team tasks is estimating how long a coding task will take. You want to please your boss and he also wants to please his boss so understanding each other and establishing that mutual trust makes it easy to work coherently in the task at hand. One challenge that most programming teams experience with their leaders is scope creeping. Scope creeping is a project management term that refers to changes, continuous or uncontrolled growth in a project’s scope, at any point after the project begins. This can occur when the scope of a project is not properly defined, documented, or controlled. It is generally considered harmful. This is because it causes problems and situations that are often not accounted for. Usually with every programming project, specifications are laid out and a timeline estimate is created for people to adhere to but once the scopes begin to change, unaccounted scenarios begin to happen. As a programmer, great communication between team members and leaders brings success to the project. This is because everyone has different level of expertise and often tasks and timelines are drawn based on the programmer’s expertise. Another thing that needs to be accounted for is vacations and sick absences. It’s the task of the programmer and team members to show commitment during tasks. You cannot take a 2 weeks or 1 week vacation when you know that the team is waiting for you to build the baseline site for people to continue developing on. This strings back to the trust issue. Efficient communications has to be open between members of teams to properly resolve issues such as these. Again communication thrives in teams when everyone is on the same level. Usually in teams, everyone has different background and finding that middle ground to communicate effectively helps the team thrive.

 

 

Source

https://player.fm/series/coding-blocks-software-and-web-programming-security-best-practices-microsoft-net/38-how-to-be-a-programmer-personal-and-team-skills

 

From the blog CS@Worcester – Le Blog Spot by Abranti3 Dada Kay and used with permission of the author. All other rights reserved by the author.

Clean Architecture – Components and Component Cohesion

Episode 71

Coding blocks podcast is presented by Joe Zack, Michael outlaw and Allen Underwood. In this podcast episode, they squad begin by talking about components cohesions in architectural designs. Cohesion in software designing refers to the degree to which the elements inside a module belong together. In one sense, it is a measure of the strength of relationship between the methods and data of a class and some unifying purpose or concept served by that class. In another sense, it is a measure of the strength of relationship between the class’s methods and data themselves. Cohesion is an ordinal type of measurement and is usually classified under two categories, “high cohesion” or “low cohesion”. According to the team, there was a principal known as the fish bowl principal, this was employed in system building and architectural design for so many years. It was believed that the fish would eventually grow to fit the bowl it was placed in. But that has changed over time, with services like AWS and other cloud functionality, developing software of any size is easily manageable. Scalability is often handled by high performance systems that allocate resources to where is it needed most and vise versa when it’s not in demand. A big part of this new trend of software reuse is propelled by the open source project that currently runs the software industry. Building components or software in components also propels this new trend of code reuse. This is because in components, code is built to be self-dependent and sufficient to run on its own. It is viewed as a module that fits a part of the big puzzle. Testing for modules and components do not break the original code as it is tested as a single entity that interacts with the overall project. Another topic that gets discussed by the group is the common closure principal. The common closure principle consists of classes that change for the same reason and at the same time. This is similar to the single responsibility principle. This simply means that if the character of the class is changing, then the component is also gonna change. We need to make sure that the component is only changing for one reason only and if there is more than one reason, then there should be more than one component. Overall, this episode went very in-depth to technical practices and techniques that are used to develop components and architecture in software creation. This level of in-depth was a little too much for what we are studying but I felt it was necessary as it gets us thinking about how to build software in components and parts and start learning how to allocate functionalities to individual components.

 

Link – Episode 71

https://player.fm/series/coding-blocks-software-and-web-programming-security-best-practices-microsoft-net

https://en.wikipedia.org/wiki/Cohesion_(computer_science)#frb-inline

 

From the blog CS@Worcester – Le Blog Spot by Abranti3 Dada Kay and used with permission of the author. All other rights reserved by the author.

CS@Worcester – Fun in Function 2017-12-11 23:50:09

The blog post this is written about can be found here.

This week I decided to look into software frameworks, and I picked this blog post because of its concise explanation and because it included advantages and disadvantages to using them.

Software frameworks provide developers with ways to create applications without starting from scratch. Instead of writing every piece of functionality, you only have to write the pieces that are unique to your application. Like a framework for a building under construction, they’re bare-bone essentials for the type of project you want to create. Using a framework allows software to be developed more quickly and with higher quality, as software frameworks are pre-tested. With less to worry about coding and testing themselves, developers can focus on fulfilling their specific requirements instead of reinventing the wheel.

Software frameworks adhere to the inversion of control design principle, in which the general framework instantiates and invokes the objects and methods specific to your application. This contrasts with using a software library, in which a custom application instantiates and invokes the objects and methods that belong to the library.

Some other advantages to using software frameworks, as the blogger writes, are that they can encourage better programming practices and appropriate use of design patterns. Upgrades to the framework can also provide benefits to the framework users without them having to do additional coding of their own. Lastly, software frameworks are by definition extensible.

Among the downsides are that if you wish to create your own software framework, it’s more difficult and time-consuming to create the first application that utilizes it than it would be without the framework. However, if well-made, the development and testing effort will be reduced in all future projects that utilize it.

Another disadvantage is that frameworks can be difficult to learn. This can negate the advantages of the framework for the first project a developer uses it for similarly to how they’re negated for the first project that utilizes a brand new framework. Finally, frameworks can grow increasingly complex over time with updates and additions.

Though they certainly have their disadvantages, software frameworks seem like an intuitive solution to me. If I’m tasked with doing something a hundred times with slight variations, after a while, it only makes sense to find the commonality between all the instances and use that as a base to add the variations to. Additionally, in the future, I will keep an eye out for whether software frameworks are available for the type of project I’m trying to create and use them if the benefits outweigh the effort needed to learn them.

From the blog CS@Worcester – Fun in Function by funinfunction and used with permission of the author. All other rights reserved by the author.

Difference between Abstraction and Encapsulation

From the blog CS@Worcester – Computer Science Exploration by ioplay and used with permission of the author. All other rights reserved by the author.

Encapsulation

Encapsulation is a technique in programming where the programmer hides the internal behavior of the object from the user. Encapsulation hide the inside view of the object from the user such that it only implements the behavior of the object. Usually the client does not need to know the detail of the program and that is exactly what encapsulation does.

Encapsulation hide the data for object and makes the variables as private, and expose only the property to access the private data which would be public. So, when you access the property you can validate the data and set it.

For example, let take a Mobile Phone and Mobile Phone company. Suppose you are a Mobile Phone company and you designed and developed a Mobile Phone design(class), now by using machinery you are making a Mobile Phone(object) for selling, when you sell your Mobile Phone the user only learn how to use the Mobile Phone and not how the Mobile Phone works.

Again, let consider a TV operation for example, the manufacturers encapsulate it with cover and we can only operate it with the remote and have no need to open the TV and change the channel.

In this regard, everything is in private except remote; so anyone can access to operate and change channel and not the things in TV.

Reference:

https://en.wikipedia.org/wiki/Encapsulation_(computer_programming)

 

 

From the blog CS@Worcester – Computer Science Exploration by ioplay and used with permission of the author. All other rights reserved by the author.

My final 343 Post: Abstraction

For the last couple of weeks, I’ve revisited a couple of the most important concepts of Object Oriented Programming, Polymorphism and Encapsulation. This is my final post for my CS-343 blog entries, and I have decided to continue in this trend. Today’s topic is Abstraction. This week I’ve gone to a favorite resource of mine, geeksforgeeks. Their article on Abstraction covers almost every question that comes up with Abstraction.

I feel it is best to first specify what an abstract class is, and how to make use of one. In Java, an abstract class is defined with the abstract keyword. An abstract class cannot be directly instantiated because of the abstract methods inside the class. An abstract method, is a method that does not have an implementation but must be present in all children classes. This is done via overriding the method(s) in the children classes. Only one method has to be abstract, meaning that there may be other methods that have complete implementations that are reused in their entirety by children classes. Similar to how we implement an interface, we extend abstract classes.

Like my other blog posts, I feel that the best way to learn a concept, is through examples. More importantly, the examples need to be practical, and ones we can relate to. For abstraction, the article on geeksforgeeks uses the classic Shape example that we’re all familiar with.

Our abstract class is the Shape, with three methods and one variable, or attribute. Each Shape has a color, getColor method and two abstract methods, area and toString. A Shape fits exactly into what an abstract class should have, and shows exactly what we can know, based on the object simply being a Shape. A Shape has to have a color, but the formulas for finding the area are different depending on the type of Shape, and the same goes with the toString method.

The children classes presented in the example are the Circle and the Rectangle. The UML from the original article even shows the extends declarator for the children classes. It’s important to note that the abstract methods are not rewritten in each of the children classes. This is because we have to implement them, and thus, they are carried over when we apply the extends declarator. The only new pieces of information in the UML are the attributes we can use for our abstract methods, radius for Circle, and length and width for Rectangle. As seen in the code blocks below the UML, these are used to calculate the area and then the toString.

Abstraction is one of the most important tools that any object oriented developer must have in their toolbox of concepts. This is used in almost every full scale application and often numerous times throughout. A lack of understanding of abstraction will lead to failure to excel in the software engineering world.

Original post here:

http://www.geeksforgeeks.org/abstraction-in-java-2/

 

From the blog CS@Worcester – Learning Software Development by Stephen Burke and used with permission of the author. All other rights reserved by the author.