I would have a question related rather to process of team programming than programming itselft. If you are a programmer working in a team and you are responsible for particular part of the software - you deliver namespace or classes? I mean, in reality, I think that programmer creates more than one class so creating a namespace to provide the other programmers with seems to me to be correct. Is that correct? I am trying to get some knowledge before I try to apply to same junior programming position..Thank you guys
Your senior developer defines a task for you and you going to do it, may be is reading, improving some functions, creating some function, or creating a class, if you do your startup projects well he give you more opportunity may be you work on specific application (bigger than a namespace), it depends on your working power and knowledge.
Related
I know this may be a silly question, but I have looked in a lot of books and tutorials and they explain what is a class, and what's a solution but there's no way to confirm if what I'm understanding is right or wrong besides asking to a human that have some knowledge about the topic.
From what I understand a Solution is a group or classes, and there's a main class that contains the most important parts of the code and how objects are supposed to interact, and from time to time it calls some other classes which have the information about and specific object.
I.E. I have a solution of a game where a bird flies avoiding clouds(?), so I have a class with all the info related to the bird, another one related to the Cloud and a Main class who have all the information regarding how the cloud.cs and the bird.cs are supposed to interact.
I know this may be a really dumb question, but as I told you before, there's no way a book or a website can say to me "yes, you understood correctly".
Thanks in Advance!
I googled around a bit and found a perfectly viable explanation about what a solution and a project is. The explanation of Claies is short, to the point and correct.
A more elaborate explanation can be found here from MS themselves.
https://msdn.microsoft.com/en-us/library/b142f8e7.aspx
A solution is a collection of projects that are bound together somehow to build a complex application. A complex application can consist of several projects and each project defines an assembly.
To give a concrete example: you create a client and a server application. The client and the server communicate with each other and logically they belong together. One without the other makes no sense. So you can create a solution that contains the client and the server project.
To make it more complex, it might be possible that these 2 projects share some code. You can then decide to split of the common code is some kind of library project. So you would have 3 projects in your solution.
I hope this is the right place to ask.
I am fairly new to .NET and I am having some problems regarding implementing OOP concepts.
I have followed a couple of books about c# and here is he problem.
By now, I know the OOP concepts theoretically, but I donot know 'How and When' to use these concepts in real world scenario. e.g. i know the DEFINITION of abstract, sealed, public classes and so on but i donot know WHEN to use them.
every books talks about person class or car class examples. but all those examples doesnt seem to work if i think of creating a for example simple inventory system. how would i define classes, methods, properties about an inventory system. this is where i alwys get stuck.
If possible please tell me of some book or resource to follow.
Thanks
It is hard to suggest a good book. Most of them describe OOP, but they don't describe "When" and "How deep". So I will give you two big advices:
Use minimal, the simplest abstractions and only when you feel they are required. Do not over-design, do not over-think. Keep things simple and loosely coupled
The second advice is an opposite compensation point for the first. Think in 3 years ahead. Just imagine how your system probably will look at that time. Predict the future requirements and customer wishes. This will give you the hint about how deep your design should be detailed and how much abstractions you should embed into system at the start to make your future bright
You might like to read Ron Jeffries' Extreme Programming Adventures in C#. It's rather outdated in terms of C# versions, but it's a good read. It is essentially his diary of learning C# by writing an XML editor. It is also focused on XP methodologies, as indicated by the title, especially test-driven development.
By presenting the material in the form of a journal or diary, the author gives interesting insights into his thought processes; the flow of the narrative depicts his problem-solving process (pursuing a solution, then realizing it's no good, abandoning it for another solution, etc.).
That aspect is usually absent from programming books, which generally lay out ready-made solutions, sometimes without adequately explaining the problem being solved. In real life, problems come before solutions, not the other way around.
Look at https://stackoverflow.com/questions/574001/what-books-do-you-suggest-for-understanding-object-oriented-programming-design-d
Head First Object-Oriented Analysis and Design
Head First Design Patterns
Is it good approach when in software-designing the class interactions are describe only with interfaces? If yes, should I always use this approach?
I must design class library that should have a high testability (I use C#).
This library have one facade and some amount of classes with different interactions in the background.
In the case of optimizing this library for good testability I've replace most part of my classes with interfaces.
And when I did this, I saw in a connection diagram (Visual Studio class diagram) only interfaces.
Is it normal decision of my problem? or there should be some another approach?
P/S: Maybe it's well known way in software-design but I can't find some confirmation in books that I have.
Yes this is good practice. It allows you to focus about the responsibilities of each class without getting concerned with implementation details. It allows you to see the method call stack and as you say gives a high level of testability and maintainability. You're on the right track as far as I see :)
Yes, that is generally a good practice.
I would recommend you to read a good design patterns book, for example this one.
it is targeted for Java developers but I had no trouble understanding all the examples as a C# developer.
By using interfaces you can decompose your applications into subsystems to make it maintenable and easily expandable. Some uses cases can be:
application may need to communicate more than one web service endpoints to to fullfill same functions such as direct billing or payment interfaces from different providers
data access layer class that execute SQLs to different Databases with different drivers.
processing different objects that implements the same interface using the same thread pool from the same queue
How to change existing Singletone behavior in C#
I have a problem – we are using assemblies developed by other team (infrastructure team), there is Singletone class we need little bit different behavior.
We are thinking of number of possibilities how to deal with code implemented by other development Team.
One possibility is to add additional Instance2 method, but it's not a good idea as we thought. This solution makes our API not usable and hard to understand.
May be there is any common way to solve it?
If you are using API you don't like simply write a wrapper of this API. Not add method to this API.
You can inherit from singleton for "reuse" or some fine tuning, using templates (C++) or generics (C#.NET).
I've posted in my blog (www.devartplus.com) a serie of posts in this subject:
1) Basic singleton inheritance in C#.NET
2) Thread-safe singleton inheritance in C#.NET
3) Singleton implementations in C++
You are invited to visit those links, and share your opinion.
Good luck.
I am newbie C# developer. When I just have started to learn programming thins were pretty simple, you see the problem, you develop solution, test it and it works, that simple.
Then you find out the design patterns and the whole abstraction thing, and you begin to spend more time on the code that yields no results, always tiring to protect code from possible changes in future. More time less result.
Sorry for the boring introduction, but I just trying to show how frustrated I am now.
There is a bunch of data-access technologies provided by Microsoft itself, and even larger bunch of technologies provided by third-party companies.
I don’t have team leader or neighbor super skilled programmer friend, so I have to ask an advice from you.
How do you realize the data access in your real applications written in C#?
From a very overall perspective, I always hide and data access implementation details behind an interface, like this:
public interface IRepository<T> { /*...*/ }
The .NET framework offers a lot of different ways to access data, so I can understand that you are confused. However, at this time, there are only really two or three reasonable options for accessing relational databases:
NHibernate
Entity Framework
(Low-level APIs like IDataReader may still have their place in limited scenarios)
It's often difficult to see the benefit of abstraction without seeing the benefits it provides in a real world application. The best advice I can give is to read up on the SOLID principles then in writing your application try and think about ways the client may come to you and say "Now I need it to do this" which maybe a subtle change to the functionality or a major change. Think about how this would affect your code and in how many places you'd need to make those changes. Once you've made those changes how confident would you be that you haven't broken something else?
Another idea would be to download one of the sample applications. One of my particular favourites is the Data Access Platform sample provided on Codeplex. Try working through this code and see how the abstraction and pattern implementations minimise the impact on the code overall when it comes time to change.
The bottom line is it's easy to learn a programming language but understanding how to build robust solutions with it takes time. Stick with it though because when you do finally get a good understanding of software architecture it's immensely rewarding.
Some points to consider for the DAL: (note: very opinionated, but answers to this question have to be)
Encapsulate logic behind a Repository
Use interfaced-based coding
Use Dependency Injection
Use a mature ORM like NHibernate/Entity Framework 4.0 (but know when to use SPROC's for db-intensive work)
Use the Unit of Work pattern
Prevent SQL Injection attacks by using parameterized queries (or LINQ-Entites, as above)