Reddit Reddit reviews Agile Principles, Patterns, and Practices in C#

We found 22 Reddit comments about Agile Principles, Patterns, and Practices in C#. Here are the top ones, ranked by their Reddit score.

Computers & Technology
Books
Computer Programming
Software Design, Testing & Engineering
Object-Oriented Design
Agile Principles, Patterns, and Practices in C#
Check price on Amazon

22 Reddit comments about Agile Principles, Patterns, and Practices in C#:

u/_dban_ · 31 pointsr/programming

I think this post summarizes why blog posts are a bad teaching medium, and why books are still very useful.

It looks like this guy read some stuff and applied it, without reading the full instructions. For example, the OP quotes Uncle Bob, but misses the context which is fully explained in Uncle Bob's book Agile Patterns, Principles and Practices.

For example, thinking that:

> depend on abstractions, not concretions

implies an explosion of interfaces and false abstractions.

The PPP book has a chapter detailing what he means by this.

In essence, the business rules should be abstracted away from how they are implemented, because the business rules change for different reasons than the implementation (and thus why they should be separated, as per SRP).

In the example, he is implementing a Coffee Machine.

Uncle Bob starts with the use cases to determine what software behavior is required, and derives a software model of that behavior using OOP. This results in a coherent set of classes with well partitioned responsibilities.

Then, he creates abstract classes to expose seams which the concrete implementations use to connect the abstract model to the physical implementation of the Coffee Machine. You can use interfaces and the strategy pattern as well to achieve the same effect (the approach I prefer). This way, the physical implementation depends on the abstract definition (as per DIP).

Thus, the seams become layer boundaries driven by abstractions derived from use cases.

Note that the goal isn't testability, it is separation of concerns. The fact that testability is improved is a side effect (and testability is a tool for measuring how well concerns are separated). This is why chasing testability as a goal leads to false abstractions, because you are approaching the problem from the wrong direction.

Thus, if you apply Uncle Bob's advice as he meant and as is explained in the book, the problem the OP demonstrates with lack of cohesion doesn't exist. In fact, there is a very useful section in the PPP book providing some useful metrics to determine how well your software model is organized, so you can move your abstract model from the "bad abstraction" to the "good abstraction" as demonstrated by the OP.

TL;DR - Seams aren't the problem, the problem is how you are thinking about the problem. Also, read the book, not the blog.

u/K60d55 · 23 pointsr/java

I don't really like the term "design your system using interfaces" because it doesn't tell you why. It's a generic idea without any context.

It is better to start with a principle, like Dependency Inversion. Dependency Inversion says you should separate your code from its external dependencies. This is good, because it keeps your code isolated and not dependent on the particular details of things like storage.

Does your application use MySql? Does it use MongoDB? It doesn't matter. In your interface, you can specify query methods for objects from a data store, and a method to save objects to your data store. Then implement the interface specifically for the data store. Your interface could be called FooRepository and the implementation MySqlFooRepository or MongoFooRepository. I dislike interfaces called FooRepositoryImpl. This strongly suggests an interface isn't necessary.

Interfaces are contracts that help you preserve your design and to explain what you need out of external dependencies.

Interfaces are good, but so are classes. Don't overuse interfaces, because indirection isn't always necessary or good. It can make your code impossible to follow and understand.

Start by learning principles like SOLID, which will help you understand where usage of interfaces makes sense. Agile Patterns, Principles and Practices is the best book I've read about this. Another book which does a great job of explaining how to properly use interfaces is Growing Object Oriented Software Guided By Tests.

u/_____sh0rug0ru_____ · 12 pointsr/programming

Ah, the context of the Uncle Bob rant from a few weeks ago. I don't see how any of the author's particular complaints have anything to do with TDD:

> You therefore are more reluctant to make large-scale changes
> that will lead to the failure of lots of tests. Psychologically, you
> become conservative to avoid breaking lots of tests.

This is a bad thing? If you think a whole lot of tests might break if you make large changes, clearly there are massive side-effects to the change you propose, and then wouldn't a conservative approach to making the changes be the right thing to do?

Personally, I like fixing broken tests when I make large changes. It gives me greater confidence that I won't introduce regressions and allows me to understand the impact of what I am doing and gives me insights to the design of the system, particularly when it comes to the level of coupling.

But, this is the consequence of having a test suite, and doesn't say anything about whether that test suite was created through TDD.

> Sometimes, the best design is one that’s hard to test so you are
> more reluctant to take this approach because you know that
> you’ll spend a lot more time designing and writing tests

The author didn't give an example of this, but I am assuming he probably means GUIs. Well, not everything needs to be tested, and especially with TDD. The key is to separate code that needs to be tested from code that doesn't (or tested in a different way).

When it comes to GUIs, I usually write a "shell" without tests (because really, besides interaction, what are you testing?) and delegate functionality to interior objects which I definitely implement test first.

Another example I can think of is heavily algorithmic code. Like, back in the day, I worked on seismic processing software. Well of course, you don't develop those kinds of algorithms test first (or, maybe in a very different way - the geoscientists involved wrote papers which discussed the math involved before writing any code). But again, like GUI programming, the seismic processing algorithms were isolated from the rest of the system, which was written test first.

TDD works well for some types of code and not others. The requirement of using judgement to decide the development processes for specific cases has nothing to do with the effectiveness of TDD as a general practice.

> The most serious problem for me is that it encourages a focus
> on sorting out detail to pass tests rather than looking at the
> program as a whole.

No it doesn't. Test-first just means you write tests before you write the code. That doesn't mean you can't look at the program as a whole first before that. The first half of Uncle Bob's book Agile Patterns, Principles and Practices is devoted to UML. Yes, you heard that right.

Check out this chapter from that book, Heuristics and Coffee. Before diving into the code, Uncle Bob spends a good chunk of time going through the use cases and coming up with a first pass at a high level structure for the system, in UML.

TDD is one part of "Agile" software development, where the rubber hits the road. But before you start driving, you should have a basic idea of where you are going, which is design. The "epicycles" of TDD then serve to validate that you are on the right course, from minor turn-by-turn directions to occasionally stepping back and making sure you are still on course.

The idea is to come up with as much UML as necessary to get a basic idea of the overall design, and then use TDD to execute and validate that design, incrementally.

The author is taking TDD out of context and missing the bigger picture.

> But the reality is that it’s often hard to specify what ‘correct
> data’ means and sometimes you have to simply process the data
> you’ve got rather than the data that you’d like to have.

What does this have to do with TDD? Again, TDD is a part of a larger process, which involves the business. Software that does "real work" doesn't work in a vacuum. Programmers have to deal with the business to understand the data to the best of their ability, and even still, you'll still make mistakes.

At least the tests document an executable understanding of the data, and test failures can actually give valuable insights on changing assumptions of the data.

u/NisusWettus · 6 pointsr/csharp

C# in Depth likely isn't what you need. That's more aimed at proficient coders that want to understand the nitty gritty/internals.

Clean Code: A Handbook of Agile Software Craftsmanship (Robert C. Martin) is very popular. Not specifically aimed at C# (a lot of the examples are Java) but it's guidelines about how to write clean code in general. The lessons carry over to all/most languages. That's probably more the sort of thing you want.

https://www.amazon.co.uk/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882

Robert C. Martin aka 'Uncle Bob' also has a few other books but I've not really looked into them. e.g. this one is focused on C# and looks decent based on a quick skim of the index but I've not read it:

Agile Principles, Patterns, and Practices in C# (Robert C. Martin)

https://www.amazon.co.uk/Principles-Patterns-Practices-Robert-Martin/dp/0131857258

u/sh0rug0ru · 5 pointsr/java

Read lots of code and read books to get multiple viewpoints. This is a deep topic which will require more than superficial online reading.

Check this out.

Books I have found useful:

u/adamwathan · 5 pointsr/PHP

In the real Command Pattern, commands do have an execute method.

This excellent book by Uncle Bob devotes a great deal of time to that pattern if you'd like to learn more about it:

https://www.amazon.com/Agile-Principles-Patterns-Practices-C/dp/0131857258

u/CSMastermind · 4 pointsr/learnprogramming

I'd suggest you should pursue software development as a career path. Once you're working full time as a developer it will be much easier for you to move into a .NET role if you choose.

The career market can be hit or miss. There are plenty of jobs using those technologies but they're less ubiquitous than say Node or Java.

In terms of keeping up your skill, Pluralsight has some amazing content. And I'd recommend these books:

Design Patterns in C# - probably the first book I'd read.

CLR via C# - In-depth, targeted at professional developers, and absolutely crucial for anyone doing it professionally.

Agile Principles, Patterns, and Practices in C# - Will help get ready to work on a professional software development team with a slant towards Cc#.

Pragmatic Unit Testing in C# with NUnit - Also important for working as a professional C# developer.

More Effective C# - Is more of a specialist read. Might be helpful after you've worked for a year or two.

Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries - Is better suited for a technical lead or architect. But could be useful to keep in your back pocket.

u/sethgecko · 3 pointsr/NewOrleans

LSU's problem is not budget cuts. Their CS bachelor and masters programs have been unaccredited and very poor for 20 years. Their CS PhD program on the other hand is quite good but that's a completely different entity. (I'm not saying brilliant people haven't graduated from LSU CS, but those people were brilliant themselves and largely could have done without the 4 year term in undergrad since they learned more on the job than in Coates Hall)

SLU, LSU and all state universities are going through budget cuts. I'm on the advisory board for SLU and ULL and in the case of SLU in 2004, 67% of their funding came from the state. In 2014, it's down to only 28% from the state. So, tuition has gone up. The pressure for private donations has risen sharply. But despite this SLU CS revamped the department in 2005 including modern technology into the curriculum, modern theoretical concepts and increased its student project exposure with modern technology and techniques many times over.

So while LSU recently added a class incorporating AngularJS in it, SLU has been teaching students cutting edge technology and theory and technics like SOLID principles, MVC and now AngularJS for a decade now. I was directly involved in SLU continuing their ABET accreditation 6 years ago and wasn't even needed for the 2014 check. SLU is also constructing a new building for CS, despite having build a new for them less than 16 years ago. I don't know how I feel about it but whatever, it's a perk.

The difference isn't money, it's people. SLU and ULL CS profs have LSU profs beat by a country mile. The SLU curriculum is constantly adapted for the industry. The student focus is experience and application of the theoretical techniques. The theory classes will teach you a dictionary is faster than a list and in the project courses, which start sophomore year, you will see why and will never forget it.

Consulting firms cherry pick ULL and SLU junior project presentations for new hires while LSU CS graduates are largely unimpressive until their 3 year maturity.

So snag a used copy of the cs bible and give Doc a call.

u/zebishop · 3 pointsr/csharp

I found that often the best way to know if your implementation is SOLID is to write the unit tests for it.

For example, if you want to test the PreferencesThing class, you could run into an issue because of the dependency on PreferencesStorage() : if it needs a file, the network, whatever, it will be hard to write. So PreferenceStorage should implement a IPreferenceStorage interface, that you would mock during the tests. And your class constructor or GetThing method would take a IPreferenceStorage parameter. In a strict SOLID approach, I guess that even the ObjectSerializer could be considered problematic.

That being said, keep in mind that SOLID is an excellent way to structure your code, not a magical hammer. Use it wisely.

I would recommend (if it has not been made) reading http://www.amazon.com/Agile-Principles-Patterns-Practices-C/dp/0131857258 which goes in length on those topics. Also, anything else by Robert Martin (uncle bob) is usually a good reference on the topic.

u/negative_epsilon · 3 pointsr/cscareerquestions

>how, exactly, things like MVC work in action, and why the little things always end up more challenging than anticipated.

These are things a bootcamp will not teach you.

I just finished this book and it goes over a lot of things like design patterns and how to stay agile, why code rot happens, etc etc. It might help you a lot more than a bootcamp would, and costs about 300 times less.

u/DEiE · 2 pointsr/learnprogramming

I would place OOP and practice on the top of the list. OOP on the top because it is much broader than a single language and practice second because practice is just plain important.

Data structures and algorithms come third and fourth because they are more forgiving in practice. OP is using Python which has a lot of data structures and algorithms built in (lists, sets, sorting, etc.) so they aren't immediately needed for results. On the other hand, if you aren't utilizing OOP and abstraction the software is more likely to turn into an unmaintainable mess (although your project will have to have a certain magnitude before it comes to this point).

One of the best resources I have read on OOP is Agile Principles, Patterns, and Practices. This one is focused on C# but the principles are applicable much more broadly.

Don't get me wrong, all are important, this is just the way I would prioritize.

u/PoisonTaffy · 2 pointsr/learnprogramming

This is a really good book about thinking OO. A real eye opener. Extra bonus in your case, as it's in C#.

Agile Principles, Patterns, and Practices in C#

The first few chapters are about agile, but that's only about a 1/4th of the book.

u/sh0rug0ru_ · 1 pointr/java

I would suggest reading these books to get a deep understanding of OOP:

  • Agile Patterns, Princples and Practices in C#
  • Growing Object Oriented Software Guided by Tests
  • Clean Code

    Here's a chapter from the Agile PPP book, Heuristics and Coffee, which gives a great overview on how to think in OOP terms. Keep this in mind: OOP is a way of thinking as much as it is a way of programming. OOP lives in the spaces between objects, in the methods, not necessarily the objects!

    Also, note that OOP is a code organization, which really starts to make sense in larger programs. I would suggest writing some larger programs, such as a contact manager, an email client, a chat application, etc. Larger programs will give you a chance to play with technologies such as databases and client/server networking. More stuff to add to the ol' resume.
u/[deleted] · 1 pointr/java

Frameworks like Spring and JPA/Hibernate are used in professional software development, and it is important to know them, but they won't teach you proper ways to architect your software. They are only tools, not substitutes for understanding and judgment.

I would suggest stepping back and learn patterns like Clean Architectures. This will help you understand the principles of software architecture, which is more important than Spring or JPA/Hibernate.

There are plenty of books on this subject. My favorites are Growing Object Oriented Software Guides by Tests, Agile Patterns, Practices and Principles in C# (the book has very little to do with Agile), Clean Code, Clean Architecture, Patterns of Enterprise Application Architecture.

Martin Fowler's website has a lot of good stuff about all architectural topics, from the stuff you're asking about, to microservices and big data.

Uncle Bob has a lot of videos on YouTube that are well worth a watch, like this one. Skip past the first five minutes or so unless you want a physics lesson, too.

u/gibbons1980 · 1 pointr/csharp

I think learning OOP is a very good idea. There are tons of books on the subject but I would recommend these 2:

Uncle Bob's Agile Principles, Patterns, and Practices in C#

This book will teach you not only about good OOP principles (SOLID principles) but a also a lot about other programming practices such as testing and refactoring.

Sandy Metz's Practical Object-Oriented Design in Ruby: An Agile Primer

Don't worry about being a Ruby book, you should be able to understand the concepts (and learn some Ruby). Sandy ha a very good way of teaching how to think about OOP.

Hope it helps.

PS: I'm curious: what exactly did you struggle with? What made you think you should learn OOP?

u/banuday17 · 1 pointr/javahelp

To sharpen your OOP skills, I highly recommend these two books. I would go so far as to say they changed my life:

u/MadeWithPat · 1 pointr/node

Clean Code is a good one :) The book where he goes into SOLID is the Agile PPP book . I believe he refers to Clean Code as a sort of prequel to Agile PPP.

It sounds like you’re doing pretty well and on the right track. CORS is an area where I’m not especially strong, tbh. I would probably put the api on an api.example.com subdomain, but that’s sheer personal preference.

I’ve spent so much time in .NET recently, it’s nice to jump into a JS discussion. Time well spent, in my mind.

u/jacobisaman · 1 pointr/ISTJ

I have been a software engineer for about a year. We use Test Driven Development where I work, and I have found that it really helps me think through the requirements and make decisions about what the software should do one step at a time. I definitely prefer this method to just "feeling it out" like some of the intuitives do.

I have also found it incredibly useful to get familiar with good programming practices and patterns and would recommend stocking up on books and maybe reading them with another person or two for discussion. Clean Code and Agile Principles, Patters, and Practices have been very useful for me. Once you start to get the general patterns down, designing something from scratch isn't such a mind explosion, because you have a general idea of how things should be designed and what "good" software looks like.

u/Innovashiun · 1 pointr/learnprogramming

For what it's worth, you are up to something. The thing is, however, that in big tech companies they use "Java, C++ or other mainstream" as a placeholder. They won't shut the door in your face if you tell them you're good at C#. As an example look at John Skeet, author of C# in depth who's working at Google now.

Agile principles http://www.amazon.com/Agile-Principles-Patterns-Practices-C/dp/0131857258 and working with Hadoop with .NET http://blogs.msdn.com/b/data_otaku/archive/2013/08/14/hadoop-for-net-developers.aspx but in general, someone can jump back and forth if the need rises.

You're probably looking at something like "I prefer start-ups and mid-sized companies over corporate" and not something language-specific.

u/KoleCasule1 · 1 pointr/csharp

Hehe, thanks for pointing out. I'll definitely read "APP&P" as it's from Uncle Bob and I see people cherishing his work.

Since I mentioned it, I assumed you are talking about Uncle Bob's book: https://www.amazon.co.uk/Principles-Patterns-Practices-Robert-Martin/dp/0131857258

Correct me if I am wrong.