We Keep Coding

Changing an Existing class - Best Practice Open/Closed Principle [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
I am trying to figure out the best way to change an existing class.
So the class is called ExcelReport and it has one method Create(data,headings). This is live and used in many places. Now recently I want to change the method so I can format columns in Excel.
Create(data, headings, columnformats)
So as not to upset my existing programs the best I can come up with is to add another method Create2(data,headings,columnformats) to the class.
I got a lot of suggestions saying I should modify the existing class with a overloaded method, which I did. But does this not break the Open/Close Principle as my existing class was in production?
Should I have created a new class ExcelReport2(and Interface) with the new improved method and passed this into my new program using dependency injection?

OCP
In object-oriented programming, the open–closed principle states "software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification";[1] that is, such an entity can allow its behaviour to be extended without modifying its source code.
Your solution
You will most likely want to create more options later on for this.
And since you asked for an open/closed principle answer we need to take that into account (open for extension, closed for change).
A more robust alternative is to create a new overload:
void Create(CreationOptions options);
Looks trivial, right? The thing is that any subclass can introduce their own options like MyPinkThemedFormattedCellsCreationOptions.
So your new option class would look like this as of now:
public class CreationOptions
{
public SomeType Data { get; set; }
public SomeType Headings { get; set; }
public SomeType[] ColumnFormats { get; set; }
}
That's open for extension and closed for change as new features doesn't touch the existing API, since now you only have to create sub classes based on CreationOptions for new features.

layered architecture. do it correctly [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I want to learn how to make layered architecture correctly. For that I need an advice.
For example project I started to write news website. I layered my project:
Is it best to do that? I'll do that angular (in web project).
And one more. Should I make one more layer for Dependency injection?

I would not call it NewsWebSite.BLL because it sounds like the BLL can only be used for web applications.
I would have it like this. If the company name is Contoso:
// This is where you can put all your common code.
// I do not mean cross cutting concern here. By common I mean if you have
// some contstants or enums that are shared by all Dlls
Contoso
Contoso.Business
Contoso.Api
Contoso.WebApp
Contoso.Data
// The name of test projects are exactly the same as the name of the
// assembly but has the word "Tests" at the end
Contoso.Business.Tests
Contoso.Api.Tests
Furthermore, see the Pascal Casing naming convention I am using. This way I do not have to deal with Contoso.BLL.SomeClass.
Also, my Contoso.Business.Tests will reside in a namespace that matches my Contoso.Buiness namespace. Here is a class in Contoso.Business:
public namespace Contoso.Business
{
public class Foo
{
}
}
The test for that class, I would not put it into Contoso.Business.Tests namespace (I am not talking about the DLL). I would make my test class which is testing Foo like this:
// See the namespace here, I am not using Contoso.Business.Tests
public namespace Contoso.Business
{
// The name of the class is identical to the name of the class being tested but the word "Tests" appended
public class FooTests
{
}
}
That way they share the same namespace and I can relate them easily.

I use often that architectural structure. In the same situations, meaning webAPI and angular.
But it's important that you considerate all the need in your project, including it's dimension. Ex: if you don't really have the need to manage Logic of business, using a BLL may just no be relevant.

Does starting method names with "Do" conform to some kind of standard? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
For some reason, a couple of members of my team habitually starts method names with "Do"
e.g.
public void DoReopenLeads()
public void DoProcessBaloney()
Now, I'm a "learn on the job" kind of a guy and haven't had any formal code training, so I don't know whether this is an industry accepted coding standard.
To my mind, it seems a bit dumb, as all methods "Do" something or other...
Coding standards for our team doesn't cover how to name methods (other than saying what the function does in fairly clear English)

There are no such standard. Maybe this is local "style". Prefix "Do" can be useful if there are several methods/functions with same words after "Do" like: PrepareProcess, LoadProcess, FinishProcess - then DoProcess will be normal.

There is no kind of definition that each method should start with "Do".
One principle from Clean Code (I love and recommend the book from Robert C. Martin) for naming methods is that you should not look into a function in order to know what the function does. So the naming has to transport the meaning.
Methods should be verbal phrases, because they actual "do" something with or on the data. But just beginning all method with a Do prefix only adds useless information. Being more specific makes it easier to accomplish the "Clean Code" goal.

Usually for methods that represent actions method's name starts with a verb. “do” or “does” are auxiliary verbs and rarely they add meaning.
Btw, take a look at this: C# Coding Conventions

Whilst this topic is kind of oponionated I would like to share some soft guidances I have found.
The DoFactorys C# Coding Standards and Naming Conventions only states that:
use noun or noun phrases to name a class
A rather useful guide of AvSol C# Guideline maintained by Dennis Doomen states that:
Name methods using a verb like Show or a verb-object pair such as ShowDialog. A good name should give a hint on the what of a member, and if possible, the why.
Also don't include And in the name of a method. It implies that method is doing more than one thing, which violates the single responsibility principle...
In the end, the are no such official guidelines exist written in stone. Your workspace and domain culture should drive creating your own guidelines.
For a good start I suggest you to read Domain-Driven Design: Tackling Complexity in the Heart of Software written by Eric Evans. It contains a section called Ubiquitous Language which might help you to learn how to create and evolve your shared language by closely consulting with your domain experts AND fellow coworkers. Your code could also follow this common language, so your codebase could tell "stories" or use-cases by reading it.
An other good reference about the UL is written by Andrew Whitaker, where he writes that:
Having a ubiquitous language improves the coherence of the code base and keeps everyone on the same page.

Is code cleanliness a good enough reason to use a property over a field? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I have a class that is Enumerated to allow subscripting of a list contained within it. For this reason, the List does not need to be publicly accessible through a field or property.
public class Foo : IEnumerable<Bar>
{
private List<Bar> _positions;
If I have other properties in my class with private setters, future programmers will see PascalCase, PascalCase, PascalCase, _asdfghjk. Huh? What the hell was that? _asdfghjk sure does look pretty ugly.
Is the consistency created by making _positions into something like
private List<Bar> Positions { get; set; }
a good enough reason for using a property over a field?

So long as you are consistent then somebody reading your code will not be surprised.
If the convention that you are using is _privateField then so long as you're using it everywhere a person reading your code will get used to it.
The danger comes if you mix styles.
To be honest, personally I'd be confused to find a private auto-getter/setter properties in a class; to quote MSDN:
Properties enable a class to expose a public way of getting and setting values, while hiding implementation or verification code.
--Properties (C# Programming Guide)
and
Generally, you should use fields only for variables that have private or protected accessibility.
--Fields (C# Programming Guide)
Finally, if you are using StyleCop, then if you start a field with an underscore, then it will warn:
Field names must not start with an underscore. [StyleCop Rule: SA1309]

I wouldn't introduce a fully-private property just for the sake of it. It can be useful to do so if it computes the property value from state, or performs validation etc - but don't just do it for the sake of it.
Personally I'd just call it positions instead of _positions - heck, you could call it Positions if you really wanted all the names to be consistent with each other (but inconsistent with normal naming conventions).
It shouldn't be a particularly rare thing to have a field which isn't exposed by a property - I'd be worried if seeing such a thing bothered a developer. Likewise not every property ought to be an automatically-implemented property, so developers should be used to seeing both foo and Foo as members of a class (with foo being private).

How to Change C# language [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
i'm learning programming on c# in my university country with French language and i wonder if i can change word to french to be more easly for me, ex:
From:
string name = Console.ReadLine();
if(name=="Aymen")
{
Console.WriteLine("Hello, Aymen");
}
To:
chain nom = Console.ReadLine();
Si(nom=="Aymen")
{
Console.WriteLine("Bonjour, Aymen");
}
What i did is i change the "string" and "if" with "chain" and "Si".
Thanks

No, that's not possible (and a bad idea anyway).
C# has a clearly designed specification that defines all language constructs, and such "translations" are not part of it. It would be possible to create a computer language with such a feature, but the impact would be huge:
the list of keywords would increase for each "language"(in your example, Si has be a reserverd keyword).
learning the language would be harder.
the majority of users of the language would not be able to read your code (just think about the fact that each basic type has multiple names.
as a professional developer, you would probably still need to learn the english version, and learning the french version first would be wasted time.
it would be much harder to write a compiler for such a language (harder == needs more time == costs more money), for very little gain.
So I would not be surprised to see a esoteric fun computer language with such a feature; but a production ready mainstream language? No.

Changing the keywords of a language is a wrong way learning the language and learning coding.

The reserved and contextual keywords of C#, and most languages, cannot be changed - the compiler expects them to be pre-defined and unambiguous. No mainstream language allows for this. This covers the string and if in your example.
The class and member names of the available libraries and frameworks are contained in the libraries themselves. Technically you could replace the libraries with your own (yes, you can write your own System.dll and mscorlib.dll, if you are very, very bored) - but some names are expected and are necessary - for example, you can't replace Monitor.Enter or GetEnumerator)() / MoveNext() / get_Current with something different - the compiler will simply break. This covers Console, ReadLine and WriteLine in your example.
However! The fields, variables, types and members inside your own code can be anything reasonable in unicode. And of course your string literals can contain any unicode you want. So you can have:
static class す {
static void Main() {
ず();
}
static void ず() { }
}

What you're asking is to change the types and the keywords of the programming language, then its structure. Since the compiler expects to work with the standard structure defined by Microsoft, your changes won't work. For this reason, what you're asking isn't possible.
If you want to change the keywords and define a new structure, read few books and learn something about compilers and programming languages. Then, maybe, you'll be able to create your own programming language with a structure defined by yourself.
Everybody, I think, wants to change the structure of a programming language according to the spoken language, in order to read it in an easier way. I thought many times something about Console.LeggiRiga() (Italian translation for Console.ReadLine()), but this would mean that my source code would be readable and understandable only by Italian speakers.
Using English, we're able to understand each other what we're doing with the code, since English ,as #OndrejTucny said, is the lingua franca of software engineering.