2

First time posting.

I know this is a very generalized question, sorry for that, I don't know how to more appropriately word this.

I've noticed a trend, a pattern in methods, it seems in almost all methods, for example, in Java (haven't programmed much in other languages although I would imagine it's the same) the method seems to share a general pattern in their creations.

It's something on the order of:

  • Create local variables to store/copy things from instance variables;
  • Create a loop to iterate through things;
  • Create a series of if statements/conditions, possibly accessing pre-made methods;
  • Check for any sort of possible exceptions/problems along the way;
  • Return the desired output of the operations from the above;

And all the other aspects such as polymorphism, recursion, interfaces, inheritance seem to be conceptual features/additions to the codes performance and functionality

Is this true? I know that each method is unique and a special combination of the above is probably require. Generally speaking do most methods follow a pattern? Is there a better way of writing out the above list, in a more formal way?

Thank you, I appreciate you taking the time to read this post.

1
  • 1
    What are you really trying to understand? Of course there will be a structure/pattern/format for programming, just the same way sentences have nouns, verbs, articles, etc. What are you trying to figure out? Nov 6, 2016 at 5:08

3 Answers 3

2

Is this true? I know that each method is unique and a special combination of the above is probably require. Generally speaking do most methods follow a pattern?

No, most methods don't follow the pattern you described. It would be more exact to say that there are many different, smaller patterns, and most methods follow one or several of those patterns.

For instance, input sanitization could be considered a pattern, and most methods, indeed, would try to check and eventually normalize the values from the arguments before using them. Unless they don't, and sometimes, they don't for a good reason.

Imagine a method which stores the first and last name of a person in a relational database. Should the method check for the length of the names before doing the SQL insert query?

  • Sometimes, yes. Doing a query which will necessarily fail is not a good idea, because it will waste database resources, waste network bandwidth, and in a worst case, make it possible for an attacker to do a DOS attack on the database itself.

  • Sometimes, no. If you're writing a small application which uses NoSQL to store the data locally (on the client's machine), it could be interesting to keep the maximum length rule in one place—the database itself—instead of duplicating the logic.

Considering the pattern you were talking about in your question, many methods don't follow it at all. For instance, take a method filter which simply walks through a sequence and returns only the elements which match a predicate. You have a loop, but no local variables, possibly no exception handling, and obviously no return statement at the end, since the results were yield-returned progressively inside the loop itself.

This means that your pattern is simply too complex to be useful. Simpler patterns, however, could work. Some, such as input validation, don't change the nature of the method. Others, such as “go take the value from a field and return it as is” are indicative of a specific type of a method—in this case, a getter.

Is there a better way of writing out the above list, in a more formal way?

No, and you don't need one.

The goal of a pattern is to be able to exchange your ideas with your pairs easily. When you're using an abstract factory, you don't need to start drawing complicated diagrams to the other members of your team: you simply tell them that you are using an abstract factory (ideally through the names of your classes), and they are (hopefully) knowing what are you talking about and what does it mean in terms of classes organization and their usage.

This would work for small “patterns” I enumerated above. A simple word getter says a lot to another developer about a specific method: if I see a Java method called getPrice, I may guess its contents. Similarly, telling someone that you will have to sanitize inputs in your method is easier than to explain that you have to have a bunch of conditions which will check for the edge cases such as the length of the strings, the null values, the out of range numeric values and other nasty stuff before being able to use the arguments within the method.

1

Exactly how code is laid out usually depends on the coding paradigm you're following.

Java is generally considered an OO language, but it is possible to write Procedural code in it as well. In that case, a procedural Java method will look different from an OO Java method in that it won't be leveraging the built-in OO features of the language.

Functional Programming is another paradigm where the general method "pattern" is different.

And, if you're brave enough to venture away from Imperative programming altogether, then you could look into Delcarative programming where the order of execution of your statements is not explicit.

I would normally try to provide some examples to compare and contrast each paradigm, but I am by no means an expert. My skillset is limited to the Imperative OO paradigm mash-up (with a dash of FP in there thanks to C#).

1

I don't really agree with MetaFight, if I'm doing OO or procedural there are definitively things that functions/methods well written share :

  • Prerequesites checks : always check all of them at the start of the function not when you're going to use them. It made things clearer when you read it afterwards.
  • Cyclomatic Complexity : Don't use too much different condition paths.
  • Single point of return : when possible have only one return. If you don't have exception in the language, you may use it in your prerequisites check instead of having some indentation level for nothing.
  • As you said, don't change the parameter values specially when things are passed by pointer/reference, it can be confusing.
  • And everything we know like magic numbers and so on apply to all the languages.

Of course between procedural or OO you will have differences, but I dare say that if you list those differences, the list will be way shorther that what they have in common.

2
  • I would tend to agree with your last statement. I wasn't trying to say OO and procedure were completely different. I'll have to revisit how I wrote my answer later when I have more time.
    – MetaFight
    Nov 5, 2016 at 16:02
  • @MetaFight I tihnk what you were trying to say is more about how we use them, since for OO we have fields, polymorphism, we write the logic differently.
    – Walfrat
    Nov 5, 2016 at 16:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.