Code Maintainability: Context Alters Developer Preferences

The MVC Design pattern encourages developers to create reusable code that flexibly addresses different areas of concern. In the context of the MVC Design pattern, the DRY principle must be applied in a way that is compatible with MVC. The model handles data validation using our enum classes for different data types. A flexible base class allows a developer to extend a class to be used in the model for all data types. Data from the model is returned to the controller. In web-based MVC frameworks, html and css are returned from the view, and the controller manages the data flow request that is returned to a user’s computer. A base Criterion class that subsequent related classes would inherit allows a developer to implement the DRY principle in an effective way. This base class would provide all the foundational and generic functionality for any criterion the application is capable of handling.

This program architecture exemplifies a developer preference that does not contribute to program performance. A developer could organize the logic of this program in many ways so long as the logic exists. Organizing the code in this manner allows experienced developers to quickly and effectively make changes; however, adding more complexity to the organization of your program inherently increases the learning curve for newer developers to onboard with your design pattern. Code complexity always increases the learning curve.

If I utilized the Ruby on Rails MVC framework, I would absolutely separate the logic from the view because that is the design pattern of Ruby on Rails. They would be in different files because Ruby on Rails pushes a developer to utilize the DRY principle while still separating areas of concern into their own model, view, and controller files.

In React (where I like to program), a developer would not separate the logic because the focus is on producing a view. The controller logic remains on the API backend. Different coding languages address areas of concern in different ways. When you first learn about programming, you think there is a right way and a wrong way to resolve a problem. Once you branch out into other programming languages and learn to work on a team, you recognize what is and is not important. React uses concepts such as Sagas and Reducers to address some of the same issues that Java solves with enums. One way is not better than the other.

I would not move the prompts for questions into the criterion class, nor would I use a static method to prompt the user in the criterion class. Although that approach would work, it does not follow the DRY principle. I would create another class that asks the questions: a yes or no question, a comparison question, and a value question. This class would not be tied to any data type but could be used with any data type. This would make our AmplitudeCriterion class smaller and would make our question code reusable. The question classes would consume our criterion classes to instantiate the values collected and return these values to the main thread.

To add a less-than-or-equal-to test for the numeric criteria that are specifiable, a developer would first create a class capable of asking the question, “What kind of comparison would you like to use?” Consequently, we could add comparisons such as equal-to or not equal-to. We prompt the user for input in the question class. We then provide this data to an instance of the criterion class. In the question class, we would ask for the searchable value. The question class would then have the result of that question instantiate our actual data variable with the result. This may not be how I would initially approach the problem; however, the size of the program you intend on building dictates how far you would be willing to push the DRY principle. For small programs, it’s difficult to visualize increasing developer time and learning curve in the name of code organization which complicates a simple piece of code with many files and unnecessary code abstraction.

The larger a program gets, the more of a requirement there is for organization so the code remains maintainable. When considering code organization, I often consider newer developers integrating into a team. I value a developer's right to choose their own preferences because I believe it boosts productivity, especially when there is little to no cost to application performance. The programs we are working with in this class are small, and justifying a principle as the only way to code seems close-minded; however, as a program becomes a large, monolithic application, principles (like the data-type principle from last week) provide code organization which makes an application maintainable with a trade-off of increasing developer learning curve.

Comments

Post a Comment

Popular posts from this blog

SalonAboutBeauty: Less Integration for Consistent Styling Across Components

Ensuring Consistent Variables Less provides several advantages for organizing CSS to ensure consistency across a website. The variables.less file defines reusable properties that allow a developer to easily communicate and maintain styles according to a style guide or theme.  The Less Web Development Cookbook describes properties in the variables.less file in relation to other programming languages: “Variables in Less are defined as the equivalent to statics in other programming languages. You assign a value to a variable once and use it everywhere in your code” (Meyghani & Jobsen, 2015, p. 50). It suggests that less allows a developer to set properties, such as colors and length, to variable names that retain their meaning and can be used everywhere in the code. Examples: @base-color: red, @primary: green.  By providing these definitions in a central location, developers create code consistency in all areas of the website. Creating an Organized File St...
Read more

Why “Human Error” Is Usually a System Design Problem

In complex systems, failure rarely comes from a single bad decision. It comes from problems that evolve slowly, cross boundaries, and remain unresolved while everyone involved behaves reasonably. Managing risk in these environments means managing trajectories, not just incidents. When ownership is divided strictly by role, function, or severity threshold, gaps are inevitable. Those gaps are where issues linger, age, and quietly accumulate risk, not because they were ignored, but because no one was responsible for carrying them forward end to end. This is common in healthcare, where delay is often necessary. A patient may require observation, referrals, or time to clarify diagnosis. The failure is not that care takes time; it is that the trajectory of care becomes fragmented. Each clinician escalates correctly within scope, yet no one owns the evolving picture across visits, domains, and decisions. The patient is evaluated repeatedly, reassured locally, and sent away without continuity ...
Read more

Challenges in Prosecuting Deep Web and Darknet Crimes: The Case of Ross Ulbricht and the Silk Road

  The deep web represents online information that is not easily accessible through search engines. Prosecuting crimes on the deep web is no more challenging than prosecuting crimes for any standard website because law enforcement can still track the user's location through a domain or IP address. Alternately, the darknet poses a challenge for law enforcement to address illicit activity because while the darknet is a web-based system, it is accessible only through the Tor protocol that encapsulates HTTP and HTTPS traffic, much like a VPN that hides a user’s location and identity. The Tor protocol, often called the Onion Router, contains methods for encrypting and routing traffic between peers. The purpose of the Tor protocol is to make web browsing anonymous by routing each request through multiple peers and altering encryption at various steps until the request reaches its destination. Subsequent requests may hop through different peers, making traffic appear random, unpredictable,...
Read more